Sommaire
Bonjour Nal!
Le titre a dut t'intriguer. Tu te demandes peut-être, c'est quoi HTMX ? c'est quoi React ? Ou alors tu connais déjà, et tu es prêt a me préparer un commentaire cinglant m'expliquant que je suis un fou.
Commençons par le commencement.
C'est quoi HTMX ?
C'est une petite bibliothèque Javascript qui nous permet de ne plus écrire de Javascript. Enfin, presque plus. Cette bibliothèque adopte le concept "HATEOAS", "Hypermedia As The Engine Of Application State" (Hypermedia en tant que moteur de l'état de l'application).
Donc pour comprendre HTMX, il faut comprendre ce qu'est l'Hypermedia.
Pour faire simple, un media est un document, une ressource qui peut être du texte, une image, une vidéo, de la musique, etc. Le concept d'hypermedia ajoute à ce document des informations supplémentaires : des références à d'autres documents.
Ainsi, un ensemble de document "hypermedia" forme grâce à ces références une sorte de toile que l'utilisateur peut naviguer.
HTML (pour "Hyper Text Markup Language") est l'exemple d'hypermedia le plus connu. Il enrichit le format textuel avec des liens, et des formulaires permettant à l'utilisateur d'interagir avec le document.
HTMX se présente comme une extension du HTML, donnant la possibilité d'ajouter de nouvelles interactions à toutes parties du document. Avec un HTML plus puissant, il devient donc possible de créer des applications complexes qui sont entièrement décrite par des documents "hypermedia".
L'architecture classique d'une application utilisant HTMX est très souvent un serveur qui génère et retourne le document hypermedia, qui référence donc d'autres documents ou ressources fournies par ce serveur. Au niveau logiciel, cela se traduit donc par une architecture similaire à ce qui se faisait avec l'avènement des "frameworks" côté client (Angular, React, Vue, EmberJS, …), comme par exemple Django, Symphony, Laravel, Ruby on Rails, …
Pour FlowG, la solution Open Source de traitement de journaux systèmes que je développe depuis quelques temps, et que j'ai déjà mentionné dans des journaux précédents, j'avais justement choisit HTMX pour créer l'interface utilisateur, avec le langage Go et le moteur de "template" Templ.
J'étais satisfait de ce choix, jusqu'à un moment fatidique…
Au final, c'est un problème de compétence
L'interface de FlowG était très crue. Je ne suis pas un expert "UX" (expérience utilisateur). J'ai donc créé quelque chose de basique, et ensuite attendu les retours d'utilisateurs.
J'ai eu ces retours très instructifs. On me demandait par exemple la possibilité d'éditer d'autres ressources depuis l'éditeur de "pipeline", sans quitter cet éditeur.
Prendre en compte tout ces changements nécessitait une gestion de "l'état" de l'application fine, et bien identifier et définir comment, quand et quelles données vont transiter dans chaque interaction du document hypermedia avec le serveur.
Je dois vous avouer, j'avais beaucoup de difficultés à ne pas écrire de code spaghetti. Et tout cela, ce sont des choses que je maîtrisais déjà avec des "framework" clients tel que React.
Le projet est encore jeune et petit, si il y avait un bon moment pour changer de technologie avant que cela devienne de la dette technique impossible à rembourser, c'était maintenant.
Du coup, pourquoi React ?
Premièrement, j'avais déjà React dans l'application. Pour l'éditeur de code, et pour l'éditeur de "pipeline". J'avais encapsulé ces composants dans des éléments HTML spécifique (aussi appelés "Web Components") :
<code-editor code="..."></code-editor>
<flow-editor flow="..."></flow-editor>Deuxièmement, c'est une technologie que je maîtrise mieux que HTMX.
Un des objectifs de FlowG, c'est qu'il soit entièrement pilotable par l'API. Tout ce qui est faisable dans l'interface utilisateur doit être faisable via l'API. Par conséquence, si l'interface utilisateur est elle même un client de l'API, l'objectif est atteint par définition.
Cela a pour conséquence de clairement séparer l'application en un "frontend" et un "backend". Ainsi, un contributeur potentiel n'a plus besoin d'être "full stack". Avec ce choix, j'étends ainsi l'éventail de contributions possibles. La barrière à l'entrée est baissée.
Cette nouvelle interface, elle ressemble à quoi ?
Au niveau technologie, on passe de :
- Go / Templ / HTMX à React
- MaterializeCSS (qui est déprécié) à React MUI (toujours Material Design donc)
- Une bête
<table>avec VirtualScroller à AG Grid
Le serveur web en Go ne sert plus que l'API ainsi que les fichiers statiques de l'interface utilisateur qui sont embarqués dans le binaire statique.
Voici par exemple l'éditeur de "pipeline" :
On n'a plus besoin de spécifier à la main le nom des nœuds que l'on veut utiliser dans la pipeline, on peut les glisser et les déposer directement.
On peut en créer depuis l'éditeur de "pipeline", et éditer les nœuds directement sur le graphe.
On voit également l'apparition du bouton "Supprimer" lorsque l'on sélectionne un nœud. Avant il fallait deviner que c'était la touche "Backspace" qui s'occupait de cela.
Et la vue pour visualiser les journaux systèmes :
On notera une amélioration de la sélection de la fenêtre de temps :
Le bouton "Watch Logs" servira a déclencher la visualisation des journaux en temps réel. L'API fournit un "endpoint Server-Sent Events" qui sera consommé par l'interface utilisateur. Il faut noter que l'implémentation officielle des navigateurs, EventSource, ne supporte pas l'envoi d'en-têtes HTTP. Hors c'est par ce mécanisme que l'authentification est implémentée. J'ai donc plutôt dût utiliser la bibliothèque suivante : event-source-plus.
La sélection de ce bouton changera donc le texte affiché pour refléter le choix de l'utilisateur.
Aussi, grâce à la bibliothèque AG Grid, utilisée pour le rendu du tableau, on peut réorganiser les colonnes selon notre préférence (ne persiste pas entre 2 rechargements de la page, plus tard peut être ?).
Un double-clique sur une ligne du tableau permettra de la visualiser en JSON, telle qu'elle est stockée dans la base de données :
Conclusion
Beaucoup d'améliorations de l'expérience utilisateur, en relativement peu de temps, tout simplement parce que je suis un meilleur développeur React que HTMX.
Au final, quand je conçois une application complexe, je suis trop habitué au modèle React/Vue. Le modèle "hypermedia", avec HTMX, reste ardu à réaliser de manière élégante, avec une implémentation qui sera à l'épreuve du temps. Je semble condamné à n'utiliser HTMX que pour des petits projets.
Liens :
# Merci
Posté par Guillaume Denry (site web personnel) . Évalué à 4 (+2/-0).
Merci pour ce retour, c'est aussi important de noter quand une techno qui semble prometteuse présente aussi des difficultés d'implémentation.
Je suis pourtant assez hypé par HTMX (enfin, plutôt par Elixir + Liveview + Phoenix qui va encore plus loin selon moi), mais il semble souffrir d'un problème qui concerne le modèle mental à adopter. En particulier sur de grosses applications.
Depuis React et le paradigme flux, c'est plutôt "facile" de comprendre le rendu en fonction des données du state (avec le dataflow unidirectionnel, scuzez mon franglais).
Par contre, avec HTMX, j'aimerais bien savoir si on arrive à un tel confort, même au prix d'un shift de paradigme.
[^] # Re: Merci
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
C'est pour ça que mon poulin c'est elm et je ne comprends vraiment l'intérêt de HTMX (j'ai l'impression d'un truc un peu gros un peu magique pour cacher du js).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Merci
Posté par Guillaume Denry (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 24 septembre 2024 à 17:21.
Elm a une place particulière dans mon cœur en revanche, je me demande si c'est pas un peu risqué d'investir dans ce langage en 2024. Parfois, le meilleur ne gagne pas :(
Par contre pour HTMX, le peu de JS que ça cache, c'est juste pour combler les manques de HTML, la promesse de HTMX c'est précisément de n'avoir quasiment pas à faire du JS qui tourne sur le front.
Ou bien je t'ai mal compris.
[^] # Re: Merci
Posté par David Delassus (site web personnel) . Évalué à 3 (+1/-0).
D'ailleurs, l'auteur de HTMX travaille actuellement sur des RFC / Specifications pour introduire dans HTML certaines fonctionnalités de HTMX.
Source: trust me bro. Plus sérieusement, j'avais vu passer un lien sur HackerNews parlant de cela il y a quelques temps, mais impossible de le retrouver :(
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Merci
Posté par Pol' uX (site web personnel) . Évalué à 2 (+0/-0).
J'avais lu ça ici, de mémoire.
Adhérer à l'April, ça vous tente ?
[^] # Re: Merci
Posté par David Delassus (site web personnel) . Évalué à 4 (+2/-0).
Je peux difficilement me citer moi même comme source :D
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Merci
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Je m'en fou. C'est ce que j'aime utiliser. J'aime utiliser zsh avec wezterm, même si personne d'autres n'aiment. Pour ce que je fais avec elm, si je dois le réécrire en un autre truc plus part c'est pas bien grave.
Tout ceux qui ont promis ça ces 20 dernières années ont pondues des solutions pas très bien faites.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Merci
Posté par Guillaume Denry (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 24 septembre 2024 à 21:27.
Je ne sais pas trop à quelles technos tu fais référence, mais HTMX (et similaire, basé sur l'exploitation des concepts de HATEOS), c'est principalement envoyer des fragments de HTML au client de façon dynamique, et c'est déjà une réalité ; avec HTMX, tu "forges" ton front avec ta techno backend, principalement. Le seul javascript qui reste éventuellement redevient ce qu'il était à la fin des années 90 : un peu de "liant" de temps en temps.
https://www.youtube.com/watch?v=3GObi93tjZI
[^] # Re: Merci
Posté par GwenLg . Évalué à 3 (+2/-0).
En français il y a aussi cette vidéo :
HTMX - Un retour aux templates ou le futur du front-end ? (conf BreizhCamp de cette année)
J'ai trouvé la vidéo intéressante, ça ne va pas dans les détails techniques, mais ça présente assez bien quand HTMX est intéressant et quand ça l'est moins, ses limites.
[^] # Re: Merci
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Et je ne parle que de ce qui me revient comme ça (c'est pour ça qu'il y a pas mal de truc qui vient de la communauté java)1. En soit ils ont tous apporter une pierre à l'édifice même si c'est pour savoir que ce n'est pas la bonne démarche, mais j'arrive pas à comprendre comment ce qu'apporte HTMX (pas la peine de tenter de me réexpliquer une énième fois, si ces RFCs sont adopter je m'y remettrais) et je ne comprends même pas ce qu'il tente de résoudre à part permettre à ceux qui n'aiment pas js de ne pas faire de js.
à noter qu'ils ne sont pas tous morts, mais bon qui aujourd'hui va se lancer dans asmjs (dernière date de sorti il y a 9 jours) ? ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Merci
Posté par Guillaume Denry (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 25 septembre 2024 à 20:54.
Toutes les technos que tu cites, c'était pour produire un logiciel destiné à être exécuté côté front et qui communique ensuite avec le backend (en JSON par exemple).
HTMX (notamment) est un changement de paradigme, puisque l'exécution de ton application est en quelque sorte "streamée", sa logique reste sur le backend et est écrite dans le langage de ton choix. C'est une implémentation de la vision d'origine complète de REST (HATEOS).
Ça permet notamment à une petite équipe de ne pas avoir à s'embarquer dans l'apprentissage d'un écosystème front et ses concepts les plus avancés, il "suffit" de connaître HTML et CSS et on utilise son langage favori pour envoyer les morceaux de pages.
C'est pas la recette magique pour tout, la première objection étant : on fait comment quand le backend ne répond plus car on est déconnecté, dans l'avion, etc ? Mais bon, en général, une appli web, c'est de toute façon relativement inutile quand on a plus de serveur en face.
[^] # Re: Merci
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Pardon hein mais tu donne un mélange des arguments de chacun des trucs que j'ai cité. Et non tout ce que j'ai cité n'est pas côté serveur. Pour ce qui est de HATEOS le concept a 20 ans et euh… On verra bien si le concept se démocratise, mais pour le moment la RFC 5988 ou json hal n'ont pas rencontré leur public. Et à l'usage c'est contraignant à implémenter et pas particulièrement confortable à l'usage
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Merci
Posté par Guillaume Denry (site web personnel) . Évalué à 3 (+1/-0).
Je pense que cette discussion n'ira pas très loin, tu as sûrement raison, HTMX n'est pas une technologie d'avenir ou même une technologie intéressante tout court, pas envie de me battre.
[^] # Re: Merci
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Pardon d'avoir un avis différent. Je serais très content si ça perce, c'est juste que je ne vois pas ce qu'il a de plus que les dizaines dizaines de prédécesseurs de ces 20 dernières années.
Je te promet d'écrire un journal pour exprimer à quel point je me suis fourvoyé si cela arrive.
Pour HATEOAS, ça fait effectivement 15 ans que j'en entends parler. C'est dommage de ne prendre mal le fait de parler pour autre chose que simplement le citer. J'espère que HTMX a une idée de ce qui ne va pas dans l'existant et comment faire mieux.
Je peux faire comme toi et dire que je suis trop con pour HTMX, mais j'espère que je suis le seul idiot sinon il ne trouvera pas son public
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Merci
Posté par Guillaume Denry (site web personnel) . Évalué à 1 (+0/-1). Dernière modification le 26 septembre 2024 à 14:21.
Si je remonte au début de cette discussion, tu dis que tu crains que HTMX serait une chose "magique" pour "cacher du JS", et je réponds techniquement que le but est non seulement de sortir de Javascript mais surtout de sortir de l'exécution d'un langage sur le front en épousant HATEOS.
Ensuite, je ne sais pas pourquoi, tu ne parles plus de "cacher du javascript" mais tu pivotes en parlant de ton scepticisme vis-à-vis de la techno sans vraiment argumenter et en listant une série de technologies qui n'ont pas grand chose à voir avec hypermedia/hateos et en te positionnant dans un rôle surplombant de celui qui "attend de voir si ça va percer", tout en ayant dit plus tôt dans d'autres documentaires que tu t'en fous du trending, que tu aimes Elm, utilises Wezterm, etc.
J'ai vraiment du mal à te suivre.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.