¿Está Muerto Jamstack en 2026? Una Evaluación Honesta de lo que Cambió
Llevo construyendo sitios Jamstack desde 2018. Por aquel entonces, la propuesta era irresistible: pre-renderizar todo a HTML estático, servirlo desde una CDN y agregar APIs para lo dinámico. Era rápido, seguro y barato de alojar. Netlify acuñó el término, Gatsby cabalgó la ola del hype y, durante un tiempo, se sentía como el futuro del desarrollo web.
Ahora es 2026, y la conversación ha cambiado drásticamente. Los servidores de Discord de Jamstack están más silenciosos. Gatsby está efectivamente muerto. Netlify despidió a una parte significativa de su plantilla. Y sin embargo — y esta es la parte que la gente pasa por alto — las ideas detrás de Jamstack están por todas partes. Solo que ya no llevan esa etiqueta.
¿Está muerto Jamstack entonces? La respuesta honesta es complicada, y creo que el matiz importa más que la opinión tajante.
Tabla de contenidos
- Qué significaba realmente Jamstack
- La cronología del declive
- Dónde ganó Jamstack (de forma permanente)
- Dónde perdió Jamstack
- El auge de los Server Components y el renderizado híbrido
- Next.js App Router: ¿el asesino de Jamstack o su evolución?
- Astro y el renacimiento de la generación estática
- La capa de CMS headless: más fuerte que nunca
- Cómo es realmente la arquitectura moderna en 2026
- Preguntas frecuentes
Qué significaba realmente Jamstack
Seamos precisos con las definiciones, porque gran parte del discurso de "Jamstack está muerto" sufre de gente argumentando sobre cosas diferentes.
El Jamstack original (JavaScript, APIs, Markup) tenía algunos principios fundamentales:
- Pre-renderizado: Generar HTML en tiempo de compilación, no en tiempo de solicitud
- Desacoplamiento: Separar el frontend del backend/CMS
- CDN primero: Servir todo desde el edge
- Orientado a APIs: Gestionar la funcionalidad dinámica mediante APIs y funciones serverless
El compromiso filosófico clave era que el tiempo de compilación es mejor que el tiempo de solicitud. El trabajo pesado se hace una vez durante el despliegue, y cada visitante obtiene el resultado en caché.
Esto funcionó brillantemente para blogs, sitios de marketing, documentación y páginas de productos de e-commerce. Funcionó terriblemente para cualquier cosa que necesitara personalización, datos en tiempo real o contenido que cambiara cada pocos minutos.
La cronología del declive
Así es más o menos cómo se fue deshilachando la narrativa de Jamstack:
| Año | Evento | Impacto |
|---|---|---|
| 2020 | Gatsby recauda 28 millones de dólares en Serie C | Pico del hype de Jamstack |
| 2021 | Next.js introduce ISR (Regeneración Estática Incremental) | Difumina la línea entre estático y dinámico |
| 2022 | Se anuncian los React Server Components | Cambio de paradigma hacia el renderizado en servidor |
| 2023 | Next.js App Router se estabiliza, el uso de Gatsby cae en picado | El renderizado híbrido se convierte en la opción por defecto |
| 2023 | Netlify adquiere Gatsby y básicamente lo aparca | Fin simbólico del Jamstack "puro" |
| 2024 | Astro 4.x gana gran tracción, Vercel impulsa PPR | La generación estática sobrevive en nuevas formas |
| 2025 | Next.js 15 llega con patrones RSC maduros | El enfoque server-first se convierte en el estándar principal |
| 2026 | El término "Jamstack" rara vez aparece en ofertas de trabajo o solicitudes de propuesta | La marca está muerta, los principios persisten |
La historia de Gatsby es especialmente reveladora. En su apogeo, Gatsby tenía miles de plugins, una comunidad enorme y adopción real en empresas. Para 2024, sus descargas en npm habían caído más de un 80% desde el pico. La adquisición por parte de Netlify no lo salvó — fue más una compra de talento que fue apagándose silenciosamente.
Pero culpar al declive de Gatsby de que "Jamstack está muriendo" es errar el tiro. Gatsby decayó porque tenía problemas técnicos reales: tiempos de compilación absurdamente largos, una capa de datos enrevesada (GraphQL para todo, lo quisieras o no) y un ecosistema de plugins que se convirtió en un lastre. Next.js le comió el terreno a Gatsby no porque la generación estática fuera incorrecta, sino porque Next.js lo hacía mejor y ofrecía más flexibilidad.
Dónde ganó Jamstack (de forma permanente)
Creo que lo que la gente entiende mal sobre la narrativa de "Jamstack está muerto" es lo siguiente: las ideas centrales ganaron tan completamente que dejamos de notarlas.
La arquitectura desacoplada es el estándar
La mayor victoria de Jamstack es que los frontends desacoplados son ahora la norma en cualquier proyecto web serio. En 2018, había que argumentar a favor de separar el frontend de WordPress o del CMS. En 2026, la pregunta ya no es "¿deberíamos desacoplar?" — sino "¿qué CMS headless y qué framework de frontend?"
Este es un cambio arquitectónico permanente. Nadie va a volver a las plantillas PHP monolíticas para proyectos nuevos (el mantenimiento de sistemas heredados es otra historia). El patrón headless — lo llames Jamstack o no — ganó.
Lo vemos constantemente en nuestro trabajo de desarrollo con CMS headless. Los clientes ya no preguntan "¿deberíamos ir headless?". Preguntan qué CMS headless encaja con su modelo de contenido.
Distribución CDN primero
Todos los frameworks y plataformas de alojamiento importantes priorizan ahora la entrega desde el edge. Vercel, Cloudflare, Netlify, AWS — todos asumen que tu contenido debe estar lo más cerca posible del usuario. Este era un principio Jamstack antes de convertirse en un estándar del sector.
Flujos de trabajo basados en Git
¿La idea de que tu sitio se despliega desde un git push, pasa por CI/CD y aterriza en una URL de previsualización antes de llegar a producción? Era radical en 2017. Ahora es lo mínimo esperado. Todas las plataformas frontend ofrecen esto. Jamstack lo normalizó.
La generación estática como herramienta (no como religión)
SSG no murió. Se convirtió en una herramienta más entre muchas. Todos los frameworks principales — Next.js, Astro, Nuxt, SvelteKit — soportan la generación estática. La diferencia es que ahora es una elección por página en lugar de una arquitectura de todo o nada.
Dónde perdió Jamstack
Ser honesto significa reconocer también los fracasos reales.
Los tiempos de compilación fueron un problema real
El secreto vergonzoso de los sitios Jamstack de gran tamaño eran los tiempos de compilación. Trabajé en un proyecto con 40.000 páginas de productos en 2021. ¿Reconstrucción completa? 45 minutos. Incluso con compilaciones incrementales, cualquier cambio de esquema significaba empezar de cero. Cuando los editores de contenido tienen que esperar 20 minutos para ver un cambio en el sitio en vivo, has perdido el argumento sobre la experiencia del desarrollador.
ISR y la revalidación bajo demanda en Next.js fueron respuestas directas a este problema. Reconocían que pre-renderizar todo en tiempo de compilación no escala más allá de cierto punto.
La personalización siempre fue un parche
Los sitios Jamstack son geniales cuando todos ven el mismo contenido. En el momento en que necesitas contenido específico del usuario — estados de sesión, recomendaciones personalizadas, tests A/B, precios según la ubicación geográfica — estás luchando contra la arquitectura. La obtención de datos en el cliente genera desplazamiento del diseño. El middleware en el edge añade complejidad. Acabas construyendo una app renderizada en servidor con pasos adicionales.
La "J" de Jamstack se volvió pesada
El tamaño de los bundles de JavaScript en los sitios Jamstack se descontroló. Los sitios Gatsby enviaban rutinariamente entre 300 y 500 KB de JavaScript para lo que era esencialmente un blog. El HTML estático era rápido, pero luego el paso de hidratación bloqueaba el hilo principal durante segundos en dispositivos móviles. Fue un gol en propia puerta.
La arquitectura de islas de Astro y los Server Components surgieron ambos como reacciones directas a este problema de hinchazón de JavaScript.
La experiencia de previsualización y edición era deficiente
Los editores de contenido acostumbrados a la previsualización en vivo de WordPress lo pasaban mal con Jamstack. Cambiabas un encabezado en el CMS, disparabas un webhook, esperabas la compilación y quizás veías tu cambio. Herramientas como los editores visuales y los modos de borrador mejoraron las cosas, pero la experiencia nunca igualó lo que un CMS tradicional ofrecía de serie.
El auge de los Server Components y el renderizado híbrido
Los React Server Components (RSC) representan el mayor cambio filosófico en arquitectura frontend desde la era de las SPA. Y están fundamentalmente en conflicto con el pensamiento Jamstack puro.
He aquí por qué: RSC asume que renderizar en el servidor en tiempo de solicitud es bueno, en realidad. En lugar de pre-construir todo, renderizas componentes en el servidor, transmites HTML al cliente y envías cero JavaScript para los componentes que no necesitan interactividad.
Esto invierte el guión de Jamstack. En lugar de "construir todo por adelantado y servir archivos estáticos", es "renderizar bajo demanda pero siendo inteligente sobre qué necesita JavaScript".
Los resultados hablan por sí solos. Una aplicación RSC bien construida puede igualar o superar el Time to First Byte de un sitio estático, mientras gestiona la personalización, los datos en tiempo real y el contenido dinámico sin ninguno de los trucos de Jamstack.
// Un componente de servidor en Next.js App Router — no se envía JS al cliente
async function ProductPage({ params }: { params: { slug: string } }) {
const product = await getProduct(params.slug);
const reviews = await getReviews(product.id);
return (
<main>
<h1>{product.name}</h1>
<p>{product.description}</p>
{/* Este componente se ejecuta en el servidor. Se envían cero KB al navegador. */}
<ReviewsList reviews={reviews} />
{/* Solo este componente interactivo envía JavaScript */}
<AddToCartButton productId={product.id} />
</main>
);
}
El modelo mental es más limpio que el equivalente Jamstack, donde habrías generado estáticamente la página del producto, luego obtenido las reseñas en el cliente, luego hidratado el botón del carrito, gestionando estados de carga para cada uno.
Next.js App Router: ¿el asesino de Jamstack o su evolución?
Yo diría que es ambas cosas. Next.js no mató Jamstack — lo absorbió.
Next.js 15 en 2025 soporta todas las estrategias de renderizado que puedas desear:
- Generación estática (SSG): Páginas renderizadas en tiempo de compilación
- Renderizado en servidor (SSR): Páginas renderizadas por solicitud
- Regeneración estática incremental (ISR): Páginas estáticas que se revalidan según un calendario
- Pre-renderizado parcial (PPR): Esqueletos estáticos con huecos renderizados en servidor de forma dinámica
- Renderizado en el cliente: Para componentes puramente interactivos
PPR es particularmente interesante. Pre-renderiza un esqueleto estático de tu página (el diseño, la navegación, el contenido estático) y deja huecos para el contenido dinámico que se renderiza en servidor y se transmite en cada solicitud. Es como si Jamstack y SSR tuvieran un hijo.
// Con PPR, las partes estáticas se pre-renderizan, las partes dinámicas se transmiten
import { Suspense } from 'react';
export default function DashboardPage() {
return (
<main>
{/* Esto se pre-renderiza en tiempo de compilación */}
<h1>Tu panel de control</h1>
<Navigation />
{/* Esto se transmite dinámicamente por solicitud */}
<Suspense fallback={<DashboardSkeleton />}>
<PersonalizedContent />
</Suspense>
</main>
);
}
Nuestra práctica de desarrollo con Next.js ha girado fuertemente hacia estos patrones híbridos. La mayoría de los proyectos ahora utilizan una mezcla de renderizado estático y dinámico por componente, lo que habría sido una herejía en la era Jamstack puro.
La decisión a nivel de framework ha pasado de "¿estático o dinámico?" a "¿qué estrategia de renderizado necesita cada pieza de contenido?". Esa es una conversación más madura.
Astro y el renacimiento de la generación estática
Si quieres argumentar que Jamstack está vivo, Astro es tu mejor evidencia.
Astro tomó las mejores partes de Jamstack — generación estática, JavaScript mínimo, rápido por defecto — y construyó un framework que arregla las peores partes. Su arquitectura de islas significa que no envías nada de JavaScript por defecto y optas por la interactividad solo donde la necesitas.
Para sitios con mucho contenido, el enfoque de Astro es difícil de superar:
- Una página de blog típica de Astro envía 0 KB de JavaScript a menos que agregues componentes interactivos explícitamente
- Los tiempos de compilación son rápidos porque Astro no empaqueta un runtime completo de React
- Las Colecciones de Contenido proporcionan una capa de contenido con tipos seguros sin la complejidad de GraphQL
- Puedes usar componentes de React, Vue, Svelte o HTML puro — elige el que prefieras
---
// Este es un componente Astro. Solo se ejecuta en tiempo de compilación.
const posts = await getCollection('blog');
---
<html>
<body>
<h1>Blog</h1>
{posts.map(post => (
<article>
<h2><a href={`/blog/${post.slug}`}>{post.data.title}</a></h2>
<p>{post.data.excerpt}</p>
</article>
))}
<!-- Solo esta isla envía JavaScript -->
<SearchWidget client:load />
</body>
</html>
Las islas de servidor de Astro (introducidas a finales de 2024) añadieron la capacidad de tener componentes dinámicos renderizados en servidor dentro de páginas que de otro modo serían estáticas — llegando esencialmente a un destino similar al PPR de Next.js pero desde la dirección estática primero.
En nuestro trabajo de desarrollo con Astro lo hemos estado usando cada vez más para sitios de marketing, documentación y proyectos orientados al contenido donde el rendimiento es la prioridad y las necesidades de interactividad son modestas.
| Característica | Next.js (App Router) | Astro 5.x | Jamstack antiguo (Gatsby) |
|---|---|---|---|
| Renderizado por defecto | Servidor (RSC) | Estático (SSG) | Estático (SSG) |
| JavaScript enviado | Por componente | Cero por defecto | Runtime completo de React |
| Tiempos de compilación (10k páginas) | ~3-5 min | ~1-2 min | ~15-30 min |
| Contenido dinámico | Nativo (RSC/SSR) | Islas de servidor | Obtención en el cliente |
| Personalización | Integrada | Middleware + islas | Chapucero en el mejor caso |
| Integración con CMS | Excelente | Excelente | Dependiente de plugins |
| Curva de aprendizaje | Pronunciada (modelo RSC) | Moderada | Moderada-Alta |
| Ideal para | Apps + híbrido de contenido | Sitios orientados al contenido | Blogs (históricamente) |
La capa de CMS headless: más fuerte que nunca
Esto es lo que hace que me oponga con más fuerza a la narrativa de "Jamstack está muerto": el mercado de CMS headless está en auge. Si la arquitectura estuviera verdaderamente muerta, su infraestructura de contenido no estaría prosperando.
El mercado de CMS headless fue valorado en aproximadamente 2.100 millones de dólares en 2024 y se proyecta que alcance los 5.500 millones de dólares para 2030 (varias estimaciones de analistas sitúan la CAGR entre el 20 y el 25%). Los principales actores registran un fuerte crecimiento:
- Contentful continúa dominando el CMS headless empresarial, con características mejoradas de composabilidad en 2025
- Sanity ha crecido rápidamente con su edición colaborativa en tiempo real y su lenguaje de consulta GROQ
- Storyblok se ganó un sólido nicho con su editor visual, resolviendo el problema de previsualización que plagaba el Jamstack inicial
- Payload CMS (código abierto, autoalojado) ha ganado una tracción seria entre los desarrolladores que quieren control total
- Hygraph (antes GraphCMS) continúa sirviendo a equipos que priorizan GraphQL
El CMS headless no se preocupa de si tu frontend usa generación estática, componentes de servidor o palomas mensajeras. Proporciona contenido estructurado mediante APIs. Eso es todo. La estrategia de renderizado es problema de tu frontend.
Este desacoplamiento es el legado más duradero de Jamstack. Que la capa de contenido y la capa de presentación estén separadas no es una tendencia — es un principio arquitectónico que sobrevivió a la muerte de la marca.
Cómo es realmente la arquitectura moderna en 2026
Entonces, si ya no lo llamamos Jamstack, ¿cómo llamamos a la manera en que se construye la mayoría de los sitios modernos? He estado usando "headless híbrido" en las conversaciones, aunque no me entusiasma. El sector no se ha asentado en un término, lo cual probablemente está bien. No necesitamos una etiqueta de marketing para una buena arquitectura.
Así es como se ve un proyecto típico en 2026:
Capa de contenido: Un CMS headless (Sanity, Contentful, Payload, Storyblok — según las necesidades y el presupuesto)
Framework frontend: Next.js para cualquier cosa con características de aplicación o interactividad compleja. Astro para sitios orientados al contenido. SvelteKit o Nuxt si el equipo tiene esas preferencias.
Estrategia de renderizado: Mixta. Las páginas de marketing se generan de forma estática. Las páginas de producto usan ISR o PPR. Los paneles de usuario usan renderizado en servidor. Los widgets interactivos usan renderizado en el cliente. El framework gestiona todo esto.
Alojamiento: Plataformas edge-first. Vercel, Cloudflare Pages, Netlify o AWS (CloudFront + Lambda@Edge) según la escala y el presupuesto.
Proceso de compilación: CI/CD basado en Git con despliegues de previsualización. Revalidación disparada por webhooks desde el CMS.
Si te fijas bien, esto se parece mucho a Jamstack con más flexibilidad. Y ese es más o menos el punto.
Las decisiones arquitectónicas que ayudamos a tomar a los clientes durante nuestros proyectos de desarrollo con CMS headless reflejan esta realidad híbrida. No hay una estrategia de renderizado que sirva para todo. La respuesta correcta depende del volumen de contenido, las necesidades de personalización, los requisitos del flujo de trabajo editorial y el presupuesto. Si estás sopesando estos compromisos para tu propio proyecto, estaremos encantados de hablarlo contigo.
Preguntas frecuentes
¿Está muerto Jamstack en 2026? La marca está efectivamente muerta — ya no verás "Jamstack" en muchas ofertas de trabajo o solicitudes de propuesta. Pero los principios arquitectónicos fundamentales (frontends desacoplados, distribución por CDN, contenido orientado a APIs, flujos de trabajo basados en Git) son más generalizados que nunca. Han sido absorbidos por el desarrollo web convencional tan a fondo que ya no necesitan una etiqueta separada. Gatsby específicamente está muerto. La filosofía persiste.
¿Qué reemplazó a Jamstack? Los frameworks de renderizado híbrido como Next.js (con App Router y RSC), Astro, Nuxt 3 y SvelteKit han reemplazado el enfoque de generación estática pura. Estos frameworks te permiten elegir la estrategia de renderizado adecuada por página o incluso por componente — estático, renderizado en servidor o en el cliente. El patrón de arquitectura headless (CMS desacoplado + framework frontend + alojamiento en el edge) sigue siendo el estándar; simplemente ya no lleva la etiqueta de Jamstack.
¿Sigue siendo relevante la generación de sitios estáticos en 2026? Absolutamente. SSG sigue siendo la mejor opción para contenido que no cambia con frecuencia y no necesita personalización — blogs, documentación, páginas de marketing, páginas de destino. Astro se ha convertido en el framework de referencia para sitios que priorizan lo estático. Next.js y Nuxt siguen soportando SSG como una opción de renderizado entre muchas. Lo que cambió es que SSG es ahora una herramienta a la que recurres cuando es apropiado, no una filosofía arquitectónica completa.
¿Qué le pasó a Gatsby? Gatsby fue adquirido por Netlify a principios de 2023 y ha sido efectivamente descontinuado. Su última actualización significativa fue en 2023. El ecosistema colapsó cuando los mantenedores de plugins siguieron adelante y la comunidad migró a Next.js, Astro y otros frameworks. Los problemas centrales de Gatsby — tiempos de compilación excesivos, capa de datos GraphQL obligatoria, bundles de JavaScript pesados y un sistema de plugins complejo — nunca fueron resueltos adecuadamente.
¿Debería seguir usando un CMS headless en 2026? Sí, y el mercado de plataformas de CMS headless es más sólido que nunca. Contentful, Sanity, Storyblok, Payload CMS y otros han madurado significativamente. El desacoplamiento del CMS headless fue el principio más duradero de Jamstack. Te permite elegir tu frontend de forma independiente, reutilizar contenido en distintos canales y evitar la dependencia de un proveedor con una plataforma monolítica. A menos que estés construyendo un blog personal (donde los archivos markdown son perfectamente válidos), un CMS headless vale la inversión.
¿Cómo cambian los React Server Components la ecuación de Jamstack? RSC cambió fundamentalmente el comportamiento por defecto de "pre-renderizar en tiempo de compilación" a "renderizar en el servidor en tiempo de solicitud". Los Server Components se ejecutan en el servidor, no envían JavaScript al navegador y pueden acceder a bases de datos y APIs directamente. Esto elimina muchos de los trucos que Jamstack requería para el contenido dinámico — se acabaron la obtención de datos en el cliente, los indicadores de carga y el desplazamiento del diseño para datos que el servidor podría haber incluido en la respuesta inicial. RSC hizo que el renderizado en servidor se sintiera tan ergonómico como la generación estática.
¿Vale la pena migrar a Next.js App Router desde una configuración Jamstack? Depende de los problemas que estés resolviendo. Si tu configuración estática actual satisface tus necesidades — tu contenido es mayoritariamente estático, las compilaciones son lo suficientemente rápidas y no necesitas personalización — no hay razón urgente para migrar. Si estás luchando contra los tiempos de compilación, añadiendo una obtención de datos en el cliente cada vez más compleja o teniendo dificultades con los flujos de trabajo de previsualización, el modelo de renderizado híbrido del App Router probablemente valga el coste de la migración. La curva de aprendizaje para RSC y el App Router es real, así que tenlo en cuenta en tu decisión.
¿Cuál es el mejor framework para un nuevo sitio de contenido en 2026? Para sitios de contenido puro (blogs, documentación, marketing), Astro es difícil de superar — cero JavaScript por defecto, compilaciones rápidas, excelente experiencia de desarrollo e integraciones geniales con CMS headless. Para sitios que combinan contenido con funcionalidades de aplicación (e-commerce, cuentas de usuario, paneles de control), Next.js te da la mayor flexibilidad con sus opciones de renderizado híbrido. Si tu equipo prefiere Vue, Nuxt 3 ofrece capacidades similares a Next.js. No hay una respuesta incorrecta entre estos tres; la elección depende de la experiencia de tu equipo y las necesidades específicas de tu proyecto.