- J’aime vraiment l’idée de base, simple et essentielle, de Htmx, mais après l’avoir utilisé à l’échelle de toute une équipe, nous avons constaté qu’en pratique ce n’est pas simple et que c’est assez complexe
L’héritage des attributs dans Htmx est clairement une erreur
- Dans les extraits de code, l’héritage des attributs est implicite et surprenant
- Comme en CSS, l’héritage est un hack peu coûteux, mais il a un prix
- Cela contredit l’argument de l’auteur sur la localité du comportement
- L’héritage par défaut diffère selon les attributs (par ex.
hx-delete n’est pas hérité, alors que hx-confirm et hx-ext le sont)
- Il faut mémoriser les exceptions et tout exprimer explicitement, ce qui rend l’héritage inutile
La plupart des applications web intéressantes ne peuvent pas remplacer entièrement les éléments du DOM
- Les éléments du DOM ont presque toujours un état local au navigateur (par ex. l’état ouvert/fermé d’un élément
<details>, la valeur saisie d’un élément <input>, l’état ouvert/fermé d’un menu déroulant)
- Si Htmx adopte l’approche simple consistant à remplacer directement le
outerHTML, tout cet état est perdu
- L’extension Morphdom écrase elle aussi certains éléments d’une manière différente de ce à quoi on s’attend
Stocker l’état dans les éléments du DOM eux-mêmes est une mauvaise idée
- Morphdom vise à résoudre la douleur décrite dans la section précédente, mais on découvre que le fonctionnement de Htmx repose sur le remplacement complet des éléments
- La file d’attente des requêtes est stockée dans les éléments du DOM eux-mêmes
- Lorsqu’une requête démarre, cet élément, ou un autre élément qui le cible, possède une file d’attente des requêtes
- Si l’on remplace complètement un élément du DOM, la file d’attente est réinitialisée, ce qui permet d’éviter certains mauvais modes d’échec
- Mais avec Morphdom, l’élément est conservé, donc la file d’attente aussi
- On se retrouve alors dans une sorte de zone de comportement indéfini qui viole la conception de Htmx
Le mode de file d’attente par défaut est un désastre
- Par défaut, Htmx annule une requête en cours si une autre requête est déclenchée sur la même file d’attente (élément)
- C’est la stratégie par défaut
- J’ai découvert ce fait plus tard
- C’est très peu intuitif, et cela signifie perdre du travail
Les déclencheurs d’événements ne sont pas locaux
- Les déclencheurs d’événements aident souvent à faire se produire quelque chose, mais ce sont des effets non locaux, avec des problèmes similaires à ceux de l’héritage des attributs
- Travailler sur une DSL dans un langage côté serveur peut aider dans une certaine mesure, mais cela donne une impression proche de l’ancienne programmation JavaScript à base de callbacks
- Quand un événement se produit, on « s’y abonne » puis on exécute une action
Il est difficile de bien préserver l’état des composants
- Un problème plus large, similaire à celui de l’état des éléments du DOM, est que vos propres composants ont eux aussi leur propre état
- Par exemple, si vous voulez une page composée de trois sections avec leur propre état nécessaire au serveur (par ex. la page d’un ensemble de résultats) ainsi que l’état requis par React ou par les Web Components, vous vous heurtez à un problème de synchronisation de l’état entre composant parent et composants enfants
- Htmx n’offre pas de bonne solution à cela
- Il existe des idées comme les paramètres de requête, les champs de formulaire cachés, les déclencheurs d’événements, etc., mais elles ont toutes de grosses réserves
- React et Halogen ont une réponse à ce problème
- Dans les deux cas, les composants enfants ont leur propre état, et le parent peut fournir des « props », comme des « conseils »
- Ils ont aussi leur propre état interne, qu’ils peuvent ignorer ou prioriser par rapport aux props
- Les props sont généralement fournies par le serveur ou dérivées du serveur, tandis que l’état est généralement un état côté client
- Les composants prêts à l’emploi fournis en React, ou ceux qu’il faut utiliser, nécessitent souvent React
- React et Htmx interagissent mal
- J’ai fait du travail peu satisfaisant avec les Web Components, mais ils ont des limitations étranges et surprenantes
- J’ai aussi créé des ponts directs vers des composants React utilisés depuis des langages côté serveur, mais en général Htmx et React se disputent le flux d’état et la gestion des éléments du DOM
- J’ai essayé Alpine, qui est bien, mais c’est encore une autre bibliothèque de programmation côté client, donc c’est redondant si React est déjà présent dans la base de code
Malgré tout, il y a des avantages
- Le fait de pouvoir utiliser un langage côté serveur est un avantage énorme, évident et peu contestable
- Personne dans l’équipe n’aurait envie de réécrire toute cette logique métier en TypeScript
- Il n’est pas nécessaire de sérialiser les types de la base de données vers des types frontend
- Pas de fuite de données, et pas besoin de GraphQL
- On peut utiliser la puissance d’abstraction supérieure des langages côté serveur
- On peut utiliser les générateurs de formulaires du langage côté serveur au lieu d’implémenter la même validation à la fois côté frontend et côté backend
- Mais les inconvénients ci-dessus sont eux aussi bien réels
Htmx-dans-React ?
- Une piste d’avenir séduisante pourrait être de réimplémenter Htmx dans React
- Le serveur enverrait un blob JSON, que React convertirait en composants de virtual DOM
- Cela résoudrait alors le problème de l’état des composants
- Il ne serait pas nécessaire d’avoir un pont spécial pour utiliser des composants React
- On pourrait utiliser des bibliothèques de data fetching connectées à React, et éviter soigneusement un certain choix de file d’attente fait dans Htmx
- Les problèmes liés à Morphdom et aux éléments de saisie du DOM dans le navigateur seraient également résolus, car ce sont des problèmes presque déjà résolus dans React
- De cette façon, on pourrait supprimer la dépendance à Htmx tout en conservant les avantages de l’idée. À condition bien sûr d’avoir le budget nécessaire pour lancer un chantier d’une telle ampleur
L’avis de GN⁺
- L’idée de base de Htmx est séduisante, mais son usage réel peut confronter à plusieurs problèmes complexes
- Certaines décisions de conception de Htmx, comme l’héritage des attributs, le remplacement des éléments du DOM ou le mode de file d’attente, peuvent être peu intuitives et provoquer des comportements inattendus
- L’intégration avec React ou les Web Components ne semble pas simple non plus
- Malgré cela, la possibilité d’utiliser des langages côté serveur reste un avantage majeur
- À l’avenir, une réimplémentation de Htmx basée sur React pourrait aussi être une piste intéressante
12 commentaires
L’intérêt vaut mieux que l’indifférence~ Moi, j’aime bien HTMX. Avec sa philosophie aussi.
C’est aussi très proche de l’esprit de SQLite haha
En quoi SQLite et HTMX se ressemblent-ils ?
Un peu comme SQLite ?
Les commentaires sont profonds. De la philosophie, donc...
Si vous avez déjà fait du développement web avec du rendu côté serveur et jQuery avant l'arrivée des SPA, vous comprendrez tout de suite qu'il s'agit de technologies de cette famille. Je pense que ceux qui ont découvert le développement web avec les SPA, en cherchant quelque chose de nouveau, se font sans doute une fausse idée.
On dirait que cet article n’a probablement pas été écrit en Corée.
Oui, c’est ça. On dirait un outil conçu pour des pages simples, donc je ne comprends pas pourquoi on va chercher des exemples ou des cas d’usage étranges pour ensuite débattre du fait qu’il n’est pas adapté à ce genre de choses.
Comme on peut le constater sur la page d’accueil de htmx, htmx considère à peu près que les technologies modernes du front-end, React compris, ne sont pas nécessaires (à condition de n’utiliser que lui).
C’est lié à la raison pour laquelle htmx attire l’attention. Cet article aussi est une traduction d’une contribution étrangère, et à l’étranger, beaucoup en ont assez de toute la gestion d’état de React. Ils ont donc vu htmx comme une alternative à React, car il offre des fonctionnalités similaires à React tout en n’exigeant pas de gestion d’état comme React. C’est pour cela qu’on continue à comparer htmx à React.
Eh bien, dans ce cas, ne faudrait-il pas plutôt prendre quelque chose qui prétend pouvoir remplacer React et le comparer ?
Rien qu’en regardant les caractéristiques listées sur cette page, on voit bien que HTMX n’est pas un outil fait pour des pages complexes et qu’il ne peut absolument pas remplacer React.
Avis sur Hacker News
Les avis divergent sur l’héritage des attributs. Il est possible de le désactiver avec l’option
htmx.config.disableInheritanceLa raison de ne pas s’être lancé dans le front-end est qu’il y a trop de choix, trop de critiques et que les tendances techniques changent souvent
Utilisation de HTMX pour construire une vitrine e-commerce performante, avec des résultats satisfaisants
L’idée de « HTMX in React » revient à réinventer les React Server Components
Désaccord avec l’idée que le mode de file d’attente par défaut est irrationnel
Après une première utilisation de HTMX, l’expérience a été simple à mettre en place pour des tâches basiques et plutôt amusante
Après avoir lu les plaintes au sujet de l’état, impression que l’auteur n’avait jamais créé de site web avant React
Se demande si HTMX propose une fonctionnalité comparable à Turbo Mount
Souhaite en savoir plus sur le problème où morphdom écrase certains éléments de manière inattendue
detailsest l’une des fonctions principales des bibliothèques comme morphdom