Astro frente a Next, Nuxt, SvelteKit y Remix
En qué se parecen y en qué difieren: Astro es agnóstico de framework y MPA-first frente a los meta-frameworks app-first atados a una librería. Cuándo elegir Astro y, con la misma honestidad, cuándo no.
Next.js, Nuxt, SvelteKit y Remix son excelentes, y comparten mucho con Astro: renderizado en servidor, rutas por ficheros, despliegue en el edge. Pero nacen de una premisa distinta —construir aplicaciones— mientras que Astro nace para construir contenido. Saber dónde está esa frontera es lo que te deja elegir bien en lugar de por moda.
- Situar el eje que separa a Astro de los meta-frameworks: MPA-first vs app-first.
- Entender qué significa que Astro sea agnóstico de framework y qué cuesta.
- Reconocer en qué se parecen todos y dónde deja de importar la diferencia.
- Decidir con criterio cuándo elegir Astro y cuándo elegir otra cosa.
El eje que los separa: app-first contra MPA-first
Next (React), Nuxt (Vue), SvelteKit (Svelte) y Remix (React) son meta-frameworks app-first. Su unidad de partida es la aplicación: un framework de componentes que se hidrata, un router de cliente, y la asunción de que el JavaScript es el sustrato natural de la página. Han incorporado renderizado en servidor y, en el caso de Next, hidratación parcial vía React Server Components —así que la línea se difumina—, pero su centro de gravedad sigue siendo la app interactiva.
Astro es MPA-first y content-first. MPA significa Multi-Page Application: cada ruta es un documento HTML completo servido por separado, sin un router de cliente que intercepte la navegación por defecto. El sustrato es el HTML, y la interactividad es la excepción declarada isla a isla. No es que Astro no pueda hacer SSR dinámico —puede, con endpoints, actions y sesiones—, sino que su punto de partida es el opuesto al de un meta-framework.
En una frase, el contraste es de valores por defecto:
- App-first: el JavaScript viene de serie y quitarlo es trabajo cuesta arriba.
- MPA-first: el HTML viene de serie y añadir JavaScript es una decisión consciente.
La objeción clásica al MPA es que recargar toda la página en cada navegación se siente lento. Astro lo resuelve con la API de View Transitions: transiciones suaves entre páginas que dan sensación de SPA sin renunciar al modelo de documentos. Obtienes la fluidez sin el coste del router de cliente ni la hidratación global.
Los cuatro meta-frameworks, en breve
Aunque los agrupemos bajo la misma etiqueta, cada uno tiene su carácter:
Next.js
El meta-framework de React. Con el App Router y los Server Components empuja fuerte la hidratación parcial, pero sigue asumiendo React como sustrato de toda la página.
Nuxt
El equivalente para Vue: SSR, rutas por ficheros y un ecosistema de módulos enorme. App-first construido sobre Vue.
SvelteKit
El framework oficial de Svelte. Compila a JavaScript muy ligero, pero su modelo sigue siendo el de una app que se hidrata entera.
Remix
Nacido alrededor de los estándares web y los formularios; hoy convergido con React Router. App-first sobre React.
Agnóstico de framework
La segunda gran diferencia es la libertad de librería. Cada meta-framework está casado con una: Next con React, Nuxt con Vue, SvelteKit con Svelte. Astro no se casa con ninguna. Mediante integraciones oficiales puedes usar React, Vue, Svelte, Solid o Preact —incluso varias a la vez en la misma página, cada una como isla independiente—.
---
import CardReact from '../components/CardReact.jsx';
import GraficoVue from '../components/GraficoVue.vue';
import MenuSvelte from '../components/MenuSvelte.svelte';
---
<!-- Tres frameworks conviviendo como islas en un mismo documento -->
<CardReact client:load />
<GraficoVue client:visible />
<MenuSvelte client:idle />Esto tiene consecuencias prácticas: migrar de forma incremental, reutilizar componentes de distintos ecosistemas, o no atarte a las decisiones futuras de una sola comunidad. Para el contenido, el .astro nativo suele bastar, y las islas cubren el resto sin imponerte un dogma.
Mezclar frameworks es posible, pero cada uno que hidratas trae su propio runtime. Dos islas de React comparten runtime; una de React y otra de Vue, no. El agnosticismo es una herramienta de flexibilidad y de migración gradual, no una invitación a cargar cinco frameworks en la home sin pensarlo.
En qué se parecen
No todo es diferencia. En muchas cosas Astro y los meta-frameworks convergen, y conviene no exagerar la distancia:
Rutas por ficheros
Todos derivan las rutas de la estructura de carpetas. La ergonomía del enrutado es casi idéntica.
SSR y SSG
Todos hacen renderizado estático y en servidor, y despliegan en el edge con adaptadores.
Base en Vite
Astro, Nuxt y SvelteKit comparten Vite. La experiencia de desarrollo se parece mucho.
Hidratación parcial
Next con RSC y Astro con islas persiguen la misma meta: enviar menos JavaScript al cliente.
La convergencia es tal que muchos patrones se transfieren casi sin fricción entre ellos. Incluso la navegación fluida, antes exclusiva de las SPA, hoy está al alcance de un MPA con una sola línea de configuración:
---
import { ClientRouter } from 'astro:transitions';
---
<head>
<ClientRouter />
</head>La diferencia rara vez está en lo que puedes hacer —casi todo es posible en todos— sino en lo que cada uno hace fácil y por defecto. Y ese “por defecto” es justo lo que más moldea un proyecto a lo largo de los meses.
Donde de verdad divergen es en las decisiones que no ves hasta que el proyecto crece:
- JavaScript de base: cero en Astro por defecto; el runtime del framework en todos los demás.
- Router: de documentos en Astro; de cliente en los meta-frameworks.
- Lock-in de librería: ninguno en Astro; total en Next, Nuxt y SvelteKit.
Cuándo elegir Astro y cuándo no
La pregunta correcta no es cuál es “mejor”, sino dónde cae tu proyecto en el espectro de contenido a aplicación.
flowchart LR A[Contenido puro] -->|Astro| B[Hibrido] -->|Next Nuxt SvelteKit Remix| C[App interactiva] -->|SPA| D[App de estado global] style A fill:#a6e3a1,color:#11111b style B fill:#94e2d5,color:#11111b style C fill:#f9e2af,color:#11111b style D fill:#f38ba8,color:#11111b
- Elige Astro para blogs, documentación, marketing, landings, portfolios y catálogos de e-commerce: sitios donde el contenido domina, el SEO es crítico y la interactividad es puntual.
- Elige un meta-framework cuando el corazón del producto es una aplicación: un dashboard, un editor, una herramienta con estado compartido entre rutas, tiempo real intenso o sesiones largas de uso.
- La zona gris —una tienda con mucho catálogo pero también mucha cuenta de usuario— admite ambas; el desempate está en qué pesa más, el contenido público o la app privada.
Hay un test rápido y sorprendentemente fiable. Pregúntate qué haría un usuario si le desactivaras el JavaScript. Si tu sitio sigue siendo útil —se lee, se navega, se indexa—, es contenido y Astro encaja de forma natural. Si se queda en una pantalla en blanco porque todo dependía del cliente, es una aplicación, y un meta-framework te servirá mejor sin pelear contra la herramienta.
Ninguna de estas herramientas está quieta. Next empuja los Server Components; Astro añade actions, sesiones y server islands para cubrir más terreno dinámico. El eje contenido-aplicación no desaparece, pero el punto donde te conviene cambiar de herramienta se desplaza con cada versión. Reevalúa la decisión por proyecto, no de una vez para siempre.
El error de principiante es tratar la elección de framework como un ranking universal, cuando es un problema de adecuación entre herramienta y forma del problema. Astro y Next no compiten por el mismo trono: optimizan cosas distintas porque parten de premisas distintas. Astro apuesta a que la mayoría de la web es contenido, y hace del cero-JS el estado por defecto; un meta-framework apuesta a que estás construyendo una aplicación, y hace del JavaScript el sustrato natural. Usar Astro para un dashboard colaborativo en tiempo real es forzar la herramienta; usar Next para un blog de mil artículos estáticos es pagar un impuesto de hidratación que no necesitabas. La madurez técnica no es tener una favorita, sino saber leer la forma de tu proyecto —cuánto es documento y cuánto es aplicación— y coger la herramienta que empuja en esa dirección. Elegir bien es, casi siempre, elegir la que hace fácil lo que tú vas a hacer a menudo.
- Piensa en tres webs que uses: una claramente de contenido, una claramente aplicación y una intermedia.
- Sitúa cada una en el espectro contenido-aplicación del diagrama de arriba.
- Para la intermedia, aplica el test del JavaScript desactivado: ¿sobrevive como documento o se cae?
- Decide qué herramienta elegirías para cada una y escribe una frase justificando cada elección. Ese razonamiento es el objetivo del nivel.