La fatigue de la gestion des dépendances : pourquoi j’ai abandonné React au profit de Go+HTMX+Templ

• Cette année, après avoir mené un projet personnel avec Go, HTMX et Templ, j’ai décidé d’abandonner React
  • On peut trouver sur le site officiel de HTMX plusieurs arguments convaincants pour abandonner React et choisir HTMX, mais j’ai l’impression que peu de gens parlent de la fatigue liée à la gestion des dépendances
• Qu’est-ce que la « fatigue de la gestion des dépendances » ?
  • Lors de mon dernier projet personnel utilisant React (un dictionnaire catalan interactif), j’ai réalisé que je passais beaucoup trop de temps à mettre à jour les dépendances des packages React
  • Quand je mettais à jour les packages vers leur dernière version, cela entraînait souvent des changements majeurs dans les API, ce qui m’obligeait à investir du temps dans le refactoring du code
  • Comme la web app était déployée comme service public sur une instance EC2, je voulais continuer à maintenir les mises à jour des dépendances
• A-t-on vraiment besoin de nouvelles versions majeures ?
  • Des packages comme wouter (un package de routage React) et TanStackQuery (utilisé pour récupérer des données depuis le backend, les mettre en cache et gérer l’état) ont gravement cassé la web app à cause de mises à jour de version majeure.
  • Quand la première mise à jour majeure a cassé l’application, j’ai refactoré le code sans me poser de questions, mais lorsque cela s’est produit une deuxième fois, j’ai commencé à m’interroger.
  • Je me suis demandé quels bénéfices réels la web app tirait de ces versions majeures, en dehors des correctifs de sécurité.
  • Je me suis demandé s’il était vraiment nécessaire de casser cinq fois l’API de composants clés.
  • Je me suis interrogé sur tout le temps perdu, alors qu’il aurait pu servir à lancer de nouvelles fonctionnalités ou d’autres produits.
• Le problème du manque de temps
  • Comme je n’ai pas beaucoup de temps à consacrer à mes projets de code personnels, je ne veux pas le gaspiller à refactorer le code après chaque mise à jour majeure de dépendance.
  • Si vous construisez un produit pour des clients et prévoyez de facturer le travail de maintenance à venir, alors utiliser beaucoup de dépendances instables peut être acceptable.
  • En revanche, si vous voulez créer un produit demandant un minimum de maintenance, je resterais loin de l’écosystème JS.
• Utiliser Go+HTMX+Templ
  • La principale raison pour laquelle j’utilise Go+HTMX+Templ dans mes projets personnels est que les projets Go me permettent de me concentrer sur la livraison de fonctionnalités, sans pour autant ignorer les mises à jour habituelles de dépendances et de sécurité.
  • Le langage Go lui-même conserve une bibliothèque standard stable et une spécification du langage stable.

[bbulbum]

HTMX semble recevoir beaucoup d’avis positifs.
Je me demande si beaucoup de gens se tournent vers HTMX comme solution complémentaire pour les applications basées sur le SSR.
Je devrais essayer ça de mon côté une fois.

[savvykang]

Je n’ai pas choisi les bibliothèques TanStack, car elles sont inutilement complexes et la qualité de leur documentation s’est dégradée ces dernières années. Et comme le cycle de remplacement des packages npm est trop court, je me demande aussi s’il est vraiment nécessaire de toujours s’obstiner à utiliser la toute dernière version.

En revanche, dans le cadre du travail en entreprise, je ne pense pas qu’on puisse abandonner React. Pour un projet personnel, en revanche, peu importe ce qu’on utilise.

[dohyun682]

Tant qu’on évite les mises à jour de version majeure, les problèmes de dépendances ne sont pas si importants, non… ?

[aer0700]

J’ai récemment vu, parmi les tâches planifiées qui tournent en interne, un truc qui tourne encore sur Python 2, et ça m’a coupé le souffle.
Après réflexion, on s’est dit qu’il valait mieux le laisser tel quel pour l’instant, puisqu’il fonctionne bien. On ne pourra pas tenir éternellement sans le mettre à jour, cela dit.

[aer0700]

La fatigue de la gestion des dépendances VS l’ennui de réinventer la roue
C’est un vieux débat. Il vaut certes mieux ne pas utiliser de roue inutile, mais si on n’en a pas besoin aujourd’hui, est-ce qu’on n’en aura toujours pas besoin demain...
Je n’ai encore jamais utilisé Go, mais on voit beaucoup de serveurs construits avec Go ces temps-ci. Même si je ne l’utiliserai pas tout de suite, je devrais quand même m’y essayer au moins une fois.

[clickin]

HTMX est à la pointe des technologies à la mode, donc beaucoup de gens semblent l’essayer, mais je me demande s’il ne vaudrait pas mieux partir plutôt sur une approche comme go + vecty + gox.

[GN⁺]

Avis Hacker News

• Partage de l’expérience consistant à abandonner des bibliothèques comme React pour développer une application web avec Actix, Tera et HTMX. Cette stack offrirait une excellente maintenabilité et serait appréciée des utilisateurs.

  • L’auteur explique avoir rapidement développé une nouvelle application web puis l’avoir déployée auprès d’utilisateurs test.
  • L’absence de « fatigue liée à la gestion des dépendances » lui a permis d’acquérir une compréhension approfondie de ses outils.

• Les bibliothèques de Tanner sont jugées riches en fonctionnalités, mais faibles en matière de design d’API.

  • React Table et React Query sont puissants, mais leurs frontières seraient mal définies, ce qui poserait problème.
  • L’avantage de React serait précisément de ne pas être un framework, et de s’arrêter à des frontières bien conçues.
  • L’auteur dit essayer de n’adopter que des bibliothèques qui respectent ces critères.

• Les exemples HTMX donnent l’impression de déplacer la complexité ailleurs, et JSX est décrit comme une manière élégante d’éviter les templates.

  • Il resterait encore de nombreux problèmes à résoudre, comme le routage, la gestion d’état ou l’authentification.

• Il est jugé étrange de dire qu’on « abandonne React », le vrai problème venant selon certains d’autres dépendances.

  • Le choix d’écrire le backend en Go a toujours été possible.

• Il est rappelé qu’il faut s’attendre à des changements lors du passage à la prochaine version majeure d’un package.

  • L’exemple de Remix est cité pour expliquer comment appliquer progressivement les changements.
  • Il est affirmé qu’un bon package demande beaucoup d’efforts.

• Un retour d’expérience évoque la migration d’un projet SPA vers Django et HTMX, avec une forte réduction des dépendances JavaScript.

  • La SPA y est décrite comme une bombe à retardement.

• Il est soutenu que React n’est pas responsable des packages tiers mal maintenus.

  • Il est expliqué qu’il n’est pas nécessaire d’avoir un routeur ou un outil de gestion d’état comme Redux.

• Il est estimé que la v5 de react-query aurait dû être compatible avec l’API de la v3, tout en précisant que la migration est simple et non indispensable.

  • La « fatigue liée à la gestion des dépendances » est perçue comme exagérée, avec le conseil de conserver un nombre raisonnable de dépendances.

• Certains s’interrogent sur la raison d’une mise à niveau alors que l’application web n’en tirait aucun bénéfice supplémentaire.

  • Il est expliqué qu’une mise à niveau vers la dernière version n’apporte pas forcément d’avantage.

• Après avoir abandonné React et nextjs pour une autre stack, le stress aurait diminué et les mises à jour ne provoqueraient plus de déprime.