Je n'ai pas fait d'application "conséquente" avec HTMX. Mais étant un dev plutôt backend, je me suis retrouvé dans la proposition qui est faite. J'ai pû faire une application web de quelques écrans de gestion de ma collection de films avec intégration à IMDB. Ce de manière bien plus plaisante que avec n'importe quel framework frontend.
J'ai utilisé Python+FastAPI+Pydantic+Jinja+Pug+HTMX.
Mais si vous voulez quelque chose de sérieux, je vous invite à regarder cette vidéo. Toute la conférence est intéressante mais pour ceux qui sont intéressés par les chiffres, se rendre au timecode 17:58.
En gros, sans perte de confort utilisateur, et même en l'améliorant côté perf, ils sont passé de 21kloc de JS à 6kloc et seulement de 500 loc à 1200 loc Python. Il explique aussi qu'un développeur peut maintenant prendre une feature de bout en bout, sans que le front doive attendre le back.
du mix balises HTML + instructions pseudo javascript
Ça ressemble plus à du html déclaratif qu'à du javascript pour moi. Par contre je trouve que quelque chose du style hx-trigger-delay="1s" aurait été plus cohérent.
Le manque de consistance dans le nommage des triggers me pose plus soucis par contre :
On dirait bien en effet, mais ça n'enlève rien au manque de cohérence quand tu ne connais pas les termes issus du monde js.
Le but d'htmx est quand même de mettre au niveau d'hypertexte certaines fonctionnalités pour s'abstenir de l'écriture du js. C'est dommage de leak les nommages bancals alors que l'interface pourrait bénéficier d'un nommage cohérent si on se limite à htmx.
Je ne sais pas ce qui est considéré comme une application conséquente mais je n'ai aucun mal à adapter mes applications classiques (SSR) à htmx.
Par contre je pense qu'il ne faut pas tomber dans le piège d'en mettre de partout, j'utilise htmx uniquement quand c'est réellement utile voir indispensable. Sur linuxfr par exemple on pourrait l'utiliser pour la prévisualisation mais peu d'intérêt pour aller d'un journal à l'autre à mon avis.
Netbox utilise HTMX pour charger les formulaires des fenêtres modales.
En fait, il y a tellement de gens qui présentent HTMX comme un remplaçant de React que ça donne une mauvaise image de la chose.
Comparer HTMX et React c'est stupide.
Pour comprendre l'intérêt de HTMX, il faut faire un peu le point sur l'histoire du web dev :
On commence avec du contenu statique, HTML / CSS servi par un serveur HTTP
On génère ce HTML dynamiquement côté serveur (CGI Perl, CGI PHP, framework Python/Ruby/…, …) à chaque requête
On a besoin d'interactivité côté client (fenêtres modales, formulaires dynamique, notifications, …), c'est là ou on introduit Javascript
La compatibilité entre navigateurs est un problème, d'où jQuery
C'est galère à organiser le code, du coup on créé des frameworks JS
Ce qu'on veut en fait, c'est faire nos propres composants HTML, d'ou React/Vue/WebComponents/…
Il s'avère qu'autant de JS côté client c'est lent, alors on veut du SSR (rendu côté serveur)
Et on est revenu au point de départ, un serveur qui retourne du HTML. A ce moment là, a-t-on besoin d'un framework JS ?
On a désormais les WebComponents pour créer de l'intéractivité côté client uniquement là ou il y en a besoin, HTMX 2.0 améliore sa compatibilité avec ces derniers justement (un meilleur support du shadow DOM).
HTML5 se dote d'éléments comme <summary> ou <dialog> rendant certains patterns en JS (comme la fenêtre modale) obsolète.
La proposition d'HTMX c'est de continuer à faire évoluer le HTML pour devenir le langage du web, au lieu que cela soit JS (ils sont d'ailleurs en discussion informelle avec des développeurs de navigateurs ainsi que le W3C pour incorporer certaines fonctionnalités de HTMX dans le standard, et donc implémenté par le navigateur). Il faut donc l'utiliser là ou ça fait sens. Si on se mets à écrire :
La proposition d'HTMX c'est de continuer à faire évoluer le HTML pour devenir le langage du web, au lieu que cela soit JS
Merci, c'est bien ce qu'il me semblait, mais là c'est clairement exprimé.
et c'est bien le sentiment que cela m'a laissé après avoir lu quelques articles que Le créateur d'htmx a rédigé pour éclairer sa démarche: https://htmx.org/essays/
Globalement, j'aime beaucoup l'approche
"Si tous les cons volaient, il ferait nuit" F. Dard
Si on se mets à écrire : […] C'est que l'on n'a rien compris à HTMX.
Pour information, c'est ce que j'avais tendance à faire à mes débuts avec HTMX.
Je venais de passer 5 ans à splitter un backend monolithe en architecture micro service. Et j'étais hypé par la notion de "micro frontend", et je comprenais pas qu'on parlait de "micro frontend" pour des applications React/Vue, qui me semblaient être des monolithes modulaires (je n'ai rien contre cette architecture).
Ma première impression de HTMX fut donc de fournir des bouts de frontend en provenance de serveurs distincts.
Je vous dis pas la monstruosité d'over-enginering que j'avais pondu à l'époque (circa 2021, bien avant la hype récente de HTMX). Les bugs d'affichage impossible à debugguer car j'avais foutu un <body hx-boost="true">.
En gros, j'essayais de faire une SPA (Single Page Application) avec HTMX, et c'est clairement pas le but du projet.
Bref, j'avais rien compris à HTMX.
Ensuite j'ai pris du recul, j'ai refait du Django sans API REST/JSON, template côté serveur, et tout le tralala.
Et puis les rares moments ou je me suis dit "tiens, ça serait bien que le serveur puisse m'envoyer un peu de HTML à rajouter ici", c'est là que HTMX est venu à mon aide.
Un cas d'usage que j'apprécie tout particulièrement désormais : Un système de notification.
Faites un endpoint SSE (Server Sent Event) côté serveur, qui envoit le contenu suivant :
event: notify
data: <p>some HTML for a notification</p>
il y a tellement de gens qui présentent HTMX comme un remplaçant de React que ça donne une mauvaise image de la chose.
Comparer HTMX et React c'est stupide.
Ça se compare au sens ou c'est une alternative si tu dois faire une application web : tu peux faire du MPA, du MPA avec du jquery, du SPA avec un des 15 framework TS/JS qui existent, du SSR, du Phoenix/Liveview, du HTMX, du ELM, du Purescript, etc.
C'est toujours intéressant de savoir les points forts et les points faibles de chaque approche.
Posté par wilk .
Évalué à 6.
Dernière modification le 20 juin 2024 à 08:50.
il y a tellement de gens qui présentent HTMX comme un remplaçant de React que ça donne une mauvaise image de la chose.
Comparer HTMX et React c'est stupide.
Comparer HTMX et React est stupide quand ils sont utilisés là où ils sont adaptés mais bien souvent React est utilisé là où HTMX aurait largement pu faire l'affaire en évitant une usine à gaz.
# htmx sucks
Posté par steph1978 . Évalué à 1.
N'y touchez pas. Si vous y touchez, le doute va s'insinuer en vous.
[^] # Re: htmx sucks
Posté par pas_pey . Évalué à 2.
Tu as un retour d'expérience plus précis à partager ?
[^] # Re: htmx sucks
Posté par steph1978 . Évalué à 5.
Je n'ai pas fait d'application "conséquente" avec HTMX. Mais étant un dev plutôt backend, je me suis retrouvé dans la proposition qui est faite. J'ai pû faire une application web de quelques écrans de gestion de ma collection de films avec intégration à IMDB. Ce de manière bien plus plaisante que avec n'importe quel framework frontend.
J'ai utilisé Python+FastAPI+Pydantic+Jinja+Pug+HTMX.
Mais si vous voulez quelque chose de sérieux, je vous invite à regarder cette vidéo. Toute la conférence est intéressante mais pour ceux qui sont intéressés par les chiffres, se rendre au timecode 17:58.
En gros, sans perte de confort utilisateur, et même en l'améliorant côté perf, ils sont passé de 21kloc de JS à 6kloc et seulement de 500 loc à 1200 loc Python. Il explique aussi qu'un développeur peut maintenant prendre une feature de bout en bout, sans que le front doive attendre le back.
[^] # Re: htmx sucks
Posté par Luc-Skywalker . Évalué à 3.
Idem que au dessus !
Ca fait un bon moment que je regarde ce truc et globalement, le principe me semble intéressant pour faire du AJAX like sans trop s’embêter.
Mais en contrepartie, je ne suis pas du tout fan
En fait, je suis curieux de savoir si le code produit pour une application un peu conséquente arrive à rester lisible et bien structuré.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: htmx sucks
Posté par Elfir3 . Évalué à 1.
Ça ressemble plus à du html déclaratif qu'à du javascript pour moi. Par contre je trouve que quelque chose du style
hx-trigger-delay="1s"aurait été plus cohérent.Le manque de consistance dans le nommage des triggers me pose plus soucis par contre :
[^] # Re: htmx sucks
Posté par wilk . Évalué à 2.
Ca reprend les termes JS non ?
https://developer.mozilla.org/fr/docs/Web/API/Element/insertAdjacentHTML
https://developer.mozilla.org/fr/docs/Web/API/Element/innerHTML
[^] # Re: htmx sucks
Posté par Elfir3 . Évalué à 1.
On dirait bien en effet, mais ça n'enlève rien au manque de cohérence quand tu ne connais pas les termes issus du monde js.
Le but d'htmx est quand même de mettre au niveau d'hypertexte certaines fonctionnalités pour s'abstenir de l'écriture du js. C'est dommage de leak les nommages bancals alors que l'interface pourrait bénéficier d'un nommage cohérent si on se limite à htmx.
[^] # Re: htmx sucks
Posté par wilk . Évalué à 5.
Je ne sais pas ce qui est considéré comme une application conséquente mais je n'ai aucun mal à adapter mes applications classiques (SSR) à htmx.
Par contre je pense qu'il ne faut pas tomber dans le piège d'en mettre de partout, j'utilise htmx uniquement quand c'est réellement utile voir indispensable. Sur linuxfr par exemple on pourrait l'utiliser pour la prévisualisation mais peu d'intérêt pour aller d'un journal à l'autre à mon avis.
[^] # Re: htmx sucks
Posté par David Delassus (site web personnel) . Évalué à 10.
Netbox utilise HTMX pour charger les formulaires des fenêtres modales.
En fait, il y a tellement de gens qui présentent HTMX comme un remplaçant de React que ça donne une mauvaise image de la chose.
Comparer HTMX et React c'est stupide.
Pour comprendre l'intérêt de HTMX, il faut faire un peu le point sur l'histoire du web dev :
Et on est revenu au point de départ, un serveur qui retourne du HTML. A ce moment là, a-t-on besoin d'un framework JS ?
On a désormais les WebComponents pour créer de l'intéractivité côté client uniquement là ou il y en a besoin, HTMX 2.0 améliore sa compatibilité avec ces derniers justement (un meilleur support du shadow DOM).
HTML5 se dote d'éléments comme
<summary>ou<dialog>rendant certains patterns en JS (comme la fenêtre modale) obsolète.La proposition d'HTMX c'est de continuer à faire évoluer le HTML pour devenir le langage du web, au lieu que cela soit JS (ils sont d'ailleurs en discussion informelle avec des développeurs de navigateurs ainsi que le W3C pour incorporer certaines fonctionnalités de HTMX dans le standard, et donc implémenté par le navigateur). Il faut donc l'utiliser là ou ça fait sens. Si on se mets à écrire :
C'est que l'on n'a rien compris à HTMX.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: htmx sucks
Posté par Luc-Skywalker . Évalué à 5.
Merci, c'est bien ce qu'il me semblait, mais là c'est clairement exprimé.
et c'est bien le sentiment que cela m'a laissé après avoir lu quelques articles que Le créateur d'htmx a rédigé pour éclairer sa démarche:
https://htmx.org/essays/
Globalement, j'aime beaucoup l'approche
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: htmx sucks
Posté par orfenor . Évalué à 4.
Comme Luc Skywalker, c'est exactement ce qu'htmx est pour moi, merci David pour cette explication simple et claire qui mérite un +10
[^] # Re: htmx sucks
Posté par David Delassus (site web personnel) . Évalué à 4.
Pour information, c'est ce que j'avais tendance à faire à mes débuts avec HTMX.
Je venais de passer 5 ans à splitter un backend monolithe en architecture micro service. Et j'étais hypé par la notion de "micro frontend", et je comprenais pas qu'on parlait de "micro frontend" pour des applications React/Vue, qui me semblaient être des monolithes modulaires (je n'ai rien contre cette architecture).
Ma première impression de HTMX fut donc de fournir des bouts de frontend en provenance de serveurs distincts.
Je vous dis pas la monstruosité d'over-enginering que j'avais pondu à l'époque (circa 2021, bien avant la hype récente de HTMX). Les bugs d'affichage impossible à debugguer car j'avais foutu un
<body hx-boost="true">.En gros, j'essayais de faire une SPA (Single Page Application) avec HTMX, et c'est clairement pas le but du projet.
Bref, j'avais rien compris à HTMX.
Ensuite j'ai pris du recul, j'ai refait du Django sans API REST/JSON, template côté serveur, et tout le tralala.
Et puis les rares moments ou je me suis dit "tiens, ça serait bien que le serveur puisse m'envoyer un peu de HTML à rajouter ici", c'est là que HTMX est venu à mon aide.
Un cas d'usage que j'apprécie tout particulièrement désormais : Un système de notification.
Faites un endpoint SSE (Server Sent Event) côté serveur, qui envoit le contenu suivant :
Côté client :
De la même manière, on peut créer un système de chat assez simplement :
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: htmx sucks
Posté par steph1978 . Évalué à 5.
Ça se compare au sens ou c'est une alternative si tu dois faire une application web : tu peux faire du MPA, du MPA avec du jquery, du SPA avec un des 15 framework TS/JS qui existent, du SSR, du Phoenix/Liveview, du HTMX, du ELM, du Purescript, etc.
C'est toujours intéressant de savoir les points forts et les points faibles de chaque approche.
[^] # Re: htmx sucks
Posté par wilk . Évalué à 6. Dernière modification le 20 juin 2024 à 08:50.
Comparer HTMX et React est stupide quand ils sont utilisés là où ils sont adaptés mais bien souvent React est utilisé là où HTMX aurait largement pu faire l'affaire en évitant une usine à gaz.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.