---
term: 'JAMstack'
seoTitle: 'JAMstack explicado: JavaScript, APIs, Markup — y el backend'
headline: '¿Qué es JAMstack?'
slug: jamstack
category: frontend-web
shortDefinition: 'JAMstack es una arquitectura web que precompila el frontend en markup estático servido desde una CDN, con JavaScript y APIs para lo dinámico.'
relatedTerms:
  - ssr-vs-csr-vs-ssg
  - baas-vs-custom-backend
  - cdn-content-delivery-network
  - auto-generated-database-apis
contrastsWith:
  - ssr-vs-csr-vs-ssg
aboutTerms:
  - 'JavaScript, APIs, Markup'
  - 'Prerenderizado y Desacoplamiento'
  - 'Arquitectura Headless'
faq:
  - question: '¿Qué es JAMstack?'
    answer: 'Una arquitectura web que precompila el frontend en markup estático en el build, lo sirve desde una CDN y usa JavaScript en el navegador llamando APIs para todo lo dinámico — desacoplando el frontend del backend. Es un patrón de arquitectura, no un framework ni un producto.'
  - question: '¿Qué significa JAM?'
    answer: 'JavaScript, APIs y Markup. El JavaScript corre en el navegador para la interactividad; las APIs proveen los datos dinámicos y las operaciones del lado del servidor; el Markup es el HTML estático precompilado servido desde el edge. Los dos principios fundadores debajo de la sigla son el prerenderizado y el desacoplamiento.'
  - question: '¿Cuál es la diferencia entre JAMstack y un stack tradicional?'
    answer: 'Un stack tradicional, como un CMS acoplado a una base de datos, renderiza cada página en un servidor, por solicitud, consultando la base de datos. JAMstack sirve archivos estáticos precompilados desde una CDN y llama APIs solo para las partes dinámicas — sin servidor de origen renderizando la página en cada visita, y sin base de datos expuesta a la web pública.'
  - question: '¿Los sitios JAMstack pueden ser dinámicos?'
    answer: 'Sí — la funcionalidad dinámica llega en runtime, con JavaScript llamando APIs: funciones serverless, un CMS headless, servicios de terceros o un Backend as a Service. La parte "estática" es solo el shell; autenticación, datos, búsqueda y comercio llegan todos por llamadas de API.'
  - question: '¿Cómo manejas autenticación, datos y formularios sin backend?'
    answer: 'Sí tienes un backend — solo que accedido por APIs, en vez de operado por ti. La autenticación pasa por un servicio de identidad o un BaaS que emite tokens; los datos vienen de una API de contenido o de base de datos; los formularios hacen POST a una función serverless o a un servicio de formularios. Toda necesidad "dinámica" mapea a una llamada de API.'
  - question: '¿Cuál es la diferencia entre JAMstack y SSR?'
    answer: 'El timing. SSR renderiza HTML en el servidor por solicitud; JAMstack prerrenderiza en el build y sirve archivos estáticos. Los frameworks modernos los mezclan — rutas estáticas precompiladas, rutas dinámicas renderizadas en el servidor o regeneradas — que es el híbrido hacia el que evolucionó la idea del JAMstack.'
  - question: '¿JAMstack está muerto?'
    answer: 'El término de marketing se apagó — quien lo creó retiró la etiqueta hacia 2023 en favor de "composable" y "arquitectura web moderna". Pero la arquitectura ganó: precompilar lo que se pueda, traer el resto vía APIs y servir desde una CDN es simplemente cómo se construye buena parte de la web hoy, viviendo dentro de CMS headless, frameworks híbridos y plataformas de edge.'
  - question: '¿Cuándo deberías usar JAMstack?'
    answer: 'Brilla en sitios de contenido, marketing, documentación y páginas sensibles al SEO, donde la velocidad y una superficie de ataque pequeña importan, además de vitrinas de e-commerce apoyadas en APIs. Encaja menos en apps muy en tiempo real o personalizadas por solicitud, donde el renderizado en el servidor o en el edge es la mejor herramienta.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'What is Jamstack? — jamstack.org'
    url: 'https://jamstack.org/what-is-jamstack/'
  - name: 'JAMstack — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/JAMstack'
  - name: 'Rendering patterns — patterns.dev'
    url: 'https://www.patterns.dev/'
  - name: 'Is Jamstack Toast? — The New Stack'
    url: 'https://thenewstack.io/is-jamstack-toast-some-developers-say-yes-netlify-says-no/'
