HTMX est si génial que je l’ai recréé moi-même (2024)

• HTMX est une approche qui améliore progressivement le front-end à partir de HTML rendu côté serveur, dans la continuité des méthodes d’avant l’explosion des UI JavaScript modernes à la React
• Lors de la refactorisation serveur d’une podcast web app auto-hébergée, le remplacement de SvelteKit par DinoSsr a fait apparaître un problème où la navigation entre pages interrompait la lecture audio ; avec HTMX, il a été possible de ne mettre à jour que la zone `` afin de conserver le composant audio
• HTMX est distribué comme une bibliothèque front-end, mais une grande partie de son implémentation repose sur les templates back-end et la configuration du serveur, les requêtes HTTP renvoyant du HTML jouant en pratique le rôle d’API HTMX
• Les attributs hx-*, l’exemple de `` cliquable et certains exemples avancés riches en JavaScript inline illustrent les limites des templates d’attributs déclaratifs et quelques frustrations liées à la documentation
• La mini-implémentation maison s’appuie notamment sur le cache 304, la History API, le remplacement de `` et le préchargement fondé sur les événements pointeur, avec à la clé moins de JavaScript dans le navigateur et une base de code plus petite et plus simple

---

La place de HTMX

• HTMX rejette les UI JavaScript modernes au profit de HTML rendu côté serveur, dans une approche issue des pratiques d’avant l’hypertrophie des front-ends avec React
• Le scroll infini et les résultats de recherche en temps réel sont des exemples populaires de HTMX ; HTMX ne cherche pas à résoudre tous les problèmes que React et d’autres tentent d’adresser, et peut sembler limité, mais dans ce cadre il reste un outil de grande valeur
• HTMX n’est pas une « magic bullet », et l’idée essentielle est que certaines des idées derrière HTMX comptent davantage que HTMX lui-même

L’expérience

• La lecture de la documentation ne suffisait pas, il a donc fallu tester l’usage réel, et la cible de l’expérimentation HTMX était la refactorisation serveur d’une podcast web app auto-hébergée
• L’implémentation précédente reposait sur SvelteKit, un outil apprécié mais potentiellement trop lourd pour de petits sites web
• Le remplacement visait DinoSsr, un outil maison en cours de développement, également utilisé pour générer des sites statiques et alimenter un blog de bookmarks
• DinoSsr fonctionne principalement côté serveur et peut fournir des composants comme des « islands » front-end, mais sans prendre en charge les interactions de page complètes
• Le composant du lecteur audio doit rester présent pendant la navigation entre pages, car un rechargement complet de la page coupe très vite l’expérience d’écoute
• SvelteKit gérait les mises à jour de l’UI et le routage front-end, mais dans la nouvelle version seul le composant du lecteur audio utilisait du JavaScript côté client, DinoSsr ne cherchant volontairement pas à faire du routage client
• Sur quelques pages, seule la section `` change ; avec HTMX, il a donc été possible d’améliorer progressivement les liens et de ne mettre à jour que cette zone, sans recharger toute la page, afin de conserver le composant audio
• L’intégration de HTMX a bien fonctionné, mais il a rapidement été retiré au profit d’une mini-version maison basée sur les mêmes idées

Quelques réflexions sur HTMX

• Dans cette expérimentation, HTMX remplaçait Svelte côté front-end, mais pas comme un substitut plug-and-play à la manière de React : cela implique un vrai changement de perspective
• HTMX est distribué comme une bibliothèque JavaScript d’amélioration progressive du front-end, mais l’essentiel de l’implémentation se fait côté back-end, avec des templates serveur et une configuration à préparer soi-même
• Les requêtes HTTP qui fournissent du HTML jouent de fait le rôle d’une API HTMX, et les détails de configuration des en-têtes HTTP sont importants pour assurer un bon cache
• Il existe les attributs standard data-* et dataset, d’où une petite frustration face à l’usage d’attributs préfixés hx-* non standard
• La documentation de HTMX contient de nombreux exemples avec `` ; l’exemple ci-dessous montre une structure où, quand l’utilisateur clique sur un div, une requête PUT est envoyée à /messages puis la réponse est chargée dans ce même div

    Put To Messages

• Les exemples où l’utilisateur doit cliquer sur un élément `` sont critiqués comme peu souhaitables
• Certains exemples avancés de HTMX utilisant du JavaScript inline deviennent assez désordonnés et montrent les limites des templates d’attributs déclaratifs
• Indépendamment de ces critiques, HTMX fournit un ensemble de fonctionnalités limité mais utile, capable d’améliorer de nombreux patterns courants de web design

Le refaire soi-même

