TanStack a officiellement cessé d'utiliser les React Server Components (RSC) dans ses bibliothèques, citant la complexité accrue, la flexibilité réduite, des gains de performance modestes et un ralentissement de la vitesse de développement comme facteurs décisifs. Ce changement est important pour quiconque développe des outils basés sur React, car les bibliothèques de TanStack sont largement adoptées et définissent souvent des standards pratiques pour l'écosystème.

Pourquoi les RSC semblaient attractifs

Les React Server Components sont arrivés comme un moyen de déporter les tâches lourdes de récupération de données (data-fetching) et de rendu vers le serveur, promettant des bundles clients plus petits et des chargements de pages plus rapides. L'équipe TanStack a testé cette approche, espérant améliorer l'expérience utilisateur de ses bibliothèques de data-grid et de query.

Ce qui les a fait reculer

  • Complexité – Le débogage du code RSC imposait un modèle mental distinct. L'équipe a passé plus de temps à tracer les problèmes de rendu côté serveur qu'elle ne pouvait se le permettre.
  • Flexibilité – De nombreuses bibliothèques tierces supposent un environnement purement client. L'exécution exclusivement côté serveur des RSC rendait l'intégration difficile sans réécrire ou créer des shims pour ces dépendances.
  • Performance – Les améliorations de vitesse mesurées étaient modestes. Le surcoût lié à l'orchestration des frontières entre serveur et client l'emportait sur les gains marginaux dans la plupart des scénarios réels.
  • Vélocité – Des modèles plus simples, uniquement côté client, permettaient à l'équipe de livrer des mises à jour plus rapidement. Avec les RSC, chaque changement nécessitait une validation à la fois sur le serveur et sur le client, ralentissant le cycle de publication.

Les enjeux plus larges

Si un ensemble d'outils de premier plan comme TanStack revient sur les RSC, d'autres projets pourraient reconsidérer l'engouement suscité. Cette décision met en lumière un compromis : les fonctionnalités de pointe peuvent introduire des coûts cachés qui nuisent à la productivité des développeurs et à la maintenance à long terme. Les entreprises qui privilégient l'itération rapide et une large compatibilité des bibliothèques pourraient suivre cet exemple.

Contre-point

Certains développeurs voient encore de l'intérêt dans les RSC pour des cas d'utilisation spécifiques — en particulier là où le traitement des données côté serveur peut réduire considérablement la taille de la charge utile (payload). L'approche pourrait évoluer, et les futurs outils pourraient résoudre les points de friction identifiés par TanStack. Pour l'instant, le consensus reste mitigé.

Ce qu'il faut surveiller ensuite

  • Mises à jour des outils – Des améliorations dans le débogage et le support de l'intégration pourraient abaisser la barrière de la complexité.
  • Retours de la communauté – À mesure que davantage d'équipes partageront des données de performance, l'équation coût-bénéfice pourrait changer.
  • Modèles alternatifs – Des techniques de rendu serveur incrémental ou des approches hybrides pourraient offrir un juste milieu.

À retenir : Le retrait de TanStack des React Server Components nous rappelle que le plus récent n'est pas toujours le meilleur ; les développeurs doivent peser le coût réel pour leur flux de travail par rapport aux gains promis avant d'adopter de nouveaux modèles.

Source: https://tanstack.com/blog/we-stopped-using-rsc-on-tanstack-com