TanStack ha dejado de utilizar oficialmente React Server Components (RSC) en sus librerías, citando la complejidad añadida, la reducción de la flexibilidad, las modestas mejoras de rendimiento y una menor velocidad de desarrollo como factores decisivos. Este movimiento es importante para cualquiera que construya herramientas basadas en React, ya que las librerías de TanStack son ampliamente adoptadas y a menudo establecen estándares prácticos para el ecosistema.

Por qué RSC parecía atractivo

React Server Components llegaron como una forma de trasladar el pesado trabajo de obtención de datos (data-fetching) y renderizado al servidor, prometiendo paquetes de cliente (client bundles) más pequeños y cargas de página más rápidas. El equipo de TanStack probó este enfoque con la esperanza de mejorar la experiencia de usuario de sus librerías de data-grid y query.

Qué los alejó

  • Complejidad – Depurar código RSC obligaba a utilizar un modelo mental distinto. El equipo pasó más tiempo rastreando problemas de renderizado en el lado del servidor de lo que podía permitirse.
  • Flexibilidad – Muchas librerías de terceros asumen un entorno puramente de cliente. La ejecución exclusiva del servidor de RSC dificultaba la integración sin tener que reescribir o crear adaptadores (shims) para esas dependencias.
  • Rendimiento – Las mejoras de velocidad medidas fueron modestas. La sobrecarga de orquestar los límites entre el servidor y el cliente superó las ganancias marginales en la mayoría de los escenarios del mundo real.
  • Velocidad – Los patrones más simples, exclusivos de cliente, permitieron al equipo lanzar actualizaciones más rápido. Con RSC, cada cambio requería validación tanto en el servidor como en el cliente, lo que ralentizaba el ciclo de lanzamientos.

Lo que está en juego a mayor escala

Si un conjunto de herramientas líder como TanStack da un paso atrás con respecto a RSC, otros proyectos podrían reconsiderar el entusiasmo (hype) que lo rodea. La decisión resalta un compromiso (trade-off): las características de vanguardia pueden introducir costes ocultos que perjudican la productividad del desarrollador y el mantenimiento a largo plazo. Las empresas que priorizan la iteración rápida y la amplia compatibilidad de librerías podrían seguir su ejemplo.

Contrapunto

Algunos desarrolladores aún ven valor en RSC para casos de uso específicos, especialmente donde el procesamiento de datos en el lado del servidor puede reducir drásticamente el tamaño de la carga útil (payload). El enfoque puede evolucionar, y las futuras herramientas podrían abordar los puntos de dolor que TanStack identificó. Por ahora, el consenso sigue siendo mixto.

Qué observar a continuación

  • Actualizaciones de herramientas – Las mejoras en la depuración y el soporte de integración podrían reducir la barrera de la complejidad.
  • Comentarios de la comunidad – A medida que más equipos compartan datos de rendimiento, la ecuación de coste-beneficio podría cambiar.
  • Patrones alternativos – Las técnicas de renderizado incremental en el servidor o los enfoques híbridos podrían ofrecer un punto medio.

Conclusión: El retroceso de TanStack respecto a React Server Components nos recuerda que lo más nuevo no siempre es lo mejor; los desarrolladores deben sopesar el coste real para su flujo de trabajo frente a las ganancias prometidas antes de adoptar patrones emergentes.

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