• Juste après avoir intégré HTMX avec succès, il a été supprimé puis remplacé par une mini-implémentation maison fondée sur les mêmes idées
• Pour permettre des requêtes fetch mises en cache, les en-têtes HTTP last-modified, if-modified-since et les réponses 304 ont été utilisés
• L’intégration de base avec l’historique repose sur pushState et popstate
• Du code a été ajouté pour extraire et remplacer l’élément ``, ainsi qu’un préchargement intégré inspiré de la preload extension de HTMX, basé sur les événements pointeur
• Ce préchargement fondé sur les événements pointeur démarre la requête fetch avant que l’événement click ne survienne, ce qui apporte un petit gain de performance
• Le code source expérimental reste très basique, mais montre bien qu’en réalité peu de JavaScript est nécessaire dans le navigateur
• Que ce soit avec HTMX ou avec une version « we have HTMX at home », le résultat est une base de code nettement plus petite et plus simple

JavaScript front-end

• Les templates et composants sont pratiquement indispensables à l’organisation et à la réutilisation du code dès qu’on dépasse le tout petit site web, et peuvent aussi être implémentés côté serveur en PHP, Ruby, Go, JavaScript, etc.
• Il n’est pas nécessaire de dupliquer cette structure dans le navigateur ni de l’implémenter uniquement dans le navigateur, même si la popularité de React et consorts a conduit beaucoup de développeurs à cesser de se poser la question
• La fatigue liée au JavaScript front-end est bien réelle et s’inscrit dans une expérience où l’on a continué à surconcevoir des UI JS tout en préférant les anciens templates serveur
• Même si HTMX en soi n’est pas jugé exceptionnel, sa philosophie reste une approche suffisamment forte pour faire honte aux développeurs JavaScript modernes

[GN⁺]

Avis sur Lobste.rs

• Petit pinaillage, mais je n’aime pas trop l’usage d’attributs HTML préfixés en hx-* là où on devrait utiliser data-* Htmx prend en charge depuis longtemps le préfixe data- Quant au fait qu’il ne faut pas pousser les utilisateurs à cliquer sur des éléments `` , le mieux est d’utiliser hx-boost de htmx sur les balises d’ancre et de formulaire. Comme cela améliore automatiquement ces balises de la bonne manière, on peut éviter les divs cliquables C’est un projet qui montre à quel point le navigateur a réellement besoin de peu de JavaScript, et la maintenance sera probablement minimale à l’avenir, avec très peu de correctifs de sécurité nécessaires. De quoi le féliciter

• Est-ce que HTMX ne maltraite pas le serveur puisqu’il rend tout ? Ça me rappelle un peu les problèmes de CGI qu’on connaissait autrefois

  • Presque certainement non. Les problèmes de CGI venaient surtout du coût de lancer beaucoup de processus à durée de vie courte, et cela a été résolu avec des choses comme FastCGI Générer du HTML n’est pas une opération particulièrement coûteuse, et il est difficile de dire que c’est plus cher que produire une quantité similaire de JSON dans une approche alternative
  • Je ne vois pas bien ce que veut dire « nous ». Mon blog est basé sur CGI, le serveur y rend le HTML, et il n’y a absolument aucun JavaScript Aucun problème depuis 1999, et comme toujours, il faut vérifier où se situe réellement le goulot d’étranglement avec du profiling
  • On appelle généralement ça du rendu côté serveur, mais en réalité c’est plus proche de la production de HTML brut sur le serveur. Le rendu effectif et la création du DOM sont toujours faits par le navigateur, comme cela a toujours été le cas Même en rangeant PHP dans la catégorie CGI, cela revient à passer à côté d’environ quinze ans de développement web où cette approche était la norme Il est vrai qu’on fait travailler davantage le serveur, mais je pense que la raison principale du déplacement de nombreux traitements vers le client relevait surtout d’un risque calculé pour réduire les coûts. Beaucoup d’utilisateurs finaux ne remarquent pas que le navigateur fait plus de travail, mais sur des appareils anciens ou peu performants, l’expérience s’est malgré tout dégradée, surtout au départ Cela dit, HTMX n’est pas du rendu côté serveur au sens strict. Au lieu d’une API qui envoie des données en JSON pour que le client les rende en HTML, le serveur envoie ces mêmes données sous forme de fragments HTML. Donc si le serveur souffre, c’est probablement dû à d’autres facteurs plutôt qu’au fait que cela consomme intrinsèquement plus de ressources qu’une API REST
  • Difficile d’être catégorique sans benchmark, mais j’imagine que c’est comparable. Dans les deux cas, au fond, on ne fait qu’émettre un tas de texte ; la différence est de savoir si le rendu de texte coûte plus cher que la génération de JSON D’après mon expérience, on a tendance à sérialiser davantage de choses avec JSON, mais je ne vois pas vraiment comment comparer cela correctement
  • Dans les applications côté serveur, il est rare que l’étape réelle de rendu HTML soit le goulot d’étranglement ; il se situe généralement avant

• Pour des raisons similaires, j’utilise alpine-ajax, très proche de htmx

  • J’aime aussi beaucoup alpine-ajax. Si je repartais de zéro pour « obtenir les avantages d’une SPA avec du SSR », c’est probablement vers ça que j’irais De toute façon, j’utilise déjà alpine pour les fonctionnalités réactives côté client. Simplement, il y a déjà beaucoup de htmx dans le dépôt, et je n’ai pas non plus de grief particulier contre htmx
  • J’utilise datastar, et c’était plutôt agréable à utiliser