HTMX est attrayant car il permet aux équipes de construire des applications web interactives sans s'engager immédiatement dans une grande architecture d'état côté client.
C'est une grande affaire pour les applications où le travail consiste principalement en :
- formulaires
- tableaux
- filtres
- mises à jour partielles de pages
Dans ces systèmes, envoyer du HTML depuis le serveur est souvent un choix plus simple que de construire une API JSON parallèle plus une couche de rendu côté client pour tout.
La Proposition de Valeur
Une interaction simple peut rester simple :
<form hx-post="/settings/profile" hx-target="#profile-panel" hx-swap="outerHTML">
<input name="displayName" />
<button type="submit">Sauvegarder</button>
</form>
Le backend retourne du HTML mis à jour. HTMX le remplace à sa place. Il y a moins d'état client à synchroniser car le serveur reste la source de vérité pour les données et le balisage.
Où Cela S'intègre le Mieux
HTMX est le plus fort lorsque :
- le backend rend déjà des templates
- l'application consiste principalement en des interactions requête/réponse
- la complexité côté client dépasse actuellement les besoins du produit
Il est plus faible lorsque :
- l'interface utilisateur est fortement pilotée par le client
- le comportement hors ligne ou "local-first" est important
- l'interaction en temps réel est dense et étatful
C'est pourquoi HTMX n'est pas "meilleur que React". Il est meilleur que de construire excessivement une application client lorsque une application pilotée par le serveur ferait le travail plus proprement.
Compromis
HTMX vous donne moins de complexité côté client, mais aussi moins de contrôle sur le runtime client que les applications de style React excellent. La bonne décision dépend de la structure du produit, pas de quel camp est le plus bruyant en ligne.
Lecture Supplémentaire