Rôle d'Alpine JS par rapport à HTMX sur Docstring

Bonjour Thibault, j'ai une question concernant Alpine JS et HTMX en prenant exemple sur Docstring qui est le site que je connais le plus avec cette stack. Quel rôle a Alpine JS sur docstring par rapport à HTMX par exemple ? Je n'arrive pas à voir le rôle du framework front-end dans une plateforme comme celle-ci.

Je suppose que c'est possible de faire des requêtes ajax avec Alpine aussi donc... Pourquoi avoir recours à HTMX ? Il y a confusion.

Je précise que ma question est dans le cas où c'est Django qui gère tout et non un framework front qui consumme une API. Sauf si c'est également le cas avec Alpine.

Salut Yanis,

Bonne question, que je me suis posé au début aussi, vu que comme tu l'évoque, Alpine peut être utilisé aussi pour faire des requêtes Ajax. Mais en fait ce n'est pas sa fonction principale.

Je m'en sers surtout pour tout ce qui est modification de styles / classes en fonction de l'état de variables. Par exemple sur les pages de formation vidéo, il y a les boutons pour augmenter la vitesse de lecture : je peux facilement désactiver un bouton quand la vitesse de lecture arrive à 2 (le maximum) et vice-versa.

Avec x-show tu peux aussi changer la visibilité d'éléments en fonction de valeurs. Ça permet par exemple d'avoir une liste d'éléments, et quand tu cliques sur un bouton, cacher des éléments qui ne matchent plus la condition d'une valeur.

Je m'en sers par exemple sur la page de vente de la formule Premium pour basculer les prix entre le mensuel et à vie et changer l'affichage d'éléments ou le calcul du prix en fonction :

Donc pour résumer, ça me permet de faire beaucoup plus facilement tout ce que je ferais avec du JavaScript pour modifier le DOM. Ça permet, comme avec HTMX et Tailwind, d'être au plus prêt des éléments (locality of behaviour), sans avoir besoin d'écrire du Javascript.

Sans Alpine, je devrais créer des écouteurs d'événements, le code se retrouverait dans des fichiers .js ou à la fin d'une page, loin de leur utilisation, et j'aurais beaucoup plus de code à écrire (par exemple pour changer la visibilité, avec Alpine un simple x-show='isVisible' suffit, alors qu'avec du JavaScript, il faut récupérer l'élément, changer ses classes, etc).

Ah oui je n'avais jamais fait attention mais c'est aussi le principe de locality of behaviour avec Alpine, pas besoin de changer de fichier et de donner des ID pour manipuler le DOM.

Je commence à comprendre l'intêret de cette stack ultra minimaliste, j'ai l'impression que ça se marie parfaitement avec django et on se retrouve au final avec des composants réutilisables partout sur le site sans React ou Vue.

Oui, tu peux aussi voir des packages comme django components pour t'aider sur la partie composant réutilisable même si c'est de base faisable avec juste un include ou des tags custom de Django :)