HTMX go ou nogo - Ekino FR

9 Minutes read

Résumé

Dans le cadre de nos développements, nous souhaitons évaluer si HTMX peut être un choix pertinent pour nos projets. Notre objectif est de réduire les ressources et le temps nécessaires au développement. Actuellement, un projet nécessite l’intervention d’une ressource back-end et d’une ressource front-end, ou bien fullstack. HTMX permettrait-il d’avoir uniquement besoin d’une ressource, et simplifier notre travail ?

Dans un premier temps, nous allons lister les avantages et les inconvénients de l’utilisation de HTMX par rapport à un framework tel que ReactJS, Vue.js, et nous analyserons quelques cas limites et d’utilisation.
Dans un second temps, nous nous intéresserons à l’évolution de HTMX, sa popularité ainsi que son utilisation en production.

Qu’est-ce que HTMX ?

HTMX est une bibliothèque JavaScript qui permet de créer des interfaces utilisateur web riches et interactives en utilisant uniquement du HTML avec des attributs propres à cette librairie. En d’autres termes, HTMX nous permet de bénéficier des fonctionnalités des applications web modernes (AJAX, WebSockets, transitions CSS, etc.) sans avoir à écrire une ligne de JavaScript complexe.

HTMX introduit de nouveaux attributs HTML permettant d’ajouter de l’interactivité à la page.

Par exemple :

hx-(get|post|put|delete) : Pour effectuer une requête ajax lors de l’interaction sur un élément
hx-trigger : Pour définir l’interaction sur un élement: (click, …)
hx-swap : Pour définir l’emplacement où sera chargé le contenu (par défaut innerHTML)

HTMX étend et généralise l’idée centrale du HTML en tant qu’hypertexte, ouvrant ainsi de nombreuses possibilités directement dans le langage :

Tous les éléments du DOM, pas seulement les ancres et les formulaires, peuvent émettre une requête HTTP.
Tous les événements, pas seulement les clics ou les soumissions de formulaires, peuvent déclencher des requêtes.
Tous les verbes HTTP, pas seulement `GET` et `POST`, peuvent être utilisés.
Tous les éléments du DOM, pas seulement la fenêtre entière, peuvent être la cible de la mise à jour par la requête.

Avantages et Inconvénients

On souhaite pouvoir comparer les avantages et inconvénients de HTMX vs un autre framework frontend très utilisé actuellement.
Le choix s’est porté sur React car c’est l’un des framework front-end les plus utilisé dans le monde professionnel selon l’enquête State of JS.

Afin de les comparer nous avons listé un certain nombre de critères (complexité, expérience de développement, …) pour détailler cette comparaison.
Ces critères sont listés dans le tableau ci-dessous et sont un sous-ensemble de tous les critères possibles.

Avantages et inconvénients par critère

Conclusion

En résumé basé sur le tableau précédent choisissez :

HTMX si vous privilégiez la simplicité, la rapidité de développement, et que votre application a des besoins en interactivité modérés, car l’un des principaux points faibles concerne les fonctionnalités limitées pour les interactions complexes côté client. C’est un bon choix pour des améliorations progressives de sites existants et pour limiter les dépendances à mettre à jour dans le futur.
React si vous avez besoin d’une application web complexe, des interactions utilisateur très riches et sophistiquées, avec une forte scalabilité et un écosystème riche.

Nous allons par la suite rentrer plus en détail sur les limites pouvant être amenées par l’utilisation de HTMX.

Limites & Cas d’utilisation

Augmentation de la responsabilité côté backend

HTMX à contre courant des frameworks JS

La particularité d’HTMX est d’attendre du code au format HTML afin de le placer tel quel dans le DOM. Cela implique la prise en charge du routing, du templating et du styling par le backend, en plus des responsabilités d’accès à la DB, auth etc…

On s’attend alors à ce que l’intégralité du code soit généré côté serveur en soustrayant par la même occasion la séparation front/back.

Posant peu de problèmes pour un projet à petite échelle, dès lors qu’il se complexifie, il devient de plus en plus coûteux de le faire évoluer. Des projets modulaires au besoin métier grandissant (dans une organisation agile par exemple) peuvent rapidement devenir plus complexes que de raison faute d’une organisation ou architecture adaptée.
L’utilisation d’HTMX devient alors une problématique organisationnelle/structurelle pour des équipes d’ingénierie dont les membres sont spécialisés soit côté frontend, soit côté backend.

Plusieurs possibilités d’adaptation se présentent alors :

Séparer la logique backend de celle du frontend au sein d’un même projet.
Séparer la partie backend et la partie frontend dans des services différents : la logique frontend serait reportée dans un service à part et le backend fournirait une réponse en JSON, traitée par le middleware pour le client web. Bien que cette solution présente un certain confort, cela va à l’encontre de la volonté d’HTMX de s’extraire à JSON.
Revenir à une vision fullstack de l’organisation des projets web. Cette dernière solution prône une maîtrise globale de la stack technique au détriment d’une spécialisation des ingénieurs. Elle correspond alors davantage à la philosophie d’HTMX.

En apportant de telles responsabilités supplémentaires côté backend, l’utilisation d’HTMX nécessite d’adapter l’organisation et la structure des équipes afin de casser les silos et contrats existants entre backend et frontend.

Le défi du développement cross plateforme

Contrairement à HTMX, les applications mobiles ou SPAs, attendent généralement une réponse en JSON. Dans le cas d’applications cross plateforme, on s’attendrait alors que le serveur fournisse une réponse en JSON, en plus de celle en HTML.

Plusieurs possibilités s’offrent à nous :

Doubler les réponses possibles à l’aide du champ Accept du header des requêtes HTTP. Le serveur devra prévoir une réponse en JSON pour la valeur application/json et une en HTML pour la valeur text/html. Des outils comme kitajs peuvent simplifier cette étape.
Migrer la logique frontend dans un service ou middleware consommé par le client web. Ce BFF (Back For Front) aurait la tâche de remplir les fonctionnalités de styling et templating en fonction de la requête client et des réponses JSON du serveur.
Utiliser l’extension client-side-templates dans la logique frontend permettant d’utiliser des syntaxes comme mustache pour interpréter du JSON. Bien que ceci résolve la problématique, cela défait le fondement philosophique d’HTMX se voulant basé uniquement sur de l’hypertexte.

Pour de tels projets, l’utilisation d’HTMX pourrait se révéler contreproductive : l’ensemble des solutions présentées nécessitent une mise en place coûteuse. Une charge de travail sera requise pour fournir une réponse différente en fonction du client.

Accessibilité : les illusions de simplicité pour les non-front-enders

L’accessibilité est l’une des parties clés d’une bonne expérience utilisateur (UX) et essentielle dans le développement web. Les développeurs doivent adapter les applications aux personnes ayant divers handicaps : déficiences visuelles et auditives, problèmes de mobilité et cognitifs. Un bon site web accessible repose sur trois points (la liste n’est pas exhaustive) :

HTML sémantique, qui est également bon pour le référencement (SEO),
Attributs ARIA (Accessible Rich Internet Applications) pour transmettre les interactions courantes aux technologies d’assistance,
Navigation au clavier.

Ces points sont-ils tous applicables à une application utilisant HTMX ? En général, oui. Comme HTMX est axé sur le HTML, l’utilisation d’une sémantique appropriée semble logique : plus nous l’utilisons, mieux nous le faisons. De plus, les attributs ARIA sont largement disponibles pour les applications pilotées par HTMX comme pour toutes les autres. Pour l’instant, tout semble bon. Mais, il y a toujours un “mais”.

HTMX essaie de modifier le comportement de certains attributs et éléments, comme click ou submit. Ces éléments sont souvent utilisés par les lecteurs d'écran et autres technologies pour garantir l'accessibilité d'un site, donc les modifier signifie créer plus de problèmes dans un écosystème déjà stable. Et regardons cet exemple tiré de la documentation HTMX :

<div hx-get="/clicked" hx-trigger="click[ctrlKey]">
  Control Click Me
</div>

Ici, nous sommes censés créer un div cliquable. Malheureusement, il n'est pas focalisable et n'indique pas son objectif aux lecteurs d'écran.

En ce qui concerne les attributs ARIA, ils fonctionnent généralement correctement dans HTMX, mais c’est la responsabilité absolue du développeur de les ajouter et de les maintenir. Pendant ce temps, dans React, nous pouvons utiliser l’une des dizaines de bibliothèques, ce qui simplifie la vie des développeurs, assure une application stable et cohérente. Il en va de même pour la navigation au clavier : HTMX permet de définir des raccourcis clavier pour différentes actions (bien qu’ils ne soient pas exempts de problèmes), mais cela reste toujours de la responsabilité du développeur, alors que React dispose de nombreuses bibliothèques correspondantes.

Maintenant, le développement avec HTMX ne semble plus si rapide et facile ?

Le problème avec HTMX est qu’il semble facile et rapide à apprendre, ce qui incite de nombreux non-développeurs front-end à se lancer dans la création de la partie client des applications et des sites. Juste pour découvrir la partie immergée de l’iceberg.

Un équilibre fragile

javascript fatigue :
longing for a hypertext
already in hand

HTMX est un outil formidable pour une mise en place de sites web simples. Comme défendu sur le site officiel, une grande partie des sites utilisent des outils bien plus complexes qu’ils ne devraient, se tournant vers des frameworks JavaScript (Angular, Next, Vue.js …) plus par dépit que par choix. De son côté, HTMX défend une vision du développement web loin des frameworks et avec le moins de JavaScript possible. En résulte des sites rapides et très légers.

Cependant, dès lors qu’un projet gagne en complexité et que les règles métiers s’affinent, HTMX comme unique outil, est vite dépassé. On devra alors faire appel à des extensions d’HTMX, des librairies tiers ou pire, du JavaScript vanilla (exemple : gestion d’état côté client).

Afin d’exploiter pleinement les possibilités offertes par HTMX, il faut donc tenir compte de l’équilibre entre la simplification technique et la complexité fonctionnelle pour ne pas transformer son projet en plat de spaghetti non maintenable.

Ainsi HTMX reste le parfait candidat pour des projets d’application simples de type gestion de tâches, des formulaires simples ou encore un back-office. Il serait cependant contre productif de l’employer pour du e-commerce, ou une application web en temps réel.

Popularité et utilisation

Popularité de HTMX

HTMX est un projet qui a démarré en avril 2020, qui est basé sur le projet intercoolerJS 2.0 qui lui même date de 2013.

Sa popularité est en évolution rapide depuis mi 2023, ci-dessous un graphique qui montre l’évolution du nombre de GitHub stars du projet.

Même s’il est plus populaire que jamais, cela ne signifie pas forcement qu’il a une place importante dans le web ou bien dans les frameworks frontend.

Regardons deux sources de données :
– Stack overflow dev survey 2024
– State of JS 2024 survey

Sur Stack Overflow, HTMX est la 20ème technologie web avec 3,3 % d’utilisation selon le sondage. Et reste loin derrière React, Vue.js, Next.js, Svelte, AngularJS

On peut recouper ces informations avec State of JS’s 2024 survey qui montre que HTMX arrive en 9ème position des framework front end avec 2% d’utilisation au travail selon les données du sondage.

En conclusion HTMX est encore pour le moment peu utilisé et la tendance entre 2023 et 2024 est restée identique.

Intérêt pour la technologie

Selon Stack Overflow, 73% des développeurs qui utilisent HTMX souhaitent continuer à l’utiliser.

Lorsque nous examinons les réponses de l’enquête State of JS 2023, qui privilégie davantage les ingénieurs frontend, nous obtenons une histoire légèrement différente.
Ici, HTMX arrive en 5ème position avec un sentiment positif à 40,9%. Derrière ReactJS avec 72%, Vue.js, Angular, Svelte.

Cette différence d’opinion entre les ingénieurs orientés frontend et les ingénieurs fullstack/backend est logique.
HTMX est principalement un facilitateur pour les personnes qui aiment le rendu côté serveur (souvent sous la forme d’applications monopages — MPAs).
Si vous êtes déjà satisfait de l’état actuel du frontend aujourd’hui (principalement des SPAs), il est peu probable que vous soyez intéressé par l’adoption d’HTMX.

Autre point : une nouvelle stack technique BETH (Bun, Elysia, Turso, Htmx) intègre HTMX. Faire partie d’une stack technique est une chose positive pour une technologie car elle fournit un ensemble complet d’outils pour un développeur.
BETH est performant, facile à apprendre et léger par rapport à MERN (MongoDB, Express.js, React, Nodejs). Cependant, il manque encore de maturité et de fonctions intégrées, laissant de nombreuses questions à résoudre à la charge du développeur.
Il faudra voir dans l’avenir si l’adoption de cette stack s’accentue.

Utilisation en production

En ce qui concerne l’utilisation, nous avons trouvé peu de ressources sur les cas en production.

Le blog htmx mentionne un projet ayant duré environ deux mois pour une base de code de 21 000 lignes, principalement en JavaScript :

L’expérience utilisateur (UX) de l’application n’a subi aucune réduction.
La taille de la base de code a été réduite de 67% (passant de 21 500 à 7 200 lignes).
Le code Python coté serveur a augmenté de 140% (passant de 500 à 1 200 lignes), ce qui est positif pour ceux qui préfèrent Python à JavaScript.
Les dépendances JavaScript ont été réduites de 96% (passant de 255 à 9).
Le temps de compilation web a été réduit de 88% (passant de 40 à 5 secondes).
Le temps de chargement initial interactif a été réduit de 50 à 60% (passant de 2 à 6 secondes à 1 à 2 secondes).
L’utilisation de la mémoire de l’application web a été réduite de 46% (passant de 75 Mo à 45 Mo).

Un cas publié sur LinkedIn, OpenUnited (2023) :

La taille de la base de code a été réduite de 61% (passant de 31 237 lignes à 12 044 lignes).
De manière subjective, la vitesse de développement a été ressentie comme étant au moins 5 fois plus rapide.

Nous avons trouvé peu de cas d’échec pour le moment, ceux-ci sont moins diffusés par les entreprises en général.
Un récit d’un développeur migrant de HTMX vers Hotwire en raison de nombreux problèmes, montre cependant que l’herbe n’est pas toujours toute verte.
Il aurait été intéressant de pouvoir confronter des cas où un retour en arrière aurait été effectué suite à des limitations dans le développement des fonctionnalités attendues par le client.

Conclusion

HTMX est une bibliothèque JavaScript qui permet de créer des interfaces utilisateur web riches et interactives en utilisant uniquement du HTML. Elle présente plusieurs avantages, notamment la simplicité d’utilisation et la réduction du code JavaScript nécessaire. Cependant, elle a aussi des inconvénients, comme une gestion limitée des interactions complexes et des défis en termes de développement cross-plateforme.

Devriez-vous utiliser HTMX dans votre prochain projet ?

Oui, si vous avez une solide compréhension des parties front-end et back-end du développement web, si votre projet est simple et ne nécessite pas de développement d’interaction complexes côté front end ultérieur. En même temps, il est très probable que HTMX disparaisse bientôt en tant que bibliothèque indépendante. Dans leur dernière communication, les créateurs de HTMX ont déclaré qu’ils visent à intégrer les concepts de HTMX dans le HTML général, de sorte que HTMX en tant que plateforme disparaîtrait (dans le monde idéal). Cela se produira-t-il bientôt ou plus tard ? Nous verrons bien, mais de toute façon, les développeurs de HTMX ne prévoient pas d’implémenter de nouvelles fonctionnalités dans les années à venir.

Remerciements

Merci ekino et à l’équipe Node.js de nous avoir permis de mener cette étude. Un remerciement particulier à Guillaume Claverie et Tatiana Lekhatkova pour leur temps et leur motivation.

HTMX go ou nogo was originally published in ekino-france on Medium, where people are continuing the conversation by highlighting and responding to this story.