HTMX, s’il vous plaît, essayez-le au moins une fois
(pleasejusttryhtmx.com)- Dans le développement web moderne, la fausse alternative entre HTML et les gros frameworks JavaScript pousse les développeurs vers une complexité inutile
- HTMX permet de gérer les requêtes AJAX, les mises à jour partielles et les transitions animées uniquement avec des attributs HTML, en appliquant directement à l’écran le HTML renvoyé par le serveur
- Sa structure permet une adoption progressive sans modifier en profondeur la base de code existante, ce qui réduit la complexité frontend et améliore la productivité et la maintenabilité
- Par rapport à une SPA basée sur React, des améliorations importantes ont été constatées en production sur le volume de code, les dépendances, le temps de build et la vitesse de chargement
- Plutôt que de choisir des frameworks excessifs, une approche simple fondée sur l’hypermédia est plus avantageuse à long terme pour la productivité et la maintenance
Le problème : un faux choix dans le développement web
- Dans les discussions sur le développement web, on ne cesse de répéter un choix extrême : soit n’utiliser que du HTML, soit adopter un gros framework comme React
- Le HTML pur est puissant pour les fonctions de base comme les liens, les formulaires ou
dialog, mais il a des limites en matière de mises à jour partielles et de réactivité immédiate - Choisir React, Vue ou Angular entraîne des centaines de dépendances, des builds lents et des débats complexes sur la gestion de l’état
- Même pour des applications simples centrées sur du CRUD, des dashboards ou des formulaires, on applique en pratique une boîte à outils excessive
Le concept clé de HTMX
- HTMX est un outil qui effectue une communication asynchrone avec le serveur en ajoutant des attributs spéciaux aux éléments HTML
- Par exemple, les attributs
hx-getethx-postpermettent d’envoyer des requêtes et d’insérer la réponse dans une zone précise du DOM
- Par exemple, les attributs
- Il étend le HTML pour que tout élément HTML puisse devenir l’émetteur d’une requête HTTP
- Le serveur renvoie non pas du JSON mais des fragments HTML tels quels, qui sont ensuite remplacés ou insérés automatiquement à l’endroit indiqué
- Le comportement est défini uniquement par déclaration d’attributs HTML, sans écrire directement de JavaScript
- La bibliothèque est très légère, avec une taille d’environ 14kb (gzip)
- Elle peut être appliquée directement à un document HTML existant sans outil de build ni configuration de framework
- La structure s’accorde bien avec une approche traditionnelle du développement web centrée sur le rendu serveur
Principales fonctionnalités
- Gestion des requêtes AJAX : exécuter des requêtes GET et POST uniquement avec des attributs HTML
- Mise à jour du DOM : appliquer automatiquement à l’élément visé le HTML renvoyé par le serveur
- Gestion des événements : relier les appels serveur à des événements utilisateur comme le clic ou la saisie
- Gestion de l’historique : intégration avec les actions précédent/suivant du navigateur
Cas réel d’adoption et chiffres
- Contexte a migré un SaaS basé sur React vers Django + HTMX
- 67 % de réduction du nombre total de lignes de code (21 500 → 7 200)
- 96 % de réduction des dépendances JavaScript (255 → 9)
- 88 % de réduction du temps de build (40 secondes → 5 secondes)
- Amélioration de 50 à 60 % de la vitesse de chargement des pages
- Les deux tiers de la base de code ont été supprimés, et l’application s’en est trouvée meilleure
- Sans séparation rigide entre frontend et backend, tous les développeurs peuvent travailler en full stack
Réponses aux objections courantes
- « N’a-t-on pas besoin d’une gestion complexe de l’état côté client ? »
- En réalité, la plupart des cas se limitent à des formulaires, listes et éléments qui apparaissent au clic, et HTMX suffit largement
- Des outils collaboratifs en temps réel comme Google Docs sont une exception, mais la plupart des équipes surestiment la complexité de leurs applis CRUD
- « Et les avantages de l’écosystème React ? »
- Un écosystème immense mène aussi à des Go entiers de
node_modules, des choix sans fin et des débats sur la gestion d’état - Avec HTMX, l’écosystème se résume à un seul langage côté serveur choisi
- Un écosystème immense mène aussi à des Go entiers de
- « Une SPA n’est-elle pas plus rapide en ressenti ? »
- Au départ, il faut passer par le téléchargement, le parsing, l’exécution et l’hydratation d’un gros volume de JavaScript
- HTMX est rapide dès le chargement initial, puis conserve cette réactivité en ne remplaçant que les parties modifiées
- « Que faire si une fonctionnalité React spécifique est vraiment nécessaire ? »
- Dans certains cas, React peut effectivement être adapté
- Mais en pratique, on choisit souvent par habitude un outil nécessaire seulement pour une petite partie du problème global
- Pourquoi choisir HTMX ?
- Si les équipes échouent, ce n’est pas à cause d’un mauvais framework, mais d’un choix excessif de framework
- HTMX parie sur la simplicité, et sur le long terme, la simplicité favorise la maintenabilité et la productivité
Quand HTMX n’est pas adapté
- Outils d’édition collaborative en temps réel (Google Docs, Figma)
- Applications nécessitant des calculs massifs côté client (éditeur vidéo, outils de CAO)
- Architectures offline-first (même s’il est possible de combiner plusieurs approches)
- Cas qui exigent réellement un état d’interface complexe
- Mais êtes-vous vraiment en train de construire ce genre de chose ?
- N’êtes-vous pas simplement en train de créer un dashboard de plus, un panneau d’administration, un site e-commerce, un blog ou une appli SaaS composés surtout de formulaires, de tableaux et de listes ?
- Pour ce type de projet, HTMX est vraiment étonnamment efficace — au point de se dire : « Pourquoi avons-nous rendu ça aussi complexe ? » ou « Mon Dieu, j’ai perdu tellement de temps là-dessus »
Alors, essayez-le
- Vous avez déjà utilisé React, essayé Vue, et sans doute regretté d’avoir testé Angular, non ?
- Et vous avez probablement déjà touché au meta-framework à la mode cette semaine sur Hacker News
- Essayez simplement HTMX, au moins une fois
- Investissez-y une journée de week-end
- Choisissez un side project
- Ou un outil interne dont personne ne se soucie vraiment
- Ou ressortez ce projet que vous remettez toujours à plus tard en vous disant que vous le referiez un jour
- Ajoutez une balise
<script>et écrivez simplement un attributhx-get, puis vérifiez vous-même comment cela fonctionne - Au pire, vous n’aurez perdu qu’une journée de week-end
- Mais il y a de fortes chances que cela vous plaise
- Et plus probablement encore, vous vous demanderez pourquoi le développement web est devenu à ce point compliqué
8 commentaires
J’avais déjà assisté à une conférence sur le sujet à la PyCon, et je me souviens que l’intervenant avait lui aussi dit qu’il n’avait pas encore pu l’utiliser en production.
Rust, essayez-le au moins une fois ?
J’ai déjà essayé Alpine.js, mais la gestion d’état était nécessaire dans la plupart des cas...
À moins de concevoir dès le départ le backend pour qu’il gère l’état, je me souviens que c’était assez pénible de résoudre les états par étape, les états conditionnels, etc.
Je suis d’accord avec tout ce qui a été dit, mais je n’arrive pas à me mettre à htmx 😢
Avis Hacker News
Je suis le créateur de htmx. Merci pour l’attention apportée grâce à cet article un peu exagéré, mais je n’aime pas trop ce genre de hype
Il existe de nombreuses façons de créer des applications web, chacune avec ses avantages et ses inconvénients. J’ai résumé les points forts et les faiblesses de htmx dans cet article
Je recommande aussi vivement d’essayer Unpoly, une autre excellente bibliothèque orientée hypermedia
(ajout) En relisant l’article, je le trouve finalement meilleur que ce que je pensais. Cela dit, j’aimerais quand même que htmx soit abordé dans un registre plus posé
Mettre à jour des champs via un menu déroulant, créer des modales, faire une barre de recherche avec autocomplétion, tout cela est simple
Cela dit, la complexité des frontends RIA vient de la manière de mettre à jour le frontend lorsque les données changent.
Quelques ajustements côté backend sont nécessaires, et c’est encore mieux si l’on dispose d’une structure capable de gérer plusieurs mises à jour partielles ensemble
Je fais actuellement un projet perso avec Rails + Stimulus, et Stimulus me semble au contraire un peu excessif. Je me demande quand il faut choisir Inertia ou Stimulus
C’est un plugin Alpine.js qui ajoute des fonctions AJAX de base aux liens et aux formulaires
J’en ai assez des articles qui prétendent être meilleurs que React avec un exemple “Hello World”
N’importe quoi fonctionne bien sur un exemple trivial. Mais dans la réalité, on a surtout des backends avec beaucoup de dépendances et des UI complexes
Les démos de base sont bien, mais il faut montrer comment on peut étendre le système quand on ajoute des fonctionnalités plus complexes
On se demande où ajouter du JS, s’il faut une étape de build, et à quel point on se retrouve enfermé dans le paradigme de htmx
Ce n’est pas tellement meilleur que React, c’est juste une autre approche
Le paradigme consistant à remplacer une partie du DOM est très simple et intuitif
Exemple : effect-ts est puissant, mais même un simple affichage devient compliqué
Notre startup a adopté HTMX, mais au final nous sommes en train de basculer vers React
HTMX rend le traitement des réponses plus complexe, et chaque endpoint doit renvoyer plusieurs fragments HTML
Il manque de documentation et de retours d’expérience, ainsi que de bonnes pratiques à grande échelle.
React est mature et fonctionne aussi très bien avec le codage assisté par IA. HTMX convient aux projets simples, mais au-delà cela devient difficile
Chaque endpoint n’a qu’une seule responsabilité et l’Optimistic UI permet une réaction immédiate
Je garde une gestion des erreurs simple et j’utilise
hx-swap-oobau minimumL’essentiel dans un choix technique, c’est de minimiser les compromis
C’est pour cela que je privilégie une validation centrée sur le backend, le frontend se contentant de l’affichage
Je ne veux pas de SSR. Le backend ne fournit qu’une API JSON, et le frontend la consomme
À mon avis, le SSR est survendu. On dirait surtout une stratégie pour vendre des services cloud
L’exemple Demo 3 Live Search a un gros problème de saccades au scroll (jank).
Les résultats sont insérés directement dans le document, ce qui semble provoquer des recalculs permanents de mise en page
React est tout à fait correct. Même pour des projets simples, il n’y a pas forcément de raison d’apprendre un autre paradigme
À l’inverse, HTMX s’apprend en 15 minutes et peut servir pendant 10 ans
Historiquement, ce sont les paradigmes légers qui gagnent le marché. React a lui-même occupé ce rôle à une époque
Je ne suis pas tombé amoureux de HTMX mais de Alpine.js
Le concept consistant à améliorer (enhance) du HTML rendu côté serveur m’a immédiatement parlé
Menus déroulants, show/hide, tout est intuitif et ne nécessite aucune étape de build
C’est intuitif et facile à maintenir, même sur de gros projets
Quand on met du JS en inline dans le HTML, la maintenance devient difficile et la gestion de l’état reste implicite
J’ai le sentiment que Hotwire ou Stimulus sont bien meilleurs à l’échelle d’une organisation
Si l’on utilise HTMX dans une grosse application, je me demande ce qu’il en est de la charge serveur et des coûts
Comme le HTML est rendu côté serveur, cela semble plus lourd à traiter que du JSON
Il peut même être plus efficace que la sérialisation JSON, et il y a aussi un coût de désérialisation côté client
HTMX, utilisé avec des outils comme Alpine.js, permet aussi de gérer facilement des états complexes
Ce n’est pas adapté à tous les cas, mais dans beaucoup de situations, cela fonctionne très bien
L’évangélisation des frameworks est la pire culture de l’écosystème web
Si une solution est bonne, elle sera adoptée au final. Pas besoin de se comporter comme un évangéliste
Les attaques contre npm sont aussi exagérées. htmx finira de toute façon par utiliser npm
Le monde est plein de mauvaises solutions adoptées grâce au marketing et à la notoriété
Si l’on veut préserver un vrai sens de l’artisanat, il faut résister à ces biais
HTMX donne l’impression de cumuler les défauts des deux mondes
Le SSR est cohérent, le CSR est séparé, mais HTMX mélange les deux et crée un couplage implicite
Si l’on veut afficher les mêmes données sous un autre format, faut-il vraiment créer deux endpoints côté backend ?
Pour la plupart des applications, l’état du backend suffit, et hormis l’amélioration de l’UX, il n’y a pas de grand bénéfice supplémentaire
Si la page entière est construite côté serveur, les données s’y trouvent déjà
J’avais fait une présentation comme ça l’an dernier. Il n’y a pas eu grand monde pour l’écouter, mais bon ^^
https://www.slideshare.net/slideshow/htmx-2024/274315966
J’avais aussi créé quelque chose comme ça en mode PoC
https://github.com/iolo/hx
Mais au final, personne n’utilise htmx haha
C’est dommage de voir qu’une fois qu’on s’est habitué à une situation, et qu’un écosystème volumineux s’est constitué autour, tout se fige au point qu’il semble ne plus y avoir la moindre dynamique d’innovation.
Les slides sont sympas, c'est dommage de ne pas avoir pu voir la présentation haha