cta:
  title: 'El 20% dinámico, resuelto'
  text: 'JAMstack precompila el shell estático; Back4app es la API detrás del JavaScript — autenticación, base de datos y funciones en la nube para la parte dinámica, sin servidor que aprovisionar.'
  linkText: 'Empieza gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-04'
translationKey: jamstack
---

**JAMstack es una arquitectura web que precompila el frontend en markup estático servido desde una CDN, con JavaScript y APIs para lo dinámico.** La sigla — **J**avaScript, **A**PIs, **M**arkup — se apoya en dos principios: *prerenderizado* (el frontend se compila por adelantado en archivos estáticos optimizados) y *desacoplamiento* (frontend y backend solo se hablan por APIs). El reencuadre que este glosario agrega, y que las guías de frontend se saltan: **la A es un backend.** El famoso "sin servidor" del JAMstack no significa sin backend — significa *el servidor de otra persona, accedido por una API*.

## Puntos clave

| Pregunta | Respuesta |
| --- | --- |
| JAM | JavaScript (navegador) · APIs (dinámico) · Markup (estático precompilado) |
| Los dos principios | Prerenderizado + desacoplamiento |
| Entrega | Archivos estáticos desde una [CDN](/glossary/es/cdn/) — sin render de origen por solicitud |
| La "A" | APIs = un backend ([BaaS](/glossary/es/baas-vs-backend-propio/), funciones, servicios headless) |
| "¿Está muerto?" | El término se retiró; la arquitectura ganó y se volvió híbrida |

## El JAM en la práctica

**JavaScript:**

```javascript
// JavaScript — the JAM in practice: static Markup, browser JS, an API for the dynamic
// The page shell was prebuilt at build time and served from a CDN.
// The dynamic 20% — auth, data, comments — is this API call at runtime:
const query = new Parse.Query('Comment');
query.equalTo('postSlug', 'what-is-jamstack');
const comments = await query.find();
render(comments); // "no server" really means: someone else's server, via an API
// The A in JAM = APIs = a backend. A BaaS is that backend, with no server to run.
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// A prebuilt shell, made dynamic by API calls — the JAMstack pattern
final query = QueryBuilder<ParseObject>(ParseObject('Comment'))
  ..whereEqualTo('postSlug', 'what-is-jamstack');
final comments = await query.query();
render(comments.results);
// Static delivery + dynamic-via-API: the backend is a BaaS, not a server
// you provision — auth, data, and functions reached over one API.
```

**Swift:**

```swift
// Swift — Back4app Swift SDK
// A prebuilt shell, made dynamic by API calls — the JAMstack pattern
let comments = try await Comment.query("postSlug" == "what-is-jamstack").find()
render(comments)
// Static delivery + dynamic-via-API: the backend is a BaaS, not a server
// you provision — auth, data, and functions reached over one API.
```

**Kotlin:**

```kotlin
// Kotlin — Back4app Android SDK
// A prebuilt shell, made dynamic by API calls — the JAMstack pattern
val query = ParseQuery.getQuery<ParseObject>("Comment")
query.whereEqualTo("postSlug", "what-is-jamstack")
val comments = query.find()
render(comments)
// Static delivery + dynamic-via-API: the backend is a BaaS, not a server
// you provision — auth, data, and functions reached over one API.
```

El shell de la página se precompiló y se sirvió desde el edge; los comentarios — la parte dinámica — llegan en runtime por una llamada de API. Esa única llamada es la arquitectura entera en miniatura: estático donde se puede, API donde hace falta, y el "servidor" detrás de la API es un servicio que consumes, no uno que operas.

## Stack tradicional vs. JAMstack

```mermaid
flowchart LR
  accTitle: Stack tradicional renderizado en el servidor versus JAMstack
  accDescr: En un stack tradicional, cada solicitud de un visitante llega a un servidor de origen que consulta una base de datos y renderiza HTML por solicitud. En JAMstack, el frontend se precompila en markup estático en el build y se sirve desde una CDN, y el JavaScript del navegador llama APIs desacopladas para los datos dinámicos, de modo que ningún servidor de origen ni base de datos queda expuesto en el camino de la solicitud.
  subgraph T["Tradicional (por solicitud)"]
    U1["Visitante"] --> WS["Servidor de origen<br/>renderiza HTML"] --> DB1[("Base de datos")]
  end
  subgraph J["JAMstack (precompilado + API)"]
    U2["Visitante"] --> CDN["CDN<br/>markup estático precompilado"]
    U2 -->|"JS llama APIs<br/>para datos dinámicos"| API[("APIs desacopladas<br/>BaaS · funciones · CMS")]
  end
```

| | Tradicional (renderizado en el servidor) | JAMstack |
| --- | --- | --- |
| HTML generado | Por solicitud, en el origen | En el [build](/glossary/es/ssr-vs-csr-vs-ssg/), precompilado |
| Servido desde | Un servidor web de origen | El edge de una [CDN](/glossary/es/cdn/) |
| Datos dinámicos | Renderizados inline desde la base | JavaScript llamando APIs |
| Acoplamiento | Frontend y backend fundidos | [Desacoplados](/glossary/es/arquitectura-desacoplada/) vía APIs |
| Superficie de ataque | Origen + base expuestos | Archivos estáticos + una API endurecida |

## De dónde viene realmente lo dinámico

La sección que los resultados de búsqueda evitan porque rompe el hechizo del "serverless". Toda necesidad dinámica de un sitio JAMstack mapea a una llamada de API, y detrás de esa API hay un backend que alguien opera:

- **Autenticación** → un servicio de identidad o [BaaS](/glossary/es/baas-vs-backend-propio/) emitiendo [tokens](/glossary/es/json-web-token-jwt/).
- **Datos** → una [API](/glossary/es/apis-generadas-automaticamente/) de contenido o de base de datos devolviendo JSON.
- **Formularios** → una [función serverless](/glossary/es/cloud-code-funciones-serverless/) o un servicio de formularios.
- **Búsqueda, comentarios, comercio** → APIs de terceros o de backend.

Así que la descripción honesta del JAMstack es *frontend estático + backend desacoplado*, y el backend natural es un **BaaS**: aporta el 20% dinámico — base de datos, autenticación, funciones en la nube, [APIs generadas automáticamente](/glossary/es/apis-generadas-automaticamente/) — sin ningún servidor que aprovisionar. Las páginas de proveedores empujan aquí un *CMS headless*, que resuelve solo contenido; un BaaS resuelve el backend dinámico completo, y por eso la dupla es la respuesta más completa a "¿cómo es dinámico un sitio estático?"

## El dividendo de seguridad

Desacoplar no es solo una historia de rendimiento; es una postura de seguridad. Sin servidor de origen renderizando páginas y sin base de datos en el camino de la solicitud, la web pública ve *archivos estáticos* — que no sufren SQL injection y no ejecutan código de servidor que explotar. La única superficie viva es la frontera de la API — alojada aparte, endurecida de forma independiente y por lo general mucho más estrecha que la de un monolito. La entrada de [arquitectura desacoplada](/glossary/es/arquitectura-desacoplada/) generaliza el beneficio; en JAMstack aparece como un atacante encontrando una CDN llena de HTML plano donde antes estaba el servidor de origen.

## ¿JAMstack está muerto? El veredicto honesto

La pregunta más repetida merece la respuesta directa. La *sigla* se apagó — quien la creó retiró la marca "JAMstack" hacia 2023 en favor de "composable" y "arquitectura web moderna", y la energía de marketing siguió su camino. La *arquitectura* ganó. "Precompila lo que puedas, trae el resto vía APIs, sirve desde una CDN" dejó de ser un movimiento y se volvió un default, absorbido por plataformas headless, meta-frameworks híbridos y renderizado en el edge. Lo que evolucionó fue la rigidez: el estático-en-todo puro dio paso a *mezclar* rutas precompiladas y [renderizadas en el servidor](/glossary/es/ssr-vs-csr-vs-ssg/) página por página. Así que JAMstack no está muerto; es el agua en la que nada la web moderna, sin necesitar ya un nombre.

## Casos de uso comunes

- **Marketing, documentación y blogs** — contenido igual para todos y que cambia en ciclos previsibles: precompila y sirve desde el edge.
- **Vitrinas de e-commerce** — páginas de producto estáticas al frente de una CDN, carrito y checkout vía APIs.
- **Sitios sensibles al SEO** — HTML precompilado que los crawlers leen al instante, sin la penalidad de ejecutar JS.
- **Frontend estático + [BaaS](/glossary/es/baas-vs-backend-propio/)** — el 20% dinámico (autenticación, datos, formularios) sobre un backend gestionado.
- **Lanzamientos de alto tráfico** — la CDN absorbe picos como un servidor de origen no puede.

## ¿Deberías usar JAMstack? Matriz de decisión

| Situación | Inclinación |
| --- | --- |
| Contenido, docs, marketing, SEO primero | JAMstack — su territorio |
| Frontend estático que necesita datos dinámicos | JAMstack + un [BaaS](/glossary/es/baas-vs-backend-propio/) como API |
| Páginas muy personalizadas por solicitud | [Renderizado en el servidor](/glossary/es/ssr-vs-csr-vs-ssg/) o edge |
| App en tiempo real, altamente interactiva | Renderizado en el cliente + [datos en vivo](/glossary/es/live-queries-tiempo-real/) |
| Enorme cantidad de páginas, cambios frecuentes | Híbrido — precompila una parte, renderiza el resto |
| Superficie de ataque pequeña como prioridad | JAMstack — el dividendo de seguridad |

## Limitaciones y trade-offs

- **El tiempo de build crece con el sitio.** Precompilar miles de páginas vuelve lento el deploy; los catálogos grandes o que cambian rápido empujan hacia la regeneración híbrida.
- **Dinámico significa cableado.** Cada funcionalidad interactiva es una integración de API; la simplicidad está del lado de la entrega, no necesariamente del de la construcción.
- **Editar contenido es menos llave en mano.** Los editores no técnicos necesitan un CMS headless o una capa administrativa; no hay un "edita esta página" integrado como en un CMS monolítico.
- **Dependes de APIs que no son tuyas.** Los servicios de terceros en el camino de la solicitud agregan riesgo de disponibilidad y versionado — el desacoplamiento corta por ambos lados.
- **No todo debería ser estático.** La personalización por solicitud y los datos en tiempo real pelean con el modelo de precompilado; la respuesta moderna es mezclar, no forzar.

## JAMstack en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Es precisamente la "A" que un sitio JAMstack necesita: el shell estático se precompila y se sirve desde una CDN, y cada llamada dinámica que hace el JavaScript — [login](/glossary/es/autenticacion-vs-autorizacion/), lecturas y escrituras de datos, envío de formularios, búsqueda — resuelve a una [API](/glossary/es/apis-generadas-automaticamente/) de Back4app, sin servidor de origen que operar y con las [ACL](/glossary/es/listas-de-control-de-acceso-acl/) endureciendo la única superficie viva que la arquitectura expone. La dupla es la conclusión honesta de la historia "serverless" que las pestañas de código esbozan: entrega estática desde el edge, comportamiento dinámico desde un backend gestionado, y el dividendo de seguridad de una web pública que ve archivos planos en vez de tu base de datos.