Ce que j’aurais aimé savoir avant de migrer 50 k lignes de code vers les React Server Components

• Un article sur l’expérience de l’auteur et les leçons tirées de la migration de 50 000 lignes de code vers les React Server Components (RSCs)
• Les RSCs sont des composants React qui s’exécutent sur le serveur plutôt que sur le client, et offrent deux avantages majeurs par rapport au server-side rendering (SSR)
  • Premièrement, les RSCs permettent aux développeurs de définir où le code s’exécute, ce qui réduit la taille des bundles et diminue le travail pendant l’hydration
  • Deuxièmement, les composants serveur récupèrent directement les données dans le composant et les diffusent en streaming vers le client, ce qui rend la récupération de données dans React plus simple et plus efficace
• Cependant, l’utilisation des RSCs comporte certaines limites. Le CSS-in-JS ne fonctionne pas dans les composants serveur, le React Context n’est accessible que dans les composants client, et la complexité liée à la gestion de l’emplacement d’exécution du code peut représenter un défi
• L’auteur propose une approche en 3 étapes pour adopter progressivement les RSCs :
  • ajouter la directive "use client" à la racine de l’application
  • déplacer la directive aussi bas que possible dans l’arbre de rendu
  • adopter des patterns avancés lorsque des problèmes de performance apparaissent
• Malgré la complexité supplémentaire, l’auteur conclut que les avantages des RSCs — comme des bundles plus petits, une exécution plus rapide et des patterns avancés de chargement des données — peuvent l’emporter sur les coûts si les gains de performance sont suffisamment importants pour l’équipe

[GN⁺]

Avis Hacker News

• L’article traite du passage de 50K lignes de code vers les React Server Components (RSCs).
• Certains utilisateurs ont mentionné la rapidité et la simplicité du rendu côté serveur, en soulignant que le client reçoit un HTML immédiatement visible.
• Certains suggèrent qu’au lieu des RSCs, envisager une solution full stack ou un framework web classique comme Rails, Django ou Laravel pourrait être plus rapide et plus évolutif.
• Certains utilisateurs ont exprimé des inquiétudes face à la complexité des frameworks modernes, évoquant les vastes pipelines de build et de compilation nécessaires même pour des tâches simples.
• Des utilisateurs ont partagé leur expérience personnelle avec next.js et sa nouvelle configuration du répertoire app, en soulignant la difficulté à comprendre où le travail s’effectue (sur le serveur ou le client), ainsi que les problèmes avec les bibliothèques React existantes qui partent du principe que le traitement se fait côté client.
• Certains utilisateurs ont signalé des bugs et des aspects encore rugueux dans le nouveau paradigme du répertoire app de next.js, y compris des problèmes liés aux routes dynamiques et aux routes parallèles.
• Un utilisateur a évoqué la similarité entre PHP et JavaScript, en notant que JavaScript a évolué pour offrir des fonctionnalités serveur similaires, bien qu’avec davantage d’acronymes et une courbe d’apprentissage plus raide.
• Certains utilisateurs ont remis en question la nécessité d’utiliser React pour des tâches qui pourraient être résolues avec des outils plus simples, comme des générateurs de sites statiques ou un CMS avec cache.
• On perçoit une certaine nostalgie pour l’époque où le serveur rendait tout et où CSS et JavaScript venaient enrichir la page après le rendu.
• Certains utilisateurs ont exprimé l’idée que React devient plus complexe pour rattraper des alternatives modernes, plus simples, plus faciles et plus rapides.
• Il existe un débat sur l’utilisation de React pour générer du HTML côté backend : certains en questionnent la nécessité, tandis que d’autres défendent ses avantages par rapport aux méthodes traditionnelles de réponse serveur.