¿Está muerto Jamstack en 2026? Qué pasó después de que murió el hype
Tu deploy termina y 12,000 páginas estáticas se envían al CDN. Ningún servidor se activa. Ninguna consulta de base de datos se dispara a mitad de la solicitud. Es rápido, versionado, y cuesta $19/mes alojarlo — exactamente la promesa que Netlify te vendió en 2019 cuando acuñaron 'Jamstack'. Pero en 2026, nadie lo llama así anymore. La arquitectura sobrevivió. La marca no. Lo que estás mirando no es muerte — es mutación. Gatsby colapsó en modo mantenimiento. Next.js absorbió la mitad del ecosistema y pivoteó hacia React Server Components. Astro envió islands architecture y llamó a la generación estática 'obvious defaults'. Los patrones en los que confiabas se fragmentaron en server-first rendering, edge compute, e hidratación selectiva. La etiqueta murió porque lo que describía se dividió en cinco filosofías en competencia, cada una afirmando que hace Jamstack mejor al no ser Jamstack en absoluto.
Ahora es 2026, y la conversación ha cambiado dramáticamente. Los servidores Discord de Jamstack están más silenciosos. Gatsby está efectivamente muerto. Netlify despidió una porción significativa de su fuerza laboral. Y sin embargo — y esto es la parte que la gente pierde — las ideas detrás de Jamstack están por todas partes. Solo que ya no llevan la etiqueta.
¿Entonces está muerto Jamstack? La respuesta honesta es complicada, y creo que el matiz importa más que el hot take.
Tabla de contenidos
- Qué significó realmente Jamstack
- La cronología del declive
- Dónde Jamstack ganó (permanentemente)
- Dónde Jamstack perdió
- El auge de Server Components y Hybrid Rendering
- Next.js App Router: ¿El asesino de Jamstack o su evolución?
- Astro y el renacimiento de la generación estática
- La capa Headless CMS: Más fuerte que nunca
- Cómo se ve realmente la arquitectura moderna en 2026
- Preguntas frecuentes
Qué significó realmente Jamstack
Seamos precisos sobre definiciones, porque muchos del discurso "Jamstack está muerto" sufren de gente argumentando sobre cosas diferentes.
El Jamstack original (JavaScript, APIs, Markup) tenía algunos principios centrales:
- Pre-renderizado: Genera HTML en tiempo de compilación, no en tiempo de solicitud
- Desacoplamiento: Separa tu frontend de tu backend/CMS
- CDN-first: Sirve todo desde el edge
- Impulsado por API: Maneja funcionalidad dinámica a través de APIs y funciones serverless
El compromiso filosófico clave era que el tiempo de compilación es mejor que el tiempo de solicitud. Haces el trabajo pesado una sola vez durante el deploy, 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
Aquí está aproximadamente cómo se desenredó la narrativa de Jamstack:
| Año | Evento | Impacto |
|---|---|---|
| 2020 | Gatsby recauda $28M Serie C | Pico del hype de Jamstack |
| 2021 | Next.js introduce ISR (Incremental Static Regeneration) | Difumina la línea entre estático y dinámico |
| 2022 | Se anuncia React Server Components | Cambio de paradigma hacia server rendering |
| 2023 | Next.js App Router se estabiliza, el uso de Gatsby se desploma | Hybrid rendering se vuelve default |
| 2023 | Netlify adquiere Gatsby, luego básicamente lo guarda | Fin simbólico del Jamstack "puro" |
| 2024 | Astro 4.x gana tracción importante, Vercel impulsa PPR | La generación estática vive en nuevas formas |
| 2025 | Next.js 15 se envía con patrones RSC maduros | Server-first se vuelve el default mainstream |
| 2026 | El término "Jamstack" raramente aparece en listados de empleos o RFPs | La marca está muerta, los principios persisten |
La historia de Gatsby es particularmente reveladora. En su apogeo, Gatsby tenía miles de plugins, una comunidad masiva, y adopción real en empresas. Para 2024, sus descargas en npm habían caído más del 80% desde su máximo. La adquisición de Netlify no lo salvó — fue más una acqui-hire que cerró silenciosamente.
Pero culpar al declive de Gatsby en "Jamstack muriendo" pierde el punto. Gatsby declinó porque tenía problemas técnicos genuinos: tiempos de compilación absurdamente largos, una capa de datos enrevesada (GraphQL para todo, quieras o no), y un ecosistema de plugins que se convirtió en una responsabilidad. Next.js se comió el almuerzo de Gatsby no porque la generación estática fuera equivocada, sino porque Next.js lo hizo mejor y ofreció más flexibilidad.
Dónde Jamstack ganó (permanentemente)
Aquí está lo que creo que la gente entiende mal sobre la narrativa "Jamstack está muerto": las ideas centrales ganaron tan completamente que dejamos de notarlas.
La arquitectura desacoplada es el default
La mayor victoria de Jamstack es que los frontends desacoplados ahora son la norma para cualquier proyecto web serio. En 2018, tenías que argumentar por separar tu frontend de WordPress o tu CMS. En 2026, la pregunta no es "¿deberíamos desacoplarnos?" — es "¿cuál headless CMS y cuál framework frontend?"
Este es un cambio arquitectónico permanente. Nadie está volviendo a plantillas PHP monolíticas para nuevos proyectos (el mantenimiento heredado es una historia diferente). El patrón headless — ya sea que lo llames Jamstack o no — ganó.
Lo vemos constantemente en nuestro trabajo de desarrollo de CMS headless. Los clientes ya no preguntan "¿deberíamos ir headless?". Preguntan cuál headless CMS se ajusta a su modelo de contenido.
Entrega CDN-First
Cada framework y plataforma de hosting importante ahora prioriza 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 de Jamstack antes de ser un default de la industria.
Flujos de trabajo basados en Git
La idea de que tu sitio se despliega desde un git push, pasa por CI/CD, y llega a una URL de preview antes de golpear producción? Eso era radical en 2017. Ahora son table stakes. Cada plataforma frontend ofrece esto. Jamstack lo normalizó.
Generación estática como herramienta (no una religión)
SSG no murió. Se convirtió en una herramienta entre muchas. Cada framework importante — Next.js, Astro, Nuxt, SvelteKit — soporta 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 Jamstack perdió
Ser honesto significa también reconocer los fracasos reales.
Los tiempos de compilación fueron un problema real
El sucio secreto de los sitios grandes de Jamstack eran los tiempos de compilación. Trabajé en un proyecto con 40,000 páginas de producto en 2021. ¿Rebuild completo? 45 minutos. Incluso con builds incrementales, cualquier cambio de esquema significaba comenzar de nuevo. Cuando tus editores de contenido tienen que esperar 20 minutos para ver un cambio en el sitio en vivo, perdiste el argumento sobre developer experience.
ISR y revalidación bajo demanda en Next.js fueron respuestas directas a este problema. Reconocieron que pre-renderizar todo en tiempo de compilación no escala pasado cierto punto.
La personalización siempre fue un hack
Los sitios Jamstack son excelentes cuando todos ven el mismo contenido. El momento en que necesitas contenido específico del usuario — estados logueados, recomendaciones personalizadas, pruebas A/B, precios geo-dirigidos — estás luchando contra la arquitectura. La obtención de datos del lado del cliente crea layout shift. El middleware edge agrega complejidad. Terminas construyendo una app server-renderizada con pasos extra.
La "J" en Jamstack se volvió hinchada
Los tamaños de bundles de JavaScript en sitios Jamstack se salieron de control. Los sitios Gatsby rutinariamente enviaban 300-500KB de JavaScript para lo que era esencialmente un blog. El HTML estático era rápido, pero entonces el paso de hidratación bloquearía el hilo principal durante segundos en dispositivos móviles. Esto fue un auto-gol.
La island architecture de Astro y los server components ambos emergieron como reacciones directas a este problema de JavaScript bloat.
La experiencia de preview y edición sufrió
Los editores de contenido acostumbrados a WordPress's live preview tuvieron un tiempo difícil con Jamstack. Cambiarías un título en tu CMS, dispararías un webhook, esperarías a un build, y entonces tal vez verías tu cambio. Herramientas como visual editors y draft modes mejoraron las cosas, pero la experiencia nunca igualó lo que un CMS tradicional ofrecía de la caja.
El auge de Server Components y Hybrid Rendering
React Server Components (RSC) representan el mayor cambio filosófico en arquitectura frontend desde la era SPA. Y son fundamentalmente en desacuerdo con el pensamiento puro de Jamstack.
Aquí está por qué: RSC asume que renderizar en el servidor en tiempo de solicitud es bueno, realmente. En lugar de pre-construir todo, renderizas componentes en el servidor, transmites HTML al cliente, y envías cero JavaScript para componentes que no necesitan interactividad.
Esto invierte el script de Jamstack. En lugar de "construye todo con anticipación y sirve archivos estáticos", es "renderiza bajo demanda pero sé 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 maneja personalización, datos en tiempo real, y contenido dinámico sin ninguno de los workarounds de Jamstack.
// Un server component en Next.js App Router — ningún cliente-side JS enviado
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. Cero KB enviado 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 de Jamstack, donde generarías estáticamente la página del producto, luego obtendríasdo cliente las reseñas, luego hidratarías el botón de carrito, manejando estados de carga para cada uno.
Next.js App Router: ¿El asesino de Jamstack o su evolución?
Yo diría que es ambos. Next.js no mató a Jamstack — lo absorbió.
Next.js 15 soporta cada estrategia de renderizado que podrías querer:
- Generación estática (SSG): Páginas renderizadas en tiempo de compilación
- Server-Side Rendering (SSR): Páginas renderizadas por solicitud
- Incremental Static Regeneration (ISR): Páginas estáticas que se revalidan en un horario
- Partial Prerendering (PPR): Shells estáticas con agujeros dinámicos server-renderizados
- Client-Side Rendering: Para componentes puramente interactivos
PPR es particularmente interesante. Pre-renderiza un shell estático de tu página (el layout, navegación, contenido estático) y deja agujeros para contenido dinámico que se renderiza en el servidor y se transmite en cada solicitud. Es como si Jamstack y SSR tuvieran un bebé.
// Con PPR, las partes estáticas están pre-renderizadas, las dinámicas se transmiten
import { Suspense } from 'react';
export default function DashboardPage() {
return (
<main>
{/* Esto está pre-renderizado en tiempo de compilación */}
<h1>Tu Dashboard</h1>
<Navigation />
{/* Esto se transmite dinámicamente por solicitud */}
<Suspense fallback={<DashboardSkeleton />}>
<PersonalizedContent />
</Suspense>
</main>
);
}
Nuestra práctica de desarrollo Next.js se ha desplazado fuertemente hacia estos patrones híbridos. La mayoría de los proyectos ahora usan una mezcla de renderización estática y dinámica por página o incluso por componente, lo que habría sido herejía en la era pura de Jamstack.
La decisión a nivel framework se ha movido 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 default — y construyó un framework que arregla las peores partes. Su island architecture significa que envías cero JavaScript por default e opt-in a interactividad solo donde la necesitas.
Para sitios pesados en contenido, el enfoque de Astro es difícil de superar:
- Una típica página de blog de Astro envía 0KB de JavaScript a menos que explícitamente agregues componentes interactivos
- Los tiempos de compilación son rápidos porque Astro no empareja un runtime React completo
- Content Collections proporciona una capa de contenido type-safe sin complejidad GraphQL
- Puedes usar componentes React, Vue, Svelte, o HTML plano — elige tu veneno
---
// Este es un componente Astro. Se ejecuta solo 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 island envía JavaScript -->
<SearchWidget client:load />
</body>
</html>
Los server islands de Astro (introducidos a finales de 2024) agregaron la habilidad de tener componentes server-renderizados dinámicos dentro de páginas de otra manera estáticas — esencialmente llegando a un destino similar al PPR de Next.js pero desde la dirección estática-first.
Hemos estado alcanzando por Astro cada vez más en nuestro trabajo de desarrollo Astro para sitios de marketing, documentación, y proyectos impulsados por contenido donde el performance es la prioridad y las necesidades de interactividad son modestas.
| Característica | Next.js (App Router) | Astro 5.x | Jamstack antiguo (Gatsby) |
|---|---|---|---|
| Renderizado default | Server (RSC) | Static (SSG) | Static (SSG) |
| JavaScript enviado | Por componente | Cero por default | Runtime React completo |
| Tiempos de compilación (10k páginas) | ~3-5 min | ~1-2 min | ~15-30 min |
| Contenido dinámico | Nativo (RSC/SSR) | Server islands | Client-side fetch |
| Personalización | Incorporado | Middleware + islands | Hacky en el mejor de los casos |
| Integración CMS | Excelente | Excelente | Plugin-dependiente |
| Curva de aprendizaje | Pronunciada (modelo RSC) | Moderada | Moderada-Alta |
| Mejor para | Apps + contenido hybrid | Sitios content-first | Blogs (históricamente) |
La capa Headless CMS: Más fuerte que nunca
Aquí está la cosa que me hace empujar más fuerte contra la narrativa "Jamstack está muerto": el mercado de headless CMS está prosperando. Si la arquitectura estuviera verdaderamente muerta, su infraestructura de contenido no estaría prosperando.
El mercado de headless CMS fue valorado en aproximadamente $2.1 mil millones en 2024 y se proyecta que alcance $5.5 mil millones para 2030 (varias estimaciones de analistas colocan el CAGR en 20-25%). Los principales jugadores están todos publicando un crecimiento fuerte:
- Contentful continúa dominando headless CMS empresarial, con características mejoradas de composability en 2025
- Sanity ha crecido rápidamente con edición colaborativa en tiempo real y lenguaje de consulta GROQ
- Storyblok se talló un nicho fuerte con su visual editor, resolviendo el problema de preview que plagaba el Jamstack temprano
- Payload CMS (código abierto, auto-alojado) ha ganado tracción seria con desarrolladores que quieren control total
- Hygraph (anteriormente GraphCMS) continúa sirviendo a equipos GraphQL-first
El headless CMS no le importa si tu frontend usa generación estática, server components, o palomas mensajeras. Proporciona contenido estructurado vía APIs. Eso es todo. La estrategia de renderizado es el problema de tu frontend.
Este desacoplamiento es el legado más duradero de Jamstack. La capa de contenido y la capa de presentación siendo separadas no es una tendencia — es un principio arquitectónico que sobrevivió la muerte de la marca.
Cómo se ve realmente la arquitectura moderna en 2026
Así que si no estamos llamándola Jamstack, ¿cómo llamamos a la forma en que la mayoría de los sitios modernos se construyen? He estado usando "headless hybrid" en conversaciones, aunque no me encanta. La industria no se ha establecido en un término, lo cual probablemente está bien. No necesitamos una etiqueta de marketing para buena arquitectura.
Aquí está cómo se ve un proyecto típico en 2026:
Capa de contenido: Un headless CMS (Sanity, Contentful, Payload, Storyblok — dependiendo de necesidades y presupuesto)
Framework frontend: Next.js para cualquier cosa con características de app o interactividad compleja. Astro para sitios content-first. SvelteKit o Nuxt si el equipo tiene esas preferencias.
Estrategia de renderizado: Mixta. Las páginas de marketing se generan estáticamente. Las páginas de producto usan ISR o PPR. Los dashboards de usuario usan server-side rendering. Los widgets interactivos usan client-side rendering. El framework maneja todo esto.
Hosting: Plataformas edge-first. Vercel, Cloudflare Pages, Netlify, o AWS (CloudFront + Lambda@Edge) dependiendo de escala y presupuesto.
Proceso de compilación: Git-based CI/CD con preview deployments. Revalidación disparada por webhook desde el CMS.
Si entrecierras los ojos, esto se ve bastante a Jamstack con más flexibilidad. Y ese es más o menos el punto.
Las decisiones arquitectónicas que ayudamos a los clientes a tomar durante nuestros compromisos de desarrollo de CMS headless reflejan esta realidad híbrida. No hay una estrategia de renderizado talla única. La respuesta correcta depende del volumen de contenido, necesidades de personalización, requerimientos de flujo de trabajo editorial, y presupuesto. Si estás sopesando estas compensaciones para tu propio proyecto, estaremos felices de hablar al respecto.
Preguntas frecuentes
¿Está muerto Jamstack en 2026? La marca está efectivamente muerta — no verás "Jamstack" en muchos listados de empleos o RFPs. Pero los principios arquitectónicos centrales (frontends desacoplados, entrega CDN, contenido impulsado por API, flujos de trabajo basados en git) están más extendidos que nunca. Han sido absorbidos en el desarrollo web mainstream tan completamente que no necesitan una etiqueta separada. Gatsby específicamente está muerto. La filosofía persiste.
¿Qué reemplazó a Jamstack? 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 correcta por página o incluso por componente — estática, server-renderizada, o client-side. El patrón de arquitectura headless (CMS desacoplado + framework frontend + hosting edge) permanece el estándar; solo que no lleva la etiqueta de Jamstack.
¿Es la generación estática de sitios aún relevante en 2026? Absolutamente. SSG sigue siendo la mejor opción para contenido que no cambia frecuentemente y no necesita personalización — blogs, documentación, páginas de marketing, landing pages. Astro se ha convertido en el framework go-to para sitios static-first. Next.js y Nuxt aún soportan SSG como una opción de renderizado entre muchas. Lo que cambió es que SSG ahora es una herramienta que alcanzas 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 se movieron 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 forzada, bundles de JavaScript pesados, y un sistema de plugins complejo — nunca fueron adecuadamente resueltos.
¿Aún debo usar un headless CMS en 2026? Sí, y el mercado de plataformas headless CMS es más fuerte que nunca. Contentful, Sanity, Storyblok, Payload CMS, y otros han madurado significativamente. El desacoplamiento de headless CMS fue el principio de Jamstack más duradero. Te permite elegir tu frontend independientemente, reutilizar contenido entre canales, y evitar lock-in de vendedor a una plataforma monolítica. A menos que estés construyendo un blog personal (donde los archivos markdown están bien), un headless CMS vale la inversión.
¿Cómo cambian los React Server Components la ecuación de Jamstack? RSC cambió fundamentalmente el default 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, envían cero JavaScript al navegador, y pueden acceder a bases de datos y APIs directamente. Esto elimina muchos de los workarounds que Jamstack requería para contenido dinámico — no más obtención de datos client-side, spinners de carga, o layout shift para datos que el servidor podría haber incluido en la respuesta inicial. RSC hizo que el server rendering 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 qué problemas estés resolviendo. Si tu configuración estática actual maneja tus necesidades — tu contenido es mayormente estático, los builds son lo suficientemente rápidos, y no necesitas personalización — no hay razón urgente para migrar. Si estás luchando con tiempos de compilación, agregando cada vez más obtención de datos client-side compleja, o lidiando con flujos de trabajo de preview difíciles, el modelo de renderizado híbrido del App Router probablemente vale el costo de migración. La curva de aprendizaje para RSC y el App Router es real, así que factor eso en tu decisión.
¿Cuál es el mejor framework para un nuevo sitio de contenido en 2026? Para sitios de contenido puro (blogs, docs, marketing), Astro es difícil de superar — cero JavaScript por default, compilaciones rápidas, excelente DX, e integraciones headless CMS excelentes. Para sitios que mezclan contenido con características de aplicación (e-commerce, cuentas de usuario, dashboards), 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 respuesta equivocada entre estos tres; la elección depende de la experiencia de tu equipo y las necesidades específicas de tu proyecto.