Lo que me hubiera gustado saber antes de migrar 50 mil líneas de código a React Server Components

• Un artículo sobre las experiencias y lecciones aprendidas por el autor al migrar 50,000 líneas de código a React Server Components (RSCs)
• Los RSCs son componentes de React que se ejecutan en el servidor en lugar del cliente, y ofrecen dos ventajas principales frente al renderizado del lado del servidor (SSR)
  • Primero, los RSCs permiten a los desarrolladores definir dónde se ejecuta el código, lo que reduce el tamaño del bundle y disminuye el trabajo durante la hidratación
  • Segundo, los componentes de servidor obtienen datos directamente dentro del componente y los transmiten en streaming al cliente, lo que hace que la obtención de datos en React sea más sencilla y eficiente
• Sin embargo, usar RSCs tiene algunas limitaciones. CSS-in-JS no funciona en componentes de servidor, React Context solo es accesible desde componentes de cliente, y la complejidad de gestionar dónde se ejecuta el código puede ser un reto
• El autor propone un enfoque de 3 pasos para adoptar RSCs de forma gradual:
  • Agregar la directiva "use client" en la raíz de la app
  • Mover la directiva lo más abajo posible en el árbol de renderizado
  • Adoptar patrones avanzados cuando aparezcan problemas de rendimiento
• A pesar de la complejidad adicional, el autor concluye que las ventajas de los RSCs, como bundles más pequeños, ejecución más rápida y patrones avanzados de carga de datos, pueden superar el costo si las mejoras de rendimiento valen la pena para el equipo

[GN⁺]

Comentarios en Hacker News

• El artículo trata sobre la discusión de migrar 50K líneas de código a React Server Components (RSCs).
• Algunos usuarios mencionaron la velocidad y simplicidad del renderizado del lado del servidor, y señalaron que el cliente recibe HTML que puede ver de inmediato.
• Hay quienes sugieren que considerar frameworks web clásicos o de stack completo como Rails, Django o Laravel podría ser una solución más rápida y escalable que usar RSCs.
• Algunos usuarios expresaron preocupación por la complejidad de los frameworks modernos, mencionando los extensos pipelines de build y compilación requeridos incluso para tareas simples.
• Los usuarios compartieron experiencias personales con next.js y su nueva configuración del directorio app, destacando la dificultad de entender dónde ocurre el trabajo (servidor o cliente) y los problemas con librerías de React existentes que asumen trabajo del lado del cliente.
• Algunos usuarios señalaron bugs y asperezas en el nuevo paradigma del directorio app de next.js, incluidos problemas relacionados con rutas dinámicas y rutas paralelas.
• Un usuario mencionó la similitud entre PHP y JavaScript, y señaló que JavaScript ha evolucionado para ofrecer funcionalidad similar del lado del servidor, aunque con más siglas y una curva de aprendizaje más pronunciada.
• Algunos usuarios cuestionaron la necesidad de usar React para tareas que podrían resolverse con herramientas más simples, como generadores de sitios estáticos o un CMS con caché.
• Hay un sentimiento de nostalgia por la época en que el servidor renderizaba todo y CSS y JavaScript mejoraban la página después del renderizado.
• Algunos usuarios expresaron la opinión de que React se está volviendo más complejo para ponerse al día con alternativas modernas, más fáciles y rápidas.
• Existe un debate sobre usar React para renderizar HTML en el backend: algunos usuarios cuestionan su necesidad y otros defienden sus ventajas frente a los métodos tradicionales de respuesta del servidor.