J'avais le réflexe de me tourner vers Vue.js. Chaque projet commençait de la même manière : installer le CLI, configurer le router, paramétrer le store, et envelopper le tout dans une structure d'application monopage (SPA). Peu importait que je construise un tableau de bord en temps réel ou un simple formulaire de contact. Vue était mon choix par défaut, et je supposais que tout ce qui était plus léger constituerait un retour en arrière.
Cette habitude est courante. Si vous avez passé des années au sein de l'écosystème React ou Vue, le modèle SPA semble inévitable. On finit par ne plus se demander si l'on a réellement besoin de toute cette machinerie. On l'utilise, tout simplement. Avec le temps, j'ai remarqué quelque chose de troublant. Je configurais des stores Vuex pour des écrans d'administration qui n'avaient besoin que de basculer un statut et de rafraîchir un tableau. Je composais une logique de récupération de données pour des pages de destination qui devaient simplement soumettre une adresse e-mail. La complexité ne venait pas des problèmes, mais de mon choix d'outil.
Puis j'ai commencé à utiliser HTMX. Le changement a été plus discret que je ne l'espérais, mais il a transformé ma façon de choisir ma pile technologique.
Ce que fait réellement HTMX
La plupart des discussions en ligne font fausse route. Les gens présentent cela comme une bataille entre Vue, React et HTMX. Cette comparaison passe totalement à côté du sujet. HTMX n'est pas un framework SPA. Il ne cherche pas à remplacer Vue. C'est une bibliothèque qui permet au HTML de faire plus que ce que le navigateur propose nativement.
Au lieu d'écrire un composant qui s'installe, récupère du JSON, le transforme en état local et re-rend une liste, vous ajoutez simplement un attribut à un bouton. Le serveur renvoie des fragments HTML, et non des charges utiles de données. Le navigateur remplace le contenu à la bonne place. Vous travaillez toujours avec des pages rendues côté serveur, mais vous obtenez l'interactivité que l'on associe généralement aux interfaces front-end JavaScript lourdes.
Ce n'est pas un déclassement. C'est un modèle différent. Vue vous demande de construire une application côté client et de gérer l'état dans le navigateur. HTMX vous demande de conserver l'état sur le serveur et d'envoyer du HTML sur le réseau. Comme ils résolvent des types de problèmes différents, les deux peuvent coexister dans un même projet sans conflit.
Quand Vue reste le bon choix
Les interfaces complexes nécessitent Vue. Si vous construisez un tableau de bord analytique en temps réel avec des widgets glisser-déposer, des filtres imbriqués et des graphiques en direct qui partagent des données entre plusieurs vues, vous avez besoin d'un framework réactif. Le navigateur doit posséder cet état. Vous ne voulez pas faire un aller-retour vers le serveur chaque fois qu'un utilisateur déplace un graphique ou change un groupe de filtres. Le modèle de composants, le système de réactivité et l'écosystème de Vue sont précisément conçus pour cela.
Il en va de même pour les applications grand public hautement interactives. Pensez à un outil de design, un tableau blanc collaboratif ou un séquenceur musical. Ce ne sont pas de simples documents avec des boutons. Ce sont des applications qui vivent dans le navigateur. Pour ce type de travail, Vue reste mon premier choix.
Là où HTMX prend le relais
Le gain le plus évident est apparu lorsque j'ai examiné les parties les plus rébarbatives de mes projets. Les panneaux d'administration ont été les premiers à changer. Un backend d'administration a généralement besoin d'un tableau d'enregistrements, de quelques boutons d'action, de filtres paginés et d'un formulaire ou deux. Rien de tout cela ne nécessite de DOM virtuel. Ce dont il a besoin, ce sont des mises à jour partielles rapides.
Avec HTMX, un bouton de suppression devient une balise avec les attributs hx-delete et hx-target. Cliquez dessus, le navigateur envoie la requête, le serveur répond avec une ligne de tableau rafraîchie.