Next.js, Astro o Remix: cómo elegir el stack en 2026

"¿Qué framework debería usar?" es la pregunta favorita en Twitter de desarrolladores y la peor pregunta de los founders. La respuesta corta es depende, pero depende de qué exactamente es donde está el valor. En esta nota, los criterios concretos para decidir entre los tres frameworks dominantes en 2026.

💰 La decisión de stack afecta el presupuesto. Ver la guía completa de pricing en Costa Rica — el stack equivocado puede sumar 30–50 % al costo del proyecto.

El estado del arte (mayo 2026)

Tres frameworks lideran el ecosistema React:

1. Next.js 16 — Vercel. App Router maduro, React Server Components estable, Turbopack default. Sigue siendo el más usado por amplio margen.
2. Astro 5 — Comunidad. Diseñado para sitios de contenido. Envía 0 KB de JS por defecto. Soporta Islands con cualquier framework (React, Vue, Svelte).
3. Remix / React Router v7 — Shopify. El merge de Remix y React Router resolvió la confusión de marca. Modelo loaders + actions, excelente con Cloudflare Workers.

Las "guerras de frameworks" terminaron hace dos años. Hoy cada uno gana en un contexto distinto. La pregunta es cuál es tu contexto.

Cuándo Next.js es la elección obvia

Si construyes una de estas cosas, elige Next.js sin pensarlo mucho:

• App con autenticación: dashboards, paneles admin, área de usuario.
• E-commerce: catálogo, carrito, checkout, panel del vendedor.
• SaaS típico: registro, billing, multi-tenant, integraciones.
• App que mezcla SSG + SSR + ISR + API: Next.js soporta los cuatro patterns en un mismo proyecto. Migrar entre ellos es trivial.

Por qué gana

• App Router + RSC te dan un modelo mental coherente: server-first, client opt-in. Eso reduce el JS enviado al cliente y mejora performance sin trabajo manual.
• Documentación + ecosistema son los mejores. Una pregunta en Stack Overflow tiene 5 respuestas; cualquier librería del ecosistema React tiene integración Next.js.
• Deploy en Vercel es magia. git push y está en producción con SSL, CDN, ISR, image optimization. No es "deploy fácil", es "deploy invisible".

Trade-offs honestos

• Costo de hosting sube rápido en proyectos con mucho SSR (USD 100+/mes para tráfico medio en Vercel). Self-hosting con Docker es opción, pero pierdes parte de la magia.
• App Router todavía cambia. RSC + Server Actions son estables pero el ecosistema de librerías a veces se atrasa con las versiones.
• JS bundle base ~70 KB es alto para sitios que son 90% contenido.

Cuándo elegir Astro y no Next.js

Si tu sitio es principalmente contenido estático (blog, marketing, docs, landing), Astro gana a Next.js de manera medible:

• 0 KB de JS por defecto. Astro genera HTML puro. El JS solo se envía donde lo pides explícitamente con un Island (un componente interactivo).
• Lighthouse 95–100 en Performance es la norma, no la excepción.
• Build times 2–3× más rápidos que Next.js para el mismo volumen de páginas.
• Markdown / MDX first-class. La integración con contenido en archivos es nativa.

Casos concretos donde lo elegiríamos:

• Sitio de marketing de una startup (5–20 páginas).
• Blog técnico con 100+ posts.
• Documentación de un producto SaaS.
• Sitio de un consultor (1 persona, contenido + portfolio).

Cuando NO Astro

• Si necesitas auth de usuarios y zonas privadas → Next.js.
• Si tu app cambia state en tiempo real (chat, colaboración) → Next.js o Remix.
• Si tu equipo no conoce React/Vue/Svelte y prefiere Next.js de seguir → válido.

Cuándo Remix / React Router v7

El sweet spot de Remix son aplicaciones con muchas mutations: formularios largos, ediciones inline, herramientas internas tipo CRUD intensivo.

Su modelo de loaders + actions es radicalmente más limpio que useEffect + fetch + reducer para este tipo de UI:

// Remix / RR v7 — todo en el server
export async function loader({ params }) {
  return await getInvoice(params.id)
}

export async function action({ request, params }) {
  const form = await request.formData()
  await updateInvoice(params.id, form)
  return redirect(`/invoices/${params.id}`)
}

Vs el equivalente en Next.js que mezcla Server Actions con state local. Para CRUD pesado, Remix es más feliz.

Donde Remix gana específicamente

• Back-office / admin panels con muchos formularios.
• Apps en Cloudflare Workers — la integración es la mejor del mercado.
• Equipos que vienen de PHP / Rails y quieren el modelo "form submit → server processes → redirect" sin tanta cosa intermedia.

Trade-offs

• Menos ecosistema que Next.js. Cada librería tiene 1 forma de integrarse en Next.js y 3 maneras dudosas en Remix.
• No tiene ISR del mismo nivel que Next.js. Para sitios con SSG pesado, Next.js es mejor.

La tabla de decisión rápida

Lo que no debería decidir el stack

• "Está de moda en Twitter" — ya no estamos en 2021.
• "Mi amigo lo usa" — su contexto no es el tuyo.
• "El framework X es 2× más rápido en X benchmark" — los benchmarks de framework rara vez se traducen a tu app real.
• "Quiero aprender Y" — válido para side projects, pésimo para proyecto de cliente.

Cómo lo hacemos en Sirius

Antes de iniciar cualquier proyecto, le hacemos al cliente 5 preguntas:

1. ¿Cuál es el tipo dominante de contenido? (estático / dinámico / mixto)
2. ¿Hay autenticación de usuarios?
3. ¿Volumen esperado de tráfico al mes?
4. ¿Quién va a mantenerlo en 2 años? (nosotros, equipo del cliente, sin definir)
5. ¿Hay alguna restricción de hosting? (auto-hospedaje, Cloudflare, AWS)

Con esas 5 respuestas, el stack se elige solo el 90% de las veces. El 10% restante es discusión genuina de trade-offs.

Si estás por iniciar un proyecto y dudas entre frameworks, conversémoslo. No cobramos esa conversación — y la respuesta puede ahorrarte 4 semanas de re-trabajo cuando descubras a mitad de proyecto que escogiste el stack equivocado.