Astro frente a Next, Nuxt, SvelteKit y Remix

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 —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. Astro puede hacer SSR dinámico —con endpoints, actions y sesiones— pero su punto de partida es el opuesto.

• 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.

El mismo objetivo, dos fronteras distintas

Next y Astro persiguen lo mismo —mandar menos JavaScript— pero trazan la frontera en sitios distintos. Un React Server Component corre en el servidor y no viaja; en cuanto un hijo lleva 'use client', ese subárbol se hidrata y además viaja el payload RSC: una descripción serializada del árbol renderizado en servidor que React necesita para coser ambas mitades.

En Astro, el equivalente no tiene zona wire salvo la que tú crees pasando props a una isla, y no hay runtime base: si no declaras isla, no baja nada.

La diferencia no es que uno sea rápido y el otro lento: es dónde está el suelo. En Next el suelo es el runtime de React; en Astro el suelo es cero y cada isla lo levanta un poco.

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—.

Esto permite migrar de forma incremental, reutilizar componentes de distintos ecosistemas y no atarte a las decisiones futuras de una sola comunidad. Para el contenido, el .astro nativo suele bastar.

Qué resuelven ellos que Astro no

La honestidad exige la dirección contraria. Hay problemas donde un meta-framework es la herramienta correcta y Astro te obligaría a pelear:

• Estado compartido entre rutas. Un carrito, un editor con borradores, una sesión de trabajo larga: el router de cliente mantiene el estado vivo entre navegaciones. En un MPA cada ruta es un documento nuevo y ese estado hay que persistirlo a mano.
• Interactividad densa y acoplada. Si media pantalla reacciona a la otra media —un dashboard con filtros cruzados—, trocearlo en islas aisladas es trabajar contra el modelo.
• Un único árbol de componentes. Contextos, providers y layouts anidados con estado son de serie en Next o Nuxt; entre islas de Astro no existen.
• Tiempo real intenso. Conexiones vivas, colaboración multiusuario, sincronización constante: eso es una aplicación de principio a fin.

En qué se parecen

En muchas cosas convergen, y conviene no exagerar la distancia: todos derivan las rutas de la estructura de carpetas, todos hacen SSG y SSR con adaptadores para el edge, Astro y SvelteKit comparten base en Vite, y tanto los RSC de Next como las islas de Astro persiguen enviar menos JavaScript.

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. Donde de verdad divergen es en tres decisiones que no ves hasta que el proyecto crece: el JavaScript de base (cero en Astro; el runtime del framework en los demás), el router (de documentos frente a de cliente) y el lock-in de librería (ninguno frente a total).

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.

• Elige Astro para blogs, documentación, marketing, landings, portfolios y catálogos de e-commerce: 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: dashboard, editor, estado compartido entre rutas, tiempo real o sesiones largas.
• La zona gris —una tienda con mucho catálogo y 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 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. Si se queda en blanco, es una aplicación.