Por qué seguimos eligiendo Next.js sobre Astro para SaaS en 2026

Next.js es un framework React full-stack que renderiza páginas, gestiona el enrutado y ejecuta lógica del servidor en un único proceso. Astro es un constructor de sitios orientado a contenido que envía casi cero JavaScript por defecto y solo hidrata las islas que realmente necesitan interactividad. En 2026 la pregunta para un equipo SaaS no es cuál es mejor en abstracto. Es cuál encaja con la forma del producto que estás construyendo.

La mayoría de los SaaS tienen una app autenticada en el centro. Un dashboard, un panel de ajustes, un workspace, un portal de facturación. Esas pantallas leen y escriben datos del usuario en cada navegación, mantienen estado entre componentes y dependen de cookies de sesión que el servidor debe verificar en cada petición. Next.js fue diseñado para esa forma. Astro puede cubrir una parte sorprendente con server islands, server actions y la Sessions API, pero cuanto más te acercas a la superficie real de un producto, más acabas montando librerías que rellenan lo que el framework no posee. Hemos enviado ambos este año. Para un SaaS, Next.js sigue siendo nuestra opción por defecto.

TL;DR

Elige Next.js cuando el sitio es el producto. Elige Astro cuando el sitio es contenido alrededor del producto. Si tienes un solo codebase y ese codebase debe alojar signup, login, dashboards y billing, Next.js encaja. Si tienes un sitio de marketing separado hecho sobre todo de páginas, posts, documentación y pricing, Astro es más rápido y más barato de operar. La brecha se está ampliando en ambas direcciones: Next.js mantiene la cuota dominante en nuevos proyectos React de empresa en 2026, y Astro fue adquirido por Cloudflare en enero de 2026, una apuesta seria por la arquitectura de islas para contenido (Alex Bobes, 2026).

Dónde gana Next.js para SaaS

Un solo repo para la app y su API

Next.js 16 envía Turbopack como bundler por defecto tanto en next dev como en next build, y el React Compiler es estable en producción (Vercel, 2026). El framework posee renderizado, routing, server actions, route handlers, middleware y edge functions dentro de un único proyecto. Para un SaaS esto importa porque el mismo git push despliega el dashboard, el callback de auth, el webhook de Stripe y el endpoint de subida. No hay un segundo servicio que mantener sincronizado, ni tipos compartidos atravesando una red, ni un segundo pipeline de despliegue.

Astro puede alojar route handlers y añadió server actions tipadas en la versión 4.15 con validación Zod integrada (Astro Actions). Es realmente capaz. Pero en el momento en que necesitas un proceso long-lived, una cola de workers o un websocket, Astro te empuja a un runtime separado y la historia integrada se rompe.

Sesiones, autenticación y middleware

Los SaaS viven de cookies de sesión. El middleware de Next.js corre en cada petición, puede leer y reescribir cookies, comprobar el estado de auth y redirigir a usuarios anónimos a /login antes de que cualquier página renderice. El patrón está documentado y las librerías de la comunidad (NextAuth, Supabase Auth, Clerk, Lucia) asumen todas esta superficie.

Astro añadió una Sessions API que guarda datos en el servidor y está disponible dentro de las actions, e integra con auth-astro y Better Auth. La trampa está en la documentación: las sesiones no se soportan en middleware edge y requieren server-side rendering para funcionar. Si una página está prerenderizada, los datos de sesión no están disponibles (Astro Sessions). Para un SaaS eso significa que la mayoría de páginas, las que dependen del usuario, no pueden prerenderizarse. Lo que hace Astro rápido en marketing es justo lo que no puedes usar en la app.

El ecosistema React 19 aterriza primero

Un dashboard SaaS suele apoyarse en TanStack Query, primitivas headless UI, gráficos, drag-and-drop, formularios complejos, file pickers, editores de texto enriquecido. Esas librerías asumen un único árbol React. Next.js te lo da de forma nativa. Astro puede renderizar islas React, y dentro de una isla puedes montar cualquiera de esas librerías, pero cada isla es su propio límite JavaScript, lo que complica compartir estado entre componentes de la misma página.

En concreto: en un dashboard Next.js, un filtro de sidebar y un gráfico se suscriben a la misma caché de TanStack Query sin ceremonia. En Astro, dos islas no pueden compartir un mismo cliente de React Query sin exportar un singleton desde un módulo vanilla y conectar cada isla a él.

