Et si le serveur renvoyait juste du HTML ? HTMX ramène l'interactivité web à sa forme la plus simple : des attributs, des fragments, zéro build.

Pendant que l'écosystème JavaScript évolue constamment, une lib de 14 ko a posé une simple question : et si le serveur renvoyait simplement... du HTML ? HTMX tient moins de la révolution technique que du retour à la raison, avec des attributs. L'Hyper Média tel que prévu au départ...

Le principe en une phrase

HTMX étend le HTML : n'importe quel élément peut déclencher une requête HTTP et remplacer un morceau de page par la réponse. Le serveur renvoie le HTML final, directement, pas du JSON qu'un framework devra re-transformer en HTML.

<button hx-get="/panier/ajouter/42" hx-target="#panier">
  Ajouter au panier
</button>
<div id="panier">3 articles</div>

Clic > GET > le serveur renvoie le fragment du panier mis à jour > HTMX remplace #panier. Pas de state manager, pas de virtual DOM, pas de sérialisation JSON aller-retour. Le HTML est l'état. Révolutionnaire, comme en 1995.

Ce que ça élimine concrètement

  • Le build. Pas de bundler, pas de transpilation, pas de node_modules de 400 Mo pour afficher un formulaire. Une balise script, terminé.
  • La duplication de logique. Avec une SPA, la validation, le routage et le templating existent deux fois : côté client et côté serveur. Avec HTMX, une seule fois, côté serveur, là où sont les données et la sécurité de toute façon.
  • Le JSON intermédiaire. Concevoir une API interne pour ta propre page, c'est écrire une lettre à ton coloc'.

Côté serveur : n'importe quoi qui parle HTTP

C'est le vrai super-pouvoir : HTMX est agnostique. PHP, Python, Go, même du CGI si tu es d'humeur nostalgique. En PHP, un fragment est un simple include qui rend un bout de HTML. Ton serveur détecte l'en-tête HX-Request pour renvoyer soit la page complète, soit le fragment seul : même template, deux modes de service.

if (isset($_SERVER['HTTP_HX_REQUEST'])) {
    include 'fragments/panier.php';   // fragment seul
} else {
    include 'pages/panier-complet.php'; // page entière
}

Bonus caché : sans l'en-tête, l'URL sert la page complète, donc les liens marchent sans JavaScript. Progressive enhancement gratuit, sans réunion d'architecture.

Les limites, parce qu'il y en a

HTMX n'est pas la réponse à tout. Une interface hautement interactive côté client (éditeur graphique, tableur, jeu) a besoin d'état local riche, et là un framework se justifie. De même, si ton produit EST une API consommée par plusieurs clients (mobile, partenaires), le JSON garde son trône.

Reste que la majorité des sites et outils métier sont des formulaires, des listes filtrables et des tableaux. Pour ça, une SPA c'est louer un semi-remorque pour déménager un studio.

Le confort psychologique du boring

Le bénéfice le plus sous-coté : la stabilité mentale. Pas de migration de framework tous les deux ans, pas de « la v19 déprécie ta façon de faire des composants ». Ton code HTMX de 2021 tourne encore. Ton savoir HTML/HTTP de 2005 est redevenu ta compétence principale. Pendant que d'autres apprennent la nouvelle API de rendu côté serveur de leur framework côté client (relis cette phrase), toi, tu livres.

HTMX rend le web plus honnête que moderne : des documents, des liens, des formulaires, et juste assez de magie pour que ça glisse. Parfois, la meilleure stack est celle qui te fout la paix.

FAQ

HTMX remplace-t-il React ou Vue ?

Pour les sites et outils métier classiques (formulaires, listes, tableaux), oui. Pour les interfaces à état client riche (éditeurs, jeux), non.

HTMX fonctionne-t-il avec PHP ?

Parfaitement : le serveur renvoie des fragments HTML, peu importe le langage. PHP + includes = système de fragments naturel.

Et le SEO avec HTMX ?

Excellent par construction : le contenu est du HTML rendu serveur, indexable directement, sans rendu JavaScript côté crawler.

← Retour au playground