Retour d'expérience d'un développeur Django : Pourquoi j'ai adopté Alpine.js et pris mes distances avec HTMX

Pourquoi j'ai adopté Alpine.js et pris mes distances avec HTMX

Bonjour à tous. Aujourd'hui, en tant que développeur Django principalement orienté backend, j'aimerais vous parler de deux acteurs majeurs qui animent la tendance du « moins de JavaScript » dans l'écosystème frontend actuel : Alpine.js et HTMX.

Pour ceux qui, comme moi, sont familiers avec Django et Python, ces outils sont une véritable bénédiction. Ils permettent de créer des sites web modernes et performants sans avoir à se plonger dans les configurations complexes de React ou Vue. Cependant, ces deux approches ont des objectifs et des caractéristiques très distincts. HTMX est spécialisé dans la communication avec le serveur, tandis qu'Alpine.js excelle dans la gestion des interactions UI côté navigateur.

Pour être direct, je suis devenu un grand adepte d'Alpine.js et j'ai pris un peu de recul par rapport à HTMX. Je vais vous expliquer pourquoi, sans filtre.

1. Prérequis : HTMX vs Alpine.js en un coup d'œil

Avant d'entrer dans le vif du sujet, j'ai préparé un tableau comparatif rapide pour ceux qui ne seraient pas familiers avec ces deux concepts.

2. Les 4 raisons pour lesquelles j'ai fini par éviter HTMX

À première vue, HTMX semble très pratique. Cependant, plus je l'intégrais profondément dans mes projets, plus je rencontrais des points de friction avec mes préférences de développement.

① "Faut-il vraiment générer des fragments HTML côté serveur ?" (Le dilemme de la maintenance)

Pour utiliser HTMX, le serveur (Django) doit retourner des snippets HTML plutôt que du JSON. Cela ne correspondait pas vraiment à ma philosophie. * Mon point de vue : "Le serveur devrait se contenter de fournir des données propres, et le client devrait s'occuper du rendu. N'est-ce pas une séparation des responsabilités plus claire ?" * La position de HTMX : "Recevoir du JSON puis le rendre à nouveau est un gaspillage. Le serveur fournissant le résultat final est la source unique de vérité (SSOT)."

En ajoutant des conditions comme if request.htmx: dans les templates Django, j'avais l'impression que la logique des vues devenait fragmentée et désordonnée.

② La logique AJAX n'est-elle pas déjà assez simple ?

Les attributs hx-get et hx-target de HTMX sont un excellent « sucre syntaxique ». Cependant, pour quelqu'un qui a déjà implémenté AJAX avec Vanilla JS ou ses propres fonctions utilitaires, ils ne sont pas indispensables. L'API fetch des navigateurs modernes est vraiment puissante. Écrire une seule ligne de fetch à l'intérieur de x-init d'Alpine.js suffit à produire un code déclaratif et propre. J'ai donc ressenti moins le besoin de suivre les règles d'une autre bibliothèque.

③ La rupture fatale de la "Locality of Behavior (LoB)"

J'aime beaucoup Alpine.js. C'est parce que l'on peut voir immédiatement ce que le code fait, directement sur place. Mais HTMX est différent. * Alpine.js : Le comportement est défini directement dans le HTML, et le résultat se produit instantanément dans la mémoire du navigateur. * HTMX : Le comportement est défini dans le HTML, mais pour voir le résultat (le fragment HTML), il faut aller fouiller dans le code du serveur (views.py).

J'ai trouvé cette rupture de contexte très inefficace. La nécessité constante d'ouvrir les fichiers backend en lisant le code, cette gêne, a été l'une des raisons décisives pour lesquelles j'ai évité htmx.

④ La gêne d'une latence (Latency) subtile

HTMX part du principe que toutes les interactions impliquent un aller-retour réseau.

Aussi rapide que soit le serveur, il ne peut égaler la réactivité instantanée d'Alpine.js qui opère directement dans le navigateur. Ce micro-délai de 0,1 à 0,2 seconde ressenti lors d'un clic était, pour moi, un facteur assez irritant en termes d'expérience utilisateur.

En conclusion : Qu'en pensez-vous ?

En résumé, je préfère une architecture où les données transitent via une API (JSON) et où l'interface utilisateur réagit instantanément dans le navigateur. C'est pourquoi j'apprécie particulièrement la combinaison d'Alpine.js et de DRF (Django REST Framework).

Ce qui est intéressant, c'est que j'ai récemment constaté sur des communautés comme Reddit de nombreuses opinions exactement opposées aux miennes. Beaucoup trouvent Alpine.js complexe et préfèrent revenir à HTMX, voire à une combinaison jQuery + HTMX. Il est clair qu'actuellement, la popularité de HTMX semble écrasante.

Bien sûr, HTMX est un excellent outil. Il ne correspondait simplement pas à mon style de développement et à ma manière de concevoir les systèmes. Je crois fermement qu'il n'y a pas de bonne ou de mauvaise réponse, seulement ce qui vous convient le mieux.

Et vous, qu'en pensez-vous ? Êtes-vous satisfait de la philosophie centrée sur le serveur de HTMX, ou préférez-vous, comme moi, les réponses JSON et la réactivité instantanée d'Alpine.js ? Partagez vos avis en commentaires !

Peut-être ai-je mis HTMX de côté trop tôt, avant d'en saisir toute la puissance ?