En 2026 el frontend “serio” converge en tres ejes: **TypeScript por default**, **server-first rendering** y **métricas de interacción (INP)**. Dentro de React, eso se materializa en **React Server Components (RSC)** y Server Functions.

## Qué resuelven los RSC

Los Server Components corren en el servidor: data access, lógica sensible y UI que **no necesita hidratarse** en el cliente. El resultado típico reportado en case studies es un **render inicial mucho más liviano** cuando el cuello de botella era el bundle de cliente.

Server Functions permiten invocar lógica de servidor desde el cliente **sin inventar un endpoint REST por cada click**, siempre mediado por el framework (Next.js y otros meta-frameworks).

## Cuándo adoptar (y cuándo no)

**Adoptá RSC si:**

- La app es data-heavy y el presupuesto de JS de cliente se rompe. - Ya estás (o querés estar) en App Router / meta-framework con soporte maduro. - Podés migrar **por rutas o features**, no big-bang.

**No migres aún si:**

- El SPA actual cumple INP/LCP y el equipo no tiene capacidad de reescritura. - El valor está en interactividad densa en cliente (canvas, editors) donde el server no ayuda. - No hay disciplina de “qué corre dónde” — RSC sin ownership es deuda nueva.

## RSC vs islands (Astro)

En un portfolio **Astro**, React no es el shell: es un **island**. Eso ya es server-first HTML + JS puntual. RSC brilla más en productos React-centric (dashboards, apps con mucho data fetching por ruta). El principio es el mismo: **menos JS al cliente por defecto**.

## Checklist 2026

1. Medí INP y LCP antes/después; no migres a ciegas. 2. TypeScript estricto en boundaries servidor/cliente. 3. No filtrar secretos ni ORM al bundle de cliente. 4. Preferí migración incremental a rewrites heroicos.

**Cierre:** RSC no mató a React client components. Redefinió el default: **el servidor renderiza; el cliente interactúa solo donde hace falta**.