Las novedades de React aterrizan antes en Next.js

Next.js 16 incluye funcionalidades de React 19.2 como View Transitions, useEffectEvent y Activity para mantener árboles de fondo montados pero ocultos. El React Compiler es estable y memoiza componentes automáticamente. Son las funcionalidades de las que se beneficia un dashboard bajo carga, y llegan a Next.js en el momento en que se estabilizan porque el App Router sigue el canary de React.

Dónde gana Astro

Páginas de marketing y pricing

Para una home, una página de pricing, una grid de features, un formulario de contacto, Astro es difícil de batir. La salida por defecto es HTML estático con cero JavaScript e hidratación selectiva mediante Islands architecture. Informes de producción sitúan las páginas Astro alrededor de 18 KB de JavaScript frente a 180 KB de un setup Next.js equivalente cargado de React, según las decisiones de hidratación. Para los Core Web Vitals de un sitio marketing esa diferencia importa.

Documentación

La documentación es un árbol de contenido con bloques de código, búsqueda y pequeños widgets interactivos. Es justo la forma para la que se construyó Astro. Starlight, el starter oficial de docs, te da búsqueda, navegación lateral, resaltado de sintaxis e i18n de serie, y el resultado es un sitio estático que carga en menos de un segundo en una 3G.

Blogs de contenido

Para un blog de contenido, las content collections de Astro más la Content Layer API de Astro 5 hacen que Markdown y MDX sean ciudadanos de primera clase. Las Server Islands permiten inyectar snippets personalizados (carrito, foto de perfil, variante A/B) en una página por lo demás completamente estática (Astro Server Islands). El resultado es un blog que envía cero JavaScript en cada artículo y se mantiene en verde en Core Web Vitals.

¿Y un híbrido?

El patrón que aparece con frecuencia: sitio marketing en Astro, app en Next.js, dos despliegues separados en subdominios distintos (www y app). Es una arquitectura válida y la hemos enviado. El coste es real:

• Dos repositorios, dos pipelines de CI, dos targets de despliegue, dos juegos de variables de entorno.
• El estado de autenticación tiene que atravesar subdominios: dominio de cookie, CORS, URLs de redirect de OAuth.
• Los design tokens y los componentes primitivos hay que compartirlos, normalmente como un paquete npm privado.
• Analítica, feature flags, error reporting y observabilidad corren dos veces.

Para un equipo de dos, el overhead no compensa los KB ahorrados en marketing. Para un equipo de quince con un equipo de contenido dedicado y un sitio marketing que trae tráfico orgánico de verdad, puede compensar. El disparador no es técnico, es la forma del equipo.

Qué usamos y por qué

Para el sitio del propio Studio y para cada SaaS enviado en 2026 la respuesta es Next.js. Las razones, en orden:

1. Un codebase, un despliegue, un runtime. Las páginas de marketing y la app autenticada viven bajo el mismo router. Añadir una nueva ruta de dashboard es un archivo en /app/dashboard. Añadir una nueva página de pricing es un archivo en /app/pricing. Sin coser subdominios.
2. La historia de sesiones está cerrada. El middleware corre en cada petición, lee la cookie de auth y redirige a los no autenticados antes del render. Desarrolladores junior lo extienden sin leer el código del framework.
3. Las funcionalidades de React 19 aterrizan primero. View Transitions, React Compiler, server actions y las caching APIs refinadas (updateTag, revalidateTag) llegan a Next.js el día en que se estabilizan.
4. El inconveniente, el tamaño del bundle en páginas marketing, lo mitigamos con route segments que excluyen client components y con límites de componente disciplinados. Nuestras rutas marketing envían menos de 50 KB de JavaScript sin salir de Next.js.

Si un cliente llega con un sitio denso en contenido (alrededor de 100 páginas de editorial estructurado, sin app autenticada), Astro es la respuesta correcta y no lo empujamos hacia Next.js. La elección del framework sigue a la forma del producto, no a nuestras preferencias. Para cualquier cosa que llamaríamos SaaS, la forma dice Next.js. Ver también nuestras notas sobre el React Compiler en producción y sobre Server vs Client Components para entender cómo estructuramos esas apps Next.js a diario.

En 2026 ambos frameworks son lo bastante maduros como para que elegir cualquiera sea defendible. La pregunta es qué problema estás resolviendo. SaaS significa app primero, contenido después. Ese orden hace de Next.js la opción por defecto más segura.