HTMX, l’anti-thèse des framework JavaScript (vs React)

HTMX est à l'opposé de React et des autres frameworks JavaScript. Qu'est-ce que je veux dire par là ? Et quand est—il préférable d’utiliser HTMX plutôt qu'un framework frontend ? Nous allons couvrir ce qu'est HTMX, quand il est utile, et ses limites.

Premièrement : qu'est-ce que HTMX ?

HTMX a été créé par un certain Carson Gross, et signifie HTML extension, comme expliqué sur son site web. L'extension du HTML se fait à deux niveaux.

Extension 1 : syntaxe HTML

L'extension la plus évidente est celle que nous voyons dans le code : HTMX étend les attributs HTML, en ajoutant hx-, par exemple dans ce code :

<div hx-on:click="alert('Clicked!')">Click</div>

Cependant, cet exemple est une exception : la plupart des extensions HTMX sont axées sur la communication avec le serveur et le traitement de la réponse. Par exemple, penchons-nous sur le code suivant :

<div>
    <button hx-get="/info" 
            hx-target="#info-details" 
            hx-swap="outerHTML">
        Obtenez des informations !
    </button>
</div>

Nous avons ici trois attributs : hx-get décrit l'appel AJAX qui sera fait au serveur, à savoir l'appel GET à la route /info.

Lorsque la réponse est reçue, HTMX va trouver l'élément dans le DOM désigné par hx-target, c'est-à-dire l'élément avec l'id info-details.

Puis, comme hx-swap est réglé sur outerHTML, HTMX remplacera tout l'élément sélectionné par le HTML reçu du serveur.

Extension 2 : HTML comme message et comme état

Cela m'amène à la deuxième extension. Dans le monde React, nous utilisons la page HTML comme la "chose qui héberge l'application".

Mais ici, HTML est plus que cela. HTMX suppose que le serveur répondra avec du HTML. Le HTML c’est aussi le message et l'état.

Comme moi, vous trouverez peut-être bizarre d'imaginer une API répondant en hypertexte plutôt qu'en JSON, par exemple. Le site web HTMX renvoie à un article de blog de Roy Fielding, qui est à l'origine de l'idée de REST. Ce billet s'intitule "REST APIs must be hypertext driven" - mes API REST doivent être en hypertexte, ce qui vous donne probablement une bonne idée de sa position sur la question. Et je comprends un peu son point.

N'oubliez pas que REST signifie “Representational State Transfer” ou transfert d’une représentation de l’état. Le JSON est excellent pour sérialiser des données de manière lisible. Mais on s’attend à ce que ces données suivent une forme fixe.

Cela signifie que le JSON ne changera pas de forme en fonction de l'état. Mais alors, dans quelle mesure peut-il être l'expression de l'état dans ReST, par opposition à de simples données sans état ?

Carson prend l'exemple d'une interface de compte bancaire, où l'action "retirer de l'argent" serait désactivée en fonction de la quantité d'argent sur le compte. Bien sûr, vous et moi pouvons facilement imaginer comment nous pourrions manipuler le JSON pour inclure cette information.

(J’en profite pour faire une petite parenthèse: on peut utiliser les headers de la requête pour indiquer à des APIs quelle format on accepte de recevoir en retour. On peut donc avoir des APIs qui répondent en JSON et en HTML selon les besoins.)

Mais mon réflexe serait d’implémenter une logique dans l'interface pour s'adapter aux données. Et ce n’est pas forcément un mauvais choix.

Mais, ce n’est pas la voie que HTMX a choisie. HTMX ne compte pas sur de la logique côté client pour mettre à jour l'état de l'interface en fonction du JSON.

En fait, HTMX évite cette responsabilité.

Il place volontairement la responsabilité de la mise à jour de l'état sur les épaules du backend, du serveur.

C'est pourquoi on pourrait dire que, même si c’est une bibliothèque JavaScript, HTMX est (en quelque sorte) un "anti-Framework JavaScript". Un framework JavaScript gère l'état sur le client et met à jour le code HTML en fonction de cet état.

HTMX s'appuie presque exclusivement sur le serveur pour mettre à jour l'état, et utilise du HTML pour exprimer l’état.

// DÉBUT DE LA COUPE DANS LA VIDÉO Il est évident que certains états sont totalement spécifiques à l'interface - par exemple, l'interface est-elle en mode sombre ? Ou le menu déroulant est-il ouvert ?

HTMX (et Carson) n'ont aucune objection à ce que cet état soit stocké côté client. Cependant, ils sont fortement opposés à ce que le client stocke un état plus significatif. // FIN DE LA COUPE DANS LA VIDÉO

Cela m'amène naturellement à la question suivante : Pourquoi choisir HTMX ? Dans quelles circonstances est-il judicieux d'opter pour HTMX plutôt que pour un framework côté client, par exemple React ou d’autres?

Ou, pour formuler les choses un peu différemment : quel est l'intérêt de HTMX ? Quel est l'intérêt de communiquer des réponses en HTML plutôt que du JSON ?

Deuxièmement, pourquoi choisir HTMX ?

La beauté du HTMX est qu'en agissant de la sorte, il permet de fournir une expérience de type "Application Mono Page” gérée par le serveur.

Vous savez bien sur que React a commencé à prendre des responsabilités côté serveur. React et NextJS et d'autres frameworks ont élargi le domaine des développeurs front-end. Ils ont donné au développement côté front des pouvoirs de gestion de l'état. Cela a commencé côté-client avec les frameworks front-end. Aujourd'hui, avec NextJS et RSC qui mènent la charge, ca comprend également le serveur.

Et c’est logique de fonctionner sur le serveur, puisque c'est là où résident les données permanentes.

L'avantage de cette approche est que vous n'avez pas besoin de changer de langage entre le côté client et le côté serveur. Changer de langage demande encore plus de gymnastique mentale que de changer de contexte, c'est pourquoi je suis en faveur de garder un environnement unifié.

Mais React côté serveur vous maintient fermement dans le monde JavaScript et TypeScript. Que faire si vous êtes un développeur backend qui se méfie des bizarreries de JavaScript ?

La beauté de HTMX est qu'il ne limite pas vos choix. Il se désigne lui-même de manière humoristique comme la stack "HOWL", où HOWL signifie "Hypertext On Whatever you'd Like" (hypertexte sur ce que vous voulez).

Cela signifie que vous pouvez rendre ce contenu HTML et fournir une expérience SPA avec le langage côté serveur de votre choix sans vous enfermer dans le monde JavaScript.

Cela signifie aussi que HTMX fait le contraire de ce que fait React, et c'est une autre raison pour laquelle HTMX est un anti "framework JS". HTMX étend le domaine du développement backend au territoire frontend.

Ainsi, pour moi, la question fondamentale de savoir qui pourrait tirer profit de l'apprentissage et de l'utilisation de HTMX se résume à deux choses.

Premièrement, où doit se situer votre état, et dans quelle mesure faites-vous confiance à vos utilisateurs ? Les applications web se situent sur un spectre allant des banques d'un côté aux jeux d'arcade de l'autre.

L'état d'un jeu d'arcade

• est complexe,
• il doit changer rapidement
• et n'a pas d'implications dans le monde réel,

il vit donc sur le client. Pour les applications avec un état et une logique côté client, il est logique d'utiliser un framework côté client.

À l'inverse, les banques ne font pas confiance à leurs utilisateurs, de sorte que tout l'état et toute la logique se trouvent sur le serveur. Si vous êtes dans cette situation, il est préférable d'utiliser HTMX plutôt qu'un framework front-end.

Pour formuler les choses différemment, la question est également la suivante : Quel type de développeur êtes-vous ?

Êtes-vous un développeur javascript front-end curieux du côté serveur ? Il est probablement préférable que vous compreniez comment NextJS et React fonctionnent.

Vous êtes un développeur côté serveur qui ne s'intéresse pas à JavaScript ? HTMX est probablement un bon choix pour vous, bien qu'il exige que vos API côté client parlent HTML. D'après mon expérience, ce n'est généralement pas le cas. Si vos API sont déjà configurées, le passage au HTML pourrait être une lourde tâche.