HTMX : et si on avait réinventé le web en faisant marche arrière ?

Le constat : on a peut-être overdosé de JavaScript

Soyons honnêtes deux minutes. Pour afficher un bouton qui change de couleur au clic, combien de projets front-end modernes nécessitent aujourd'hui un build Webpack ou Vite, un state manager, trois hooks React et un fichier de config de 200 lignes ? On a collectivement glissé vers une complexité folle pour des besoins qui, historiquement, se réglaient avec trois lignes de HTML et un soupçon de JavaScript vanilla.

C'est exactement le constat que fait HTMX, une bibliothèque JavaScript ultra-légère (environ 14 Ko gzippés, sans aucune dépendance) qui propose une idée presque provocatrice : et si le HTML pouvait faire bien plus de choses qu'on ne le pense, sans avoir besoin de réécrire toute votre UI en composants réactifs ?

Le principe : étendre le HTML, pas le remplacer

HTMX part d'un postulat simple. Le HTML sait déjà faire des requêtes au serveur via les balises <a> et <form>. Le problème, c'est qu'il ne sait le faire que de façon limitée : un lien ne peut déclencher qu'un GET, un formulaire qu'un GET ou un POST, et le résultat recharge systématiquement toute la page.

HTMX débloque ces limitations directement via des attributs HTML. Vous pouvez désormais déclencher n'importe quelle méthode HTTP (GET, POST, PUT, DELETE, PATCH) depuis n'importe quel élément, sur n'importe quel événement (clic, survol, scroll, frappe au clavier...), et injecter la réponse où vous voulez dans la page, sans recharger quoi que ce soit.

Concrètement, ça donne ça :

<button hx-post="/api/like" 
        hx-target="#compteur" 
        hx-swap="innerHTML">
  J'aime ❤️
</button>

<span id="compteur">42</span>

Ici, un clic sur le bouton envoie une requête POST vers /api/like, et le serveur renvoie directement un fragment HTML (par exemple <span id="compteur">43</span>) qui remplace le contenu ciblé. Pas de JSON à parser, pas de state React à synchroniser, pas de re-render à gérer. Le serveur reste la source de vérité, et il répond... avec du HTML.

L'approche HDA : Hypermedia-Driven Applications

Ce concept porte même un nom : les Hypermedia-Driven Applications (HDA), popularisées par Carson Gross, le créateur d'HTMX, dans son livre Hypermedia Systems (disponible gratuitement en ligne, pour les curieux). L'idée centrale : au lieu de construire une API JSON consommée par un front-end JavaScript qui reconstruit lui-même le DOM, le serveur envoie directement des morceaux de HTML prêts à être injectés.

Ça casse radicalement avec l'architecture SPA classique où :

• Le front-end et le back-end sont deux applications séparées qui communiquent en JSON
• Toute la logique d'affichage est dupliquée côté client (components, templates JS)
• Il faut gérer un routeur côté client, un state global, des effets de bord...

Avec HTMX, vous gardez votre moteur de templates serveur préféré (Twig, Blade, Jinja2, EJS, peu importe), et vous lui demandez simplement de générer des petits fragments de HTML au lieu de pages entières. Le JavaScript, lui, se contente d'orchestrer les échanges.

Un exemple concret : la recherche en temps réel

Prenons un cas ultra classique : une barre de recherche qui filtre une liste au fur et à mesure que l'utilisateur tape, sans recharger la page. En React, ça implique généralement un useState, un useEffect, un debounce maison et un appel fetch. Avec HTMX :

<input type="text" 
       name="q"
       hx-get="/recherche" 
       hx-trigger="keyup changed delay:300ms"
       hx-target="#resultats"
       placeholder="Rechercher un article...">

<div id="resultats">
  <!-- les résultats arrivent ici -->
</div>

L'attribut hx-trigger gère nativement le debounce avec delay:300ms, et changed évite de déclencher une requête si la valeur n'a pas réellement changé (par exemple avec les touches fléchées). Côté serveur, la route /recherche reçoit simplement le paramètre q et renvoie le HTML des résultats filtrés. C'est tout. Pas de bundle JS additionnel, pas de dépendance à gérer dans un package.json qui grossit à vue d'œil.

Les vrais avantages, sans filtre marketing

Il faut être honnête : HTMX n'est pas une solution magique pour tout. Mais sur certains types de projets, les bénéfices sont réels :

• Simplicité architecturale : une seule application à maintenir, un seul langage de templating, pas de synchronisation entre deux bases de code.
• Performance perçue : les pages HTML pur restent indexables nativement par Google (bon point SEO), et le payload réseau est souvent plus léger qu'un gros bundle JS + réponses JSON à transformer.
• Courbe d'apprentissage douce : si vous connaissez le HTML et un minimum de back-end, vous êtes opérationnel en une après-midi. Pas besoin d'apprendre tout un écosystème (JSX, hooks, state management, routing côté client...).
• Progressive enhancement naturel : votre application fonctionne globalement même si le JS plante, puisque la base reste des formulaires et des liens HTML classiques.

Et les limites, alors ?

Soyons aussi lucides sur les contraintes. HTMX n'est clairement pas fait pour des interfaces ultra-interactives type éditeur vidéo en ligne, jeu en temps réel ou tableau de bord avec des dizaines d'états locaux complexes à gérer côté client sans aller-retour serveur. Pour ça, React, Vue ou Svelte restent largement plus adaptés.

De plus, l'approche demande une discipline différente côté back-end : vos routes doivent être pensées pour renvoyer des fragments HTML ciblés, pas juste du JSON brut. Ça implique souvent de revoir l'organisation de ses templates et parfois de multiplier les endpoints spécifiques à chaque interaction UI.

Enfin, l'écosystème est encore jeune comparé à React. Moins de composants préfabriqués, moins de tutoriels, moins d'outils de debug dédiés (même si des extensions navigateur commencent à apparaître).

Pour quels projets ça a du sens ?

Chez YouOnline, on voit clairement l'intérêt d'HTMX sur des projets où le serveur back-end est déjà costaud (sites vitrines évolués, back-offices métier, applications internes d'entreprise, plateformes de contenu) et où l'enjeu n'est pas de rivaliser avec Figma ou Notion en termes d'interactivité, mais plutôt d'offrir une expérience fluide sans la lourdeur d'une architecture SPA complète.

C'est aussi un excellent choix pour des équipes réduites ou des projets avec un budget maintenance limité : moins de code, moins de dépendances à mettre à jour, moins de surface d'attaque en termes de sécurité côté client.

En résumé

HTMX ne cherche pas à tuer React ni à relancer la guerre des frameworks. C'est plutôt un rappel salutaire que la complexité n'est pas toujours synonyme de modernité, et que parfois, la meilleure solution technique est celle qui retire des couches plutôt que d'en ajouter. Si votre prochain projet n'a pas besoin de la puissance d'une SPA complète, ça vaut clairement le détour de tester cette approche hypermedia qui, visiblement, a de l'avenir devant elle.