El dilema de elegir framework
Cada vez que arrancamos un proyecto nuevo, la pregunta aparece: ¿Next.js o Astro? Después de usar ambos en producción durante años, la respuesta siempre es depende.
No es una respuesta vaga. Es la respuesta correcta.
Cuándo elegimos Astro
Astro brilla en sitios donde el contenido es rey:
- Sitios corporativos — HTML estático, carga instantánea, SEO perfecto out of the box.
- Blogs y documentación — Content Collections hace que manejar Markdown sea trivial.
- Landing pages — Cero JavaScript en el cliente por defecto. Lighthouse 100 sin esfuerzo.
La arquitectura de “islands” permite que solo los componentes interactivos carguen JavaScript. El resto es HTML puro.
---
// Solo este componente envía JS al cliente
import ContactForm from '../components/ContactForm.tsx';
---
<h1>Contenido estático, sin JS</h1>
<ContactForm client:visible />Cuándo elegimos Next.js
Next.js es la elección cuando la app necesita interactividad pesada:
- Dashboards — Estado compartido entre componentes, actualizaciones en tiempo real.
- Apps con autenticación — Middleware, sesiones, protección de rutas.
- E-commerce complejo — Server components + cliente interactivo en la misma app.
El App Router con React Server Components cambió el juego. Renderizado en servidor sin sacrificar interactividad.
Nuestra regla de decisión
| Criterio | Astro | Next.js |
|---|---|---|
| Contenido estático | ✅ | ⚠️ |
| App interactiva | ⚠️ | ✅ |
| SEO crítico | ✅ | ✅ |
| Bundle size mínimo | ✅ | ⚠️ |
| Ecosistema React | ⚠️ | ✅ |
Si el sitio es mayormente contenido con algo de interactividad → Astro. Si es una aplicación web completa → Next.js.
La trampa de elegir por popularidad
El error más común que vemos es elegir Next.js para un sitio corporativo de 5 páginas. Terminas con un bundle de 200KB para mostrar texto e imágenes.
Lo mismo aplica en reversa: no uses Astro para un dashboard con 50 componentes interactivos. No es su fuerte.
Elige por el problema, no por el hype.
