Pourquoi Gumroad n’a pas choisi htmx
(htmx.org)- Gumroad a envisagé htmx pour son nouveau projet Helper, en espérant un frontend léger, mais est passé à React/Next.js à mesure que les exigences UX devenaient plus complexes
- htmx semblait prometteur pour les interactions simples, mais avec des formulaires comportant une validation dynamique et des champs conditionnels, la logique côté serveur devenait verbeuse et le flux de développement peu naturel
- Le glisser-déposer du workflow builder, la collaboration en temps réel, la gestion d’état complexe et la génération de formulaires dynamiques se mettaient en œuvre plus directement avec l’écosystème React et son modèle de composants
- Les ressources de résolution de problèmes et la prise en charge par les outils d’IA étaient plus abondantes côté Next.js et React ; htmx était désavantagé en vitesse de développement à cause du manque de données d’apprentissage open source
- htmx peut convenir à des applications existantes rendues côté serveur ou à des modèles d’interaction simples, mais pour une interface riche en état comme Helper, React et Next.js étaient mieux adaptés
Contexte de l’évaluation de htmx pour Helper
- En lançant son nouveau projet Helper, Gumroad a évalué htmx comme candidat pour le frontend
- L’attente initiale venait de l’expérience selon laquelle React est plus lourd que nécessaire, et htmx était perçu comme une façon d’ajouter légèrement des interactions simples
- En interne, certains estimaient aussi que htmx ressemblait à un mème se moquant de l’écosystème JavaScript devenu complexe
- De même que Tailwind peut ressembler à une autre syntaxe pour du CSS inline, htmx était vu comme proche d’une autre syntaxe pour du JavaScript inline
- Tailwind a trouvé sa place dans l’outillage de Gumroad, mais htmx ne s’est pas étendu pour répondre aux objectifs de Helper et n’a pas conduit à la meilleure expérience utilisateur pour les clients
Les points où React/Next.js paraissait plus naturel
-
Expérience de développement et traitement des formulaires
- Il était possible de réaliser une implémentation correcte avec htmx, mais Gumroad a trouvé plus intuitif de faire fonctionner les fonctionnalités avec Next.js
- Pour les formulaires complexes avec validation dynamique et champs conditionnels, le travail côté client avec React était plus simple, tandis qu’avec htmx la logique côté serveur s’allongeait
-
UX et contraintes d’interaction
- htmx a tendance à pousser l’application vers une approche Rails/CRUD, ce qui rend facilement l’expérience de base banale ou générique
- L’interface de glisser-déposer du workflow builder nécessitait des contournements avec htmx, et paraissait plus rudimentaire que l’expérience fluide obtenue avec les bibliothèques React
-
Outils d’IA et vitesse de résolution des problèmes
- Les outils d’IA connaissent bien Next.js, mais moins htmx, notamment en raison du manque de données d’apprentissage open source
- Les ressources étant abondantes côté React/Next.js, il était plus rapide de trouver des solutions en cas de problème
-
Complexité et extensibilité
- Plus le projet devenait complexe, plus la simplicité de htmx se rapprochait d’une contrainte plutôt que d’un avantage
- Avec l’ajout de la collaboration en temps réel et de visualisations de données complexes, l’approche centrée serveur de htmx rendait la gestion de l’état entre plusieurs composants de plus en plus difficile
Les différences révélées fonctionnalité par fonctionnalité dans Helper
- Glisser-déposer : dans l’écosystème React,
react-beautiful-dndfournit un glisser-déposer fluide et accessible avec peu de configuration - Gestion d’état complexe : les approches de gestion d’état de React comme
useStateou Redux étaient plus directes pour refléter en temps réel dans l’UI les paramètres et la logique conditionnelle de chaque étape de workflow - Génération de formulaires dynamiques : créer des formulaires de configuration différents selon le type d’étape et les modifier en fonction des saisies utilisateur se traitait plus intuitivement avec le modèle de composants React
- Collaboration en temps réel : permettre à plusieurs utilisateurs de modifier simultanément un workflow a été implémenté de façon relativement directe avec WebSockets et React ; avec htmx, cela aurait nécessité une logique côté serveur plus complexe et du JavaScript personnalisé
- Optimisation des performances : à mesure que les workflows devenaient plus grands et complexes, le virtual DOM de React et des hooks comme
useMemoetuseCallbackpermettaient d’optimiser finement le rendu
Écosystème et décision finale
- L’écosystème React/Next.js est vaste et mature, et a fourni des solutions à presque tous les problèmes rencontrés par Gumroad
- Avec htmx, il fallait souvent faire des compromis sur les fonctionnalités ou les reconstruire soi-même ; dans l’intégration de services tiers et de bibliothèques, il existait parfois des bindings React mais pas d’équivalent htmx
- Après être passé à React/Next.js, Gumroad a jugé que c’était un meilleur choix pour construire une UX complexe
- L’équipe pouvait avancer plus vite, créer une expérience utilisateur plus immersive et tirer parti des outils et bibliothèques existants
- Elle a aussi pu améliorer nettement l’expérience utilisateur de l’application pour les clients principaux de Helper
- Les limites de htmx ne sont pas impossibles à surmonter, mais les résoudre éloignait de ses points forts et orientait vers des solutions plus naturelles dans un environnement centré sur JavaScript
- htmx peut être un bon choix pour des modèles d’interaction simples ou des projets construits sur des applications existantes rendues côté serveur
- Pour des interfaces complexes et riches en état comme Helper, React et Next.js étaient plus adaptés, et Gumroad estime pouvoir continuer à réévaluer sa stack technique au gré des évolutions des besoins et des nouvelles technologies
1 commentaires
Avis de Hacker News
C’est quelque chose que j’avais écrit dans un autre fil : le CEO de Gumroad a dit sur Twitter qu’il avait essayé htmx sur un projet, mais avait finalement choisi NextJS.
Je cherchais un témoignage négatif réfléchi qui pourrait être publié sur le site de htmx, je lui ai donc demandé s’il pouvait rédiger son expérience, et je lui suis reconnaissant d’avoir accepté volontiers.
C’est rafraîchissant comparé à d’autres projets qui prétendent être la meilleure solution pour tout.
Je suis particulièrement curieux de la remarque sur le glisser-déposer : est-ce vraiment difficile avec htmx, et si oui, est-il prévu d’y remédier ?
Comme si Rails et React ne pouvaient pas être utilisés ensemble.
L’article en lui-même ressemble moins à un retour d’expérience négatif sur htmx qu’à un cas où, dès l’apparition du glisser-déposer et de la collaboration en temps réel, le fait d’avoir expérimenté htmx était peut-être une erreur dès le départ.
Je ne comprends pas très bien non plus ce que la capture d’écran est censée montrer, mais je pense quand même que c’est un bon texte à publier sur le site de htmx.
Pour moi, htmx ressemble davantage à un remplaçant de jQuery qu’à une alternative à React.
htmx et jQuery ajoutent de l’interaction à un document ; React cherche à devenir le document tout entier.
Les outils doivent varier selon la tâche.
Le passage « IA et support par les outils : il est aussi worth noting que les outils d’IA connaissent très bien Next.js, mais beaucoup moins htmx » est formulé sobrement comme un inconvénient, mais c’est un signe assez inquiétant pour l’avenir des outils de développement, bibliothèques, frameworks et langages.
À mon avis, les grands modèles de langage vont accentuer les dynamiques de winner-takes-all et les effets de prime au premier entrant, et encourager encore davantage l’usage des outils open source grâce à des données d’entraînement plus nombreuses et de meilleure qualité.
Même avant les grands modèles de langage, React avait l’avantage que la plupart des questions avaient déjà une réponse sur StackOverflow, et qu’il existait des bibliothèques matures pour presque tous les usages.
Désormais, certaines personnes posent simplement à un grand modèle de langage les questions qu’elles auraient autrefois posées sur StackOverflow, et le résultat est le même.
Utiliser ce que beaucoup d’autres utilisent apporte des avantages.
Mais je suis fermement convaincu que, comme stratégie à long terme pour une carrière d’ingénieur logiciel, ce n’est pas un très bon pari.
Je me suis même demandé si ce n’était pas une bonne chose.
L’industrie du logiciel passe trop de temps à courir après les derniers outils, fonctionnalités de langage et frameworks.
Un peu de stagnation, et le fait de terminer le travail avec les outils qu’on possède déjà plutôt que de fabriquer un nouveau marteau tous les six mois, pourraient être positifs.
À partir du seul commentaire, on ne sait pas si l’IA a réellement mal géré HTMX, ou si c’était plutôt une remarque sur le manque d’autres ressources.
Les grands modèles de langage fonctionnent souvent très bien comme des traducteurs généralistes.
S’ils connaissent les patterns et concepts généraux des frameworks populaires, et un peu la syntaxe de frameworks plus petits, ils produisent d’après mon expérience du code plutôt bon même pour des frameworks de niche.
C’est un peu comme le fait que des pirates peuvent parler avec un accent de pirate de sujets dont ils n’ont jamais parlé dans les données d’entraînement.
Le passage « quand on construisait des formulaires complexes avec validation dynamique et champs conditionnels, on s’est retrouvés à écrire une logique côté serveur complexe pour gérer ce qui aurait été une simple tâche côté client avec React » me fait penser au mème Anakin/Padmé.
« Mais vous implémentez quand même aussi la validation côté serveur, hein… hein ? »
J’ai du mal à imaginer un formulaire facile avec React mais difficile avec htmx, sauf dans le cas où l’on veut injecter un état global d’application à la React et en finir à 90 % grâce à une bibliothèque.
Simplement, elle est faite une seule fois à la soumission, pas page par page.
Contrairement à l’idée selon laquelle « htmx pourrait être une bonne solution pour garder le frontend très léger », on dirait que htmx a cessé d’être adapté dès qu’ils ont abandonné le frontend léger.
Ils ont commencé à utiliser des bibliothèques tierces pour rendre une UI/UX complexe et gérer l’état.
Dire aussi que « faire X était plus facile avec React » n’est pas une comparaison équitable si cela a été fait avec une bibliothèque tierce.
C’est simplement que quelqu’un d’autre l’a fait à votre place, donc vous n’avez pas eu à le faire vous-même.
Je suis largement d’accord avec l’article, mais s’ils savaient qu’ils avaient besoin d’un état et d’un rendu complexes, htmx n’était pas une bonne solution dès le départ.
J’aime htmx, mais cet article montre que l’auteur avait une compréhension technique assez limitée.
Ce ne sont pas des avantages et inconvénients qui nécessitent une connaissance approfondie de la plateforme web ou de la documentation htmx.org : on dirait plutôt qu’il voulait essayer HTMX parce que c’était dans l’air du temps.
Le langage Gherkin semble intéressant dans les cas simples et peut, en principe, être étendu aux cas complexes, mais plus il faut gérer de couches d’abstraction, plus pytest en pur Python devient pratique.
Le périmètre du projet n’était pas du tout « simple », et dans mon cas je serais directement parti sur React.
À propos du passage selon lequel « la mise en place d’une interface de glisser-déposer pour le workflow builder représentait un gros défi avec htmx, et nécessitait des contournements lourds par rapport à l’expérience fluide qu’on peut obtenir avec des bibliothèques React », HTMX est plus pertinent quand on limite le bundle frontend à ce qui est nécessaire, sans aller au-delà
Il suffit de se brancher sur l’événement
htmx.onLoad, puis de repérer dans le contenu chargé le balisage portant des attributs — par exemple columns, cards, tasks, etc. — et de l’y rattacherPar exemple, on peut binder sortable.js au balisage rendu, puis connecter les événements sortable à des mises à jour d’état via HTMX
C’est assez simple, et la documentation contient précisément ce type d’exemple : https://htmx.org/docs/#3rd-party
Les sites web modernes, dynamiques et avec état ne sont absolument pas incompatibles avec HTMX
À la lecture de l’article, l’équipe semble plus à l’aise avec le développement frontend qu’avec le développement backend
Du point de vue d’un développeur de l’ancienne école, on perçoit parfois une légère crainte et des malentendus dans la manière de penser des développeurs frontend
Honnêtement, je pense qu’il suffit d’ajuster un peu sa façon de penser pour comprendre comment cette approche fonctionne, mais je comprends aussi que beaucoup de gens n’aient jamais vu d’approche client/serveur classique de toute leur carrière
Cela dit, on ne peut pas ignorer la valeur des composants React prêts à l’emploi, ni l’avantage de trouver facilement documentation et aide
Toute une génération de designers a conçu le mobile et le web de façon très similaire, en reportant la complexité de mise en œuvre sur les développeurs
Pourtant, le web devrait, autant que possible, être différent du mobile, et il peut l’être
L’article dit que le design était trop « generic », comme une application CRUD, mais est-ce vraiment une mauvaise chose ?
Nous disposons d’un accomplissement remarquable : un modèle documentaire universellement adopté, qui permet de créer des expériences utilisateur prévisibles sur tous les sites, et nous ne le voyons que comme « ennuyeux »
Comme si l’ennui était en soi un problème fondamental
Je comprends la pression du marché pour des expériences distinctives, brandées, qui donnent l’impression d’applications mobiles, mais j’en viens à imaginer ce que cela donnerait si les designers pouvaient aussi penser à la manière du WWW, autant qu’ils pensent à la manière de React
J’aime le fait que HTMX publie ce genre d’article, ainsi que des textes similaires, sur son propre site
Il semble y avoir pas mal de raisons légitimes pour lesquelles HTMX seul ne leur convenait pas
Je ne suis pas spécialiste frontend, mais j’ai quelques réflexions
Premièrement, ne faut-il pas de toute façon valider les formulaires côté backend ?
Je me demande pourquoi il était si difficile pour le système backend de transmettre les résultats au frontend
Dans beaucoup de cas, il existe de très bonnes raisons de valider les formulaires à la fois côté frontend et côté backend ; dans ces cas-là, HTMX seul ne suffit sans doute pas, mais la formulation de ce problème me paraît un peu confuse
Deuxièmement, utiliser uniquement HTMX peut pousser l’application dans cette direction jusqu’à un certain point, et dans certains cas c’est une bonne chose, mais ils semblent avoir conclu qu’il leur fallait une autre approche pour leurs clients
Troisièmement, j’aimerais en savoir plus sur la manière dont cette équipe utilisait les outils d’IA, au point que leur dépendance à ces outils devienne un problème majeur
À l’avenir, si les outils de développement IA deviennent importants, il sera intéressant de voir si le seuil nécessaire pour disposer de suffisamment d’outillage et d’intégrations afin d’adopter un nouveau framework ou langage de programmation deviendra trop élevé
Quatrièmement, comme dans une critique fréquente de HTMX, certains projets demandent plus que ce que HTMX fournit
Cinquièmement, l’une des raisons pour lesquelles j’aime Django et Python tient aussi à la profondeur de leur communauté, de leurs intégrations et de leur écosystème d’extensions
Quelque chose comme https://unpoly.com/, dont le concept est similaire mais qui offre plus de fonctionnalités que HTMX, leur aurait peut-être mieux convenu
À propos de l’affirmation selon laquelle « le processus de développement de Next.js semblait naturel », je ne vois pas quelle partie de cette syntaxe ReactJS serait naturelle
Elle peut être familière, mais elle n’est pas naturelle
useEffect(() => { const timer = setInterval(() => { setCount((prevCount) => prevCount + 1); }, 1000); return () => clearInterval(timer); }, []);Au final, il faudra sans doute raccorder ça maladroitement avec JavaScript
Si l’on veut un hook personnalisé avec un timeout variable, cela peut devenir bien plus complexe
Dan a lui aussi dû écrire un long billet sur le sujet : https://overreacted.io/making-setinterval-declarative-with-r...
Peux-tu en écrire ?
Le fait que htmx.org ait hébergé cet article est louable
Au final, si quelqu’un adopte htmx puis s’énerve parce qu’il ne répond pas à ses besoins, il y a désormais une ressource vers laquelle le renvoyer
J’utilise htmx dans quelques-uns de mes projets et l’expérience a été plutôt bonne
Ce genre d’article me rend même plus confiant dans l’usage de htmx, parce qu’il montre, chose rare, où htmx excelle et où il est insuffisant
Le troisième point me fait peur
J’imagine un monde où des entreprises paient pour que leur framework soit surreprésenté dans les jeux d’entraînement des modèles, puis vendent des contrats sur cette base
C’est un peu comme si l’optimisation pour les moteurs de recherche était baked in dans les outils de développement