Pourquoi Gumroad n’a pas choisi Htmx

• Gumroad a envisagé htmx en lançant son nouveau projet, Helper.
• L’entreprise voulait utiliser htmx pour éviter la complexité de React, mais l’équipe était divisée sur ce choix.
• Au départ, htmx semblait prometteur pour ajouter des interactions simples.

Les limites de htmx

• Intuitivité et expérience développeur : travailler avec htmx s’est révélé moins intuitif qu’avec Next.js. Lors de l’implémentation de formulaires complexes et de validations dynamiques, la logique côté serveur est devenue plus compliquée.
• Limites UX : htmx adopte fondamentalement une approche Rails/CRUD, ce qui a rendu l’expérience utilisateur monotone. Mettre en place une interface en glisser-déposer s’est avéré plus difficile qu’avec React.
• IA et support des outils : Next.js est bien pris en charge par les outils d’IA, contrairement à htmx. Cela a eu un impact sur la vitesse de développement et la résolution des problèmes.
• Problèmes de passage à l’échelle : à mesure que le projet est devenu plus complexe, htmx n’a plus suivi les besoins. L’ajout de collaboration en temps réel et de fonctions avancées de visualisation de données a rendu la gestion d’état difficile.
• Communauté et écosystème : l’écosystème React/Next.js est mature et propose une grande variété de solutions, ce qui n’est pas le cas de htmx.

Décision finale : passer à React/Next.js

• React/Next.js s’est révélé mieux adapté à la création d’UX complexes.
• L’équipe a tiré parti des atouts de React pour le glisser-déposer, la gestion d’état complexe, la génération de formulaires dynamiques, la collaboration en temps réel et l’optimisation des performances.
• Pour dépasser les limites de htmx, l’équipe est passée à React, ce qui soutient la vision à long terme du projet.
• Elle est satisfaite de cette décision et peut désormais avancer plus vite, créer une expérience utilisateur plus engageante et tirer parti des outils et bibliothèques existants.

Leçons tirées de l’expérience

• Il est important d’envisager des alternatives légères, mais il est tout aussi important de choisir une technologie capable d’évoluer avec le projet et de soutenir une vision à long terme.
• Dans le cas de Helper, React et Next.js se sont avérés être ce choix, et depuis la migration, l’expérience utilisateur de l’application pour les clients clés a été nettement améliorée.

Résumé de GN⁺

• L’expérience de Gumroad montre qu’il est important d’envisager des alternatives légères, mais aussi de choisir une technologie capable d’accompagner la croissance du projet et sa vision à long terme.
• htmx peut convenir à des modèles d’interaction simples ou à des applications existantes rendues côté serveur.
• Pour l’interface complexe de Helper, fondée sur des états riches, React et Next.js constituaient un meilleur choix.
• La stack technique peut être réévaluée selon les besoins, et il est important de rester flexible à mesure que de nouvelles technologies apparaissent.

[GN⁺]

Avis Hacker News

• Le CEO de Gumroad a partagé son expérience après avoir essayé htmx puis être passé à NextJS. C’était une information utile pour ceux qui cherchaient un retour d’expérience négatif sur htmx

  • Les outils d’IA sont familiers de Next.js, mais pas de htmx. Cela suggère une prévision importante sur l’avenir des outils de développement
  • Certains prédisent que les LLM renforceront les dynamiques actuelles de winner-takes-all et encourageront l’usage d’outils open source

• Lors de la création de formulaires complexes, la logique côté serveur est devenue plus compliquée et plus difficile que le travail côté client avec React

  • Il existe même un mème qui rappelle qu’il faut aussi implémenter la validation côté serveur

• Ils voulaient garder le frontend léger avec htmx, mais ont fini par utiliser des bibliothèques tierces pour gérer une UI/UX complexe et l’état de l’application

  • Selon certains, si travailler avec React était plus simple, c’est surtout parce qu’ils utilisaient des bibliothèques tierces
  • Si l’on doit gérer un état complexe et le rendu, htmx n’aurait sans doute pas été un bon choix dès le départ

• Implémenter une interface en glisser-déposer avec htmx était difficile, alors qu’une bibliothèque React permettait une expérience plus fluide

  • Avec htmx, il vaut mieux n’utiliser que le bundle frontend strictement nécessaire
  • En exploitant l’événement htmx.onLoad, on peut repérer dans le contenu chargé le balisage portant des attributs et y connecter le comportement voulu

• L’équipe semblait plus à l’aise avec le développement frontend et a rencontré des difficultés dans la communication avec le backend

  • Ils reconnaissent les avantages des composants React ainsi que la facilité à trouver de la documentation et de l’aide

• Certains estiment que le processus de développement était plus naturel avec Next.js

  • D’autres trouvent toutefois que la syntaxe de ReactJS n’a rien de naturel

• Certains trouvent intéressant que HTMX partage ce type de retour d’expérience et rappellent qu’il existe aussi des projets pour lesquels HTMX seul ne suffit pas

  • Ils soulignent à nouveau la nécessité de valider les formulaires aussi côté backend
  • Le cas d’une équipe devenue très dépendante des outils d’IA est jugé intéressant
  • Certains estiment qu’il faudrait des plugins pour compenser les limites de HTMX

• HTMX.org est salué pour héberger ce type d’essai

• Il existe des inquiétudes sur le fait que les outils d’IA puissent rendre plus difficile l’adoption de nouveaux frameworks ou langages de programmation

  • Certains imaginent un impact sur les outils de développement comparable à celui du SEO