HTMX : l'alternative légère à React

Qu'est-ce que HTMX, au juste ?

HTMX est une petite bibliothèque JavaScript (moins de 14 ko non compressée) qui permet d'accéder aux capacités des navigateurs modernes directement depuis vos attributs HTML, sans écrire de JavaScript. L'idée de base : plutôt que de charger toute une page, vous faites des requêtes au serveur et vous mettez à jour les portions de la page qui changent.

Concrètement, au lieu d'écrire :

fetch('/api/data').then(r => r.json()).then(d => document.querySelector('#result').innerHTML = d.html)

Avec HTMX, vous écrivez simplement :

<button hx-get="/api/data" hx-target="#result">Charger</button>

Et c'est le serveur qui retourne directement du HTML pour remplacer la zone indiquée. Voilà. C'est simple, naturel, et cela fonctionne dans tous les navigateurs modernes.

Pourquoi React est-il devenu si lourd ?

React est un excellent outil. Il excelle pour les applications très interactives où l'interface change constamment sans rechargement serveur : des outils collaboratifs type Figma, des tableaux de bord temps réel, des applications bureautiques web.

Mais React a un coût. Un projet React minimal inclut :

• La bibliothèque React elle-même (40+ ko)
• ReactDOM (10+ ko)
• Un bundler (Webpack, Vite, Parcel)
• Du transpiling (JSX vers JavaScript)
• La gestion d'état (Redux, Context, Zustand...)
• Des dépendances satellites

Le JavaScript final envoyé au navigateur dépasse rapidement 200 ko. Cela signifie : temps de chargement plus long, plus de batterie consommée sur mobile, plus de CPU, plus de complexité à maintenir.

Pour un site vitrine, un formulaire de contact, un blog, un catalogue produit, c'est simplement du gaspillage. La plupart des interactions sur ces sites sont des appels serveur classiques : soumettre un formulaire, charger plus de contenu, filtrer une liste. HTMX fait exactement cela, sans surcharge.

Comment fonctionne HTMX concrètement

HTMX s'appuie sur une philosophie : l'hypermedia, c'est-à-dire du HTML enrichi avec des attributs spéciaux. Ces attributs disent au navigateur comment interagir avec le serveur.

Les cas d'usage courants :

• hx-get : Faire une requête GET et remplacer une partie de la page
• hx-post : Soumettre un formulaire en AJAX (sans rechargement)
• hx-put / hx-patch / hx-delete : Appels REST standards
• hx-trigger : Déclencher sur un événement (click, change, entrée utilisateur...)
• hx-swap : Contrôler comment remplacer le DOM (innerHTML, outerHTML, avant/après...)
• hx-select : Sélectionner une partie spécifique de la réponse

L'avantage majeur : votre serveur envoie du HTML, pas du JSON. Vous codez en arrière-plan comme avant (Python, PHP, Ruby, Node.js...), en générant du HTML. Vos templates serveur font tout le travail. C'est une approche que les développeurs full-stack connaissent depuis 20 ans.

Exemple : ajouter un article à une liste sans rechargement. Avec HTMX, le formulaire envoie les données, le serveur crée l'article en base, retourne le HTML du nouvel article, et HTMX l'ajoute au DOM. Zéro ligne de JavaScript.

Comparatif : HTMX vs React

Les chiffres sont indicatifs mais révélateurs. React brille dans les cas critiques de haute interactivité. HTMX gagne sur tout le reste.

Quand choisir HTMX plutôt que React

HTMX est idéal pour :

• Les sites vitrines et blogs avec quelques touches interactives (formulaires, filtres, recherche).
• Les applications métier simples : CRM léger, tableau de gestion, interface d'administration.
• Les MVPs et prototypes quand vous testez un marché et que la vitesse compte.
• Les équipes petites sans spécialistes JavaScript, travaillant surtout en backend.
• Les projets avec contraintes d'infra (serveurs limités, bande passante réduite).
• Les sites avec beaucoup d'utilisateurs mobiles où chaque kilobyte d'économie compte.

React reste préférable pour :

• Les applications très interactives (tableaux collaboratifs, outils créatifs, jeux web).
• Les applications offline-first où le client doit fonctionner sans serveur.
• Les équipes expertes en JavaScript avec une architecture bien établie.
• Les projets où le frontend est une priorité stratégique (par ex. une startup SaaS).

Limites et considérations

HTMX n'est pas une baguette magique. Quelques limites à avoir en tête :

Charge serveur : Avec HTMX, le serveur traite plus de requêtes (même s'elles sont légères). Si votre infra est déjà au limite, il faut le prévoir.

Pas d'offline : L'app ne fonctionne pas sans connexion. Pour un site informatif, ce n'est pas grave. Pour une app métier, c'est un problème.

WebSockets pour le temps réel : Les notifications temps réel (notifications push, mises à jour live) nécessitent WebSockets. HTMX + WebSockets, c'est possible mais moins "magique".

Écosystème plus petit : Moins de composants pré-bâtis, moins de libs satellites. HTMX est jeune comparé à React.

Expérience de développement : Aucun devtools React, aucun hot reload natif. C'est du HTML classique, memes outils que avant.

Malgré ces points, pour la grande majorité des projets web professionnels en France (TPE, PME, freelances), HTMX est non seulement viable mais souvent supérieur à React.

Par où commencer

Si HTMX vous tente, voici un plan concret :

• Essayez sur un petit projet : Un formulaire, une liste filtrable, un mini-admin. Vous verrez comment ça marche avant de vous engager.
• Choisissez votre backend : Python (Django, Flask), PHP (Laravel, Symfony), Ruby (Rails), Node.js (Express, Fastify)... tous fonctionnent très bien avec HTMX.
• Utilisez vos outils habituels : Vos templates Jinja2, Blade, ERB, EJS. HTMX retourne simplement du HTML, pas de révolution.
• Apprenez les attributs HTMX : Une douzaine suffisent pour 80% des cas. La doc officielle est excellente.
• Oubliez le JavaScript : Essayez de ne pas en écrire. Si vous en écrivez beaucoup, vous aller à contre-courant de la philosophie.

Comptez 2-3 jours pour une équipe de développeurs expérimentés pour maîtriser les bases.