React Server Components no van a matar tu SPA

Los React Server Components llegaron con promesas de revolucionar cómo pensamos el frontend. Mejor performance, menos JavaScript al cliente, hidratación selectiva. Todo suena genial en el papel.

Pero después de trabajar con RSC en proyectos reales, la cosa no es tan simple. No estamos ante el reemplazo definitivo del patrón cliente tradicional, sino ante una herramienta más con casos de uso específicos.

Qué resuelven realmente los Server Components

Los RSC atacan problemas concretos del desarrollo React tradicional:

Waterfalls de datos: En lugar de hacer fetch después del mount, podés obtener datos directamente en el servidor antes de renderizar.

Bundle size: Los componentes del servidor no suman al JavaScript que baja al cliente.

Performance inicial: La primera renderización es más rápida porque viene pre-renderizada del servidor.

Hasta acá, todo tiene sentido. Pero cada solución trae sus propios trade-offs.

Los casos donde RSC brillan

Dashboards y páginas de contenido

Si tenés una página que muestra datos de una API y no necesita mucha interacción, RSC es ideal:

// UserProfile.server.js
import { getUserData } from './api';

export default async function UserProfile({ userId }) {
  const user = await getUserData(userId);
  
  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.email}</p>
      <UserPosts posts={user.posts} />
    </div>
  );
}

El componente se ejecuta en el servidor, obtiene los datos, y manda HTML listo al cliente. Sin waterfalls, sin loading states.

E-commerce y landing pages

Páginas donde la performance inicial es crítica y la interacción es limitada. Un catálogo de productos, por ejemplo, se beneficia enormemente de RSC.

Dónde los Server Components no funcionan

Aplicaciones con estado complejo

Si tu app maneja estado global, formularios complejos, o interacciones en tiempo real, RSC se vuelve un problema más que una solución.

// Esto NO funciona en un Server Component
function TodoApp() {
  const [todos, setTodos] = useState([]);
  const [filter, setFilter] = useState('all');
  
  // Los hooks de estado no existen en el servidor
  // useEffect tampoco
  // Ni event handlers
}

Apps que dependen de APIs externas en tiempo real

Si tu aplicación consume WebSockets, Server-Sent Events, o APIs que cambian constantemente, el modelo servidor-cliente se complica.

Interacciones pesadas del lado cliente

Drag & drop, editors de código, dashboards interactivos. Todo lo que requiera manipulación DOM directa o librerías cliente-específicas no funciona con RSC.

El problema real: complejidad arquitectónica

La mayor complicación de RSC no es técnica, es conceptual. Ahora tenés que pensar en dos contextos de ejecución:

• ¿Este componente puede ser servidor?
• ¿Qué pasa si necesito estado después?
• ¿Cómo manejo errores en el servidor vs cliente?
• ¿Dónde va la lógica de autenticación?

En proyectos chicos o con equipos junior, esta complejidad puede ser contraproducente.

Cuándo seguir con el patrón tradicional

Equipos pequeños o sin experiencia en SSR

Si tu equipo recién está aprendiendo React, agregar RSC es como saltar etapas. Mejor que dominen primero el ciclo cliente tradicional.

Apps con mucha interactividad

Calculadoras, juegos, editors, herramientas de diseño. Si el 80% de tu funcionalidad requiere JavaScript del lado cliente, RSC no te va a dar ventajas significativas.

Proyectos con deadlines ajustados

RSC requiere replantear la arquitectura. Si tenés que entregar rápido, el patrón SPA tradicional sigue siendo más predecible.

La combinación híbrida que funciona

Lo interesante es que no tenés que elegir uno u otro. Podés usar RSC para las partes que se benefician y mantener componentes cliente donde los necesitás:

// ProductPage.server.js
import ProductDetails from './ProductDetails.server';
import AddToCart from './AddToCart.client'; // Componente cliente

export default async function ProductPage({ productId }) {
  const product = await getProduct(productId);
  
  return (
    <div>
      <ProductDetails product={product} /> {/* Server */}
      <AddToCart productId={productId} />   {/* Cliente */}
    </div>
  );
}

Consideraciones de deployment

RSC requiere un servidor Node.js ejecutándose. Si estás acostumbrado a deployar SPAs en CDNs estáticas, esto cambia tu infrastructure:

• Necesitás un servidor que corra 24/7
• Caching se vuelve más complejo
• Cold starts pueden afectar performance
• Costos de hosting aumentan

El futuro no es binario

La industria no se va a dividir entre "RSC" y "SPA". Los frameworks están evolucionando hacia modelos híbridos donde podés elegir el patrón apropiado para cada parte de tu aplicación.

Next.js 13+, Remix, y otros frameworks ya ofrecen esta flexibilidad. La pregunta no es "¿RSC o SPA?", sino "¿qué patrón para cada funcionalidad?".

Recomendaciones prácticas

Empezá con RSC si:

• Tu app es principalmente de lectura (dashboards, blogs, e-commerce)
• La performance inicial es crítica
• Tenés experiencia con SSR

Mantené el patrón cliente si:

• Tu app requiere mucha interactividad
• El equipo no tiene experiencia con rendering servidor
• Los deadlines son ajustados

Considerá un enfoque híbrido si:

• Tenés partes estáticas y partes interactivas
• Podés invertir tiempo en arquitectura
• La performance y UX son prioritarias

Los React Server Components son una adición valiosa al ecosistema, pero no son la bala de plata que va a reemplazar todo lo que conocemos. Como toda herramienta, tienen su lugar específico en el toolbox del desarrollador frontend.