Ich baue Jamstack-Sites seit 2018. Damals war das Versprechen unwiderstehlich: Alles in statisches HTML vorrendern, von einem CDN ausliefern und APIs für dynamische Inhalte hinzufügen. Es war schnell, sicher und kostengünstig zu hosten. Netlify prägte den Begriff, Gatsby ritt die Hype-Welle, und für eine Weile fühlte sich das wie die Zukunft der Webentwicklung an.

Jetzt ist es 2026, und das Gespräch hat sich dramatisch verschoben. Die Jamstack-Discord-Server sind leiser geworden. Gatsby ist praktisch tot. Netlify hat einen großen Teil seiner Belegschaft entlassen. Und doch — und das ist der Teil, den die Leute übersehen — die Ideen hinter Jamstack sind überall. Sie tragen nur nicht mehr dieses Label.

Also ist Jamstack tot? Die ehrliche Antwort ist kompliziert, und ich denke, die Nuancierung ist wichtiger als der heiße Take.

Inhaltsverzeichnis

Ist Jamstack 2026 tot? Eine ehrliche Bewertung dessen, was sich geändert hat

Was Jamstack wirklich bedeutete

Seien wir präzise bei den Definitionen, denn ein großer Teil des "Jamstack ist tot"-Diskurses leidet darunter, dass Menschen über verschiedene Dinge argumentieren.

Das ursprüngliche Jamstack (JavaScript, APIs, Markup) hatte einige Kernprinzipien:

  1. Pre-rendering: HTML zur Build-Zeit generieren, nicht zur Request-Zeit
  2. Entkopplung: Dein Frontend von deinem Backend/CMS trennen
  3. CDN-first: Alles vom Edge ausliefern
  4. API-getrieben: Dynamische Funktionalität über APIs und serverlose Funktionen handhaben

Das Schlüsselprinzip war, dass Build-Zeit besser ist als Request-Zeit. Du leist die schwere Arbeit einmal während der Bereitstellung, und jeder Besucher erhält das gecachte Ergebnis.

Das funktionierte brillant für Blogs, Marketing-Sites, Dokumentation und E-Commerce-Produktseiten. Es funktionierte schrecklich für alles, das Personalisierung, Echtzeitdaten oder Inhalte brauchte, die sich alle paar Minuten änderten.

Der Zeitstrahl des Niedergangs

Hier ist ungefähr, wie die Jamstack-Erzählung auseinanderfiel:

Jahr Ereignis Auswirkung
2020 Gatsby sammelt $28M Serie C Peak Jamstack Hype
2021 Next.js führt ISR (Incremental Static Regeneration) ein Verwischt die Grenze zwischen statisch und dynamisch
2022 React Server Components angekündigt Paradigmenwechsel zu Server Rendering
2023 Next.js App Router wird stabil, Gatsby-Nutzung sinkt Hybrid Rendering wird Standard
2023 Netlify übernimmt Gatsby, verstaut es dann praktisch Symbolisches Ende des "reinen" Jamstack
2024 Astro 4.x gewinnt großen Zulauf, Vercel präsentiert PPR Statische Generierung lebt in neuen Formen weiter
2025 Next.js 15 wird mit reifen RSC-Patterns ausgeliefert Server-first wird zum Mainstream Default
2026 Der Begriff "Jamstack" erscheint selten in Stellenangeboten oder RFPs Die Marke ist tot, die Prinzipien bleiben erhalten

Die Gatsby-Geschichte ist besonders aussagekräftig. Auf ihrem Höhepunkt hatte Gatsby Tausende von Plugins, eine riesige Community und echte Enterprise-Adoption. Bis 2024 waren seine npm-Downloads um über 80% vom Peak gefallen. Netlifies Übernahme rettete es nicht — es war eher ein Akquisition-Hire, der ruhig auslief.

Aber die Gatzby-Rezession auf "Jamstack stirbt" zurückzuführen, übersieht den Punkt. Gatsby sank, weil es echte technische Probleme hatte: absurd lange Build-Zeiten, eine verwickelte Datenschicht (GraphQL für alles, ob du es wolltest oder nicht), und ein Plugin-Ökosystem, das zur Belastung wurde. Next.js aß Gatsbys Mittagessen nicht, weil statische Generierung falsch war, sondern weil Next.js es besser machte und mehr Flexibilität bot.

Wo Jamstack gewonnen hat (Dauerhaft)

Hier ist, was ich denke, dass Menschen über die "Jamstack ist tot"-Erzählung falsch verstehen: Die Kernideen haben so komplett gewonnen, dass wir aufgehört haben, sie zu bemerken.

Entkoppelte Architektur ist der Standard

Der größte Jamstack-Sieg ist, dass entkoppelte Frontends jetzt die Norm sind für jedes ernsthafte Webprojekt. Im Jahr 2018 musste man argumentieren, um dein Frontend von WordPress oder deinem CMS zu trennen. Im Jahr 2026 ist die Frage nicht "sollten wir entkoppeln?" — es ist "welches Headless CMS und welches Frontend-Framework?"

Das ist ein dauerhafter Architekturwechsel. Niemand geht zu monolithischen PHP-Templates für neue Projekte zurück (Legacy-Wartung ist eine andere Geschichte). Das Headless-Muster — ob du es Jamstack nennst oder nicht — hat gewonnen.

Wir sehen das ständig in unserer Headless CMS Entwicklungsarbeit. Kunden fragen nicht mehr "sollten wir headless gehen?" Sie fragen, welches Headless CMS zu ihrem Content-Modell passt.

CDN-First Auslieferung

Jede große Framework und Hosting-Plattform priorisiert jetzt Edge-Auslieferung. Vercel, Cloudflare, Netlify, AWS — sie alle gehen davon aus, dass dein Inhalt so nah wie möglich beim Benutzer sein sollte. Das war ein Jamstack-Prinzip, bevor es ein Industrie-Standard war.

Git-basierte Workflows

Die Idee, dass deine Site von einem git push bereitgestellt wird, ein CI/CD durchläuft und auf einer Preview-URL landet, bevor sie zur Produktion geht? Das war 2017 radikal. Es ist jetzt Standard. Jede Frontend-Plattform bietet das. Jamstack normalisierte es.

Statische Generierung als ein Werkzeug (keine Religion)

SSG ist nicht gestorben. Es wurde ein Werkzeug unter vielen. Jedes große Framework — Next.js, Astro, Nuxt, SvelteKit — unterstützt statische Generierung. Der Unterschied ist, dass es jetzt eine Pro-Seite-Wahl ist, anstatt einer All-oder-Nichts-Architektur.

Ist Jamstack 2026 tot? Eine ehrliche Bewertung dessen, was sich geändert hat - Architektur

Wo Jamstack verloren hat

Ehrlich zu sein bedeutet, auch die echten Fehler anzuerkennen.

Build-Zeiten waren ein echtes Problem

Das schmutzige Geheimnis großer Jamstack-Sites waren Build-Zeiten. Ich arbeitete 2021 an einem Projekt mit 40.000 Produktseiten. Vollständiger Rebuild? 45 Minuten. Selbst mit inkrementellen Builds bedeutete jede Schema-Änderung einen Neustart. Wenn deine Content-Editoren 20 Minuten warten müssen, um eine Änderung auf der Live-Site zu sehen, hast du das Argument über Developer Experience verloren.

ISR und On-Demand-Revalidation in Next.js waren direkte Reaktionen auf dieses Problem. Sie erkannten an, dass Pre-Rendering alles zur Build-Zeit nicht über einen bestimmten Punkt hinaus skaliert.

Personalisierung war immer ein Hack

Jamstack-Sites sind großartig, wenn jeder den gleichen Inhalt sieht. Der Moment, in dem du benutzerspezifische Inhalte brauchst — angemeldete Zustände, personalisierte Empfehlungen, A/B-Tests, geo-gezielte Preise — kämpfst du gegen die Architektur. Client-seitiges Abrufen erzeugt Layout-Verschiebung. Edge-Middleware fügt Komplexität hinzu. Du endigst damit, eine Server-gerenderte App mit zusätzlichen Schritten zu bauen.

Das "J" in Jamstack wurde aufgebläht

Die JavaScript-Bundle-Größen auf Jamstack-Sites gerieten außer Kontrolle. Gatsby-Sites lieferten routinemäßig 300-500KB JavaScript für das, was im Wesentlichen ein Blog war. Das statische HTML war schnell, aber dann würde der Hydrations-Schritt den Main Thread für Sekunden auf Mobilgeräten einfrieren. Das war ein Eigentor.

Astros Island-Architektur und Server-Komponenten entstanden beide als direkte Reaktionen auf dieses JavaScript-Bloat-Problem.

Preview- und Bearbeitungserlebnis litten

Content-Editoren, die an WordPress' Live-Preview gewöhnt waren, hatten es schwer mit Jamstack. Du änderst eine Überschrift in deinem CMS, löst einen Webhook aus, wartest auf einen Build, und siehst dann vielleicht deine Änderung. Tools wie visuelle Editoren und Draft-Modi verbesserten die Dinge, aber das Erlebnis stimmte nie mit dem überein, was ein traditionelles CMS von vornherein bot.

Der Aufstieg von Server Components und Hybrid Rendering

React Server Components (RSC) stellen den größten philosophischen Wendepunkt in der Frontend-Architektur seit der SPA-Ära dar. Und sie sind grundlegend im Widerspruch zum reinen Jamstack-Denken.

Hier ist warum: RSC setzt voraus, dass Rendering auf dem Server zur Request-Zeit gut ist, tatsächlich. Anstatt alles voraus zu bauen, renderst du Komponenten auf dem Server, streamst HTML zum Client, und sendest null JavaScript für Komponenten, die keine Interaktivität brauchen.

Das flippt das Jamstack-Drehbuch um. Anstatt "alles im Voraus bauen und statische Dateien servieren," ist es "auf Anfrage rendern, aber sei smart darüber, was JavaScript braucht."

Die Ergebnisse sprechen für sich. Eine gut gebaute RSC-Anwendung kann die Time to First Byte einer statischen Site erreichen oder schlagen, während sie Personalisierung, Echtzeitdaten und dynamische Inhalte ohne irgendwelche Jamstack-Workarounds handhaben kann.

// Eine Server-Komponente in Next.js App Router — kein Client-seitiges JS wird gesendet
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>
      {/* Diese Komponente läuft auf dem Server. Zero KB an den Browser gesendet. */}
      <ReviewsList reviews={reviews} />
      {/* Nur diese interaktive Komponente versendet JavaScript */}
      <AddToCartButton productId={product.id} />
    </main>
  );
}

Das mentale Modell ist sauberer als das Jamstack-Äquivalent, wo du die Produktseite statisch generieren würdest, dann Client-seitig Rezensionen abrufen würdest, dann den Cart-Button hydratisieren würdest, Ladezustände für jeden handhaben würdest.

Next.js App Router: Jamstack-Killer oder seine Weiterentwicklung?

Ich würde argumentieren, dass es beides ist. Next.js tötete Jamstack nicht — es absorbierte es.

Next.js 15 im Jahr 2025 unterstützt jede Rendering-Strategie, die du dir vorstellen kannst:

  • Statische Generierung (SSG): Seiten, die zur Build-Zeit gerendert werden
  • Server-Side Rendering (SSR): Seiten, die pro Request gerendert werden
  • Incremental Static Regeneration (ISR): Statische Seiten, die auf einem Schedule neu validieren
  • Partial Prerendering (PPR): Statische Shells mit server-gerendertem dynamischem Inhalt
  • Client-Side Rendering: Für rein interaktive Komponenten

PPR ist besonders interessant. Es pre-rendert eine statische Shell deiner Seite (Layout, Navigation, statischer Inhalt) und lässt Lücken für dynamische Inhalte, die pro Request server-gerendert und gestreamt werden. Es ist wie wenn Jamstack und SSR ein Baby bekamen.

// Mit PPR sind die statischen Teile pre-gerendert, dynamische Teile werden gestreamt
import { Suspense } from 'react';

export default function DashboardPage() {
  return (
    <main>
      {/* Das ist zur Build-Zeit pre-gerendert */}
      <h1>Dein Dashboard</h1>
      <Navigation />
      
      {/* Das wird pro-Request dynamisch gestreamt */}
      <Suspense fallback={<DashboardSkeleton />}>
        <PersonalizedContent />
      </Suspense>
    </main>
  );
}

Unsere Next.js Entwicklungspraxis hat sich stark zu diesen hybriden Mustern verschoben. Die meisten Projekte verwenden jetzt eine Mischung aus statischem und dynamischem Rendering auf einer Pro-Komponenten-Basis, was in der reinen Jamstack-Ära Häresie gewesen wäre.

Die Framework-Level-Entscheidung hat sich von "statisch oder dynamisch" zu "welche Rendering-Strategie braucht jedes Stück Inhalt?" verschoben. Das ist ein reiferes Gespräch.

Astro und die Renaissance der statischen Generierung

Wenn du argumentieren möchtest, dass Jamstack am Leben ist, ist Astro dein bestes Beweis.

Astro nahm die besten Teile von Jamstack — statische Generierung, minimales JavaScript, schnell per Default — und baute ein Framework, das die schlimmsten Teile behebt. Seine Island-Architektur bedeutet, dass du standardmäßig null JavaScript versendest und dich nur dort für Interaktivität entscheidest, wo du sie brauchst.

Für inhaltsreiche Sites ist Astros Ansatz schwer zu schlagen:

  • Eine typische Astro-Blog-Seite versendet 0KB JavaScript, es sei denn, du fügst explizit interaktive Komponenten hinzu
  • Build-Zeiten sind schnell, weil Astro keinen ganzen React-Runtime bundeln muss
  • Content Collections bieten eine typsichere Inhaltsschicht ohne GraphQL-Komplexität
  • Du kannst React, Vue, Svelte oder reine HTML-Komponenten verwenden — wähle dein Gift
---
// Das ist eine Astro-Komponente. Sie läuft nur zur Build-Zeit.
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>
    ))}
    
    <!-- Nur diese Insel versendet JavaScript -->
    <SearchWidget client:load />
  </body>
</html>

Astros Server Islands (eingeführt im späten 2024) fügten die Fähigkeit hinzu, dynamisch server-gerenderte Komponenten in ansonsten statischen Seiten zu haben — im Wesentlichen an einem ähnlichen Ziel wie Next.js PPR angekommen, aber aus der statisch-first-Richtung.

Wir greifen zunehmend zu Astro in unserer Astro Entwicklungsarbeit für Marketing-Sites, Dokumentation und inhaltsgesteuerte Projekte, wo Performance Priorität ist und Interaktivitätsbedarf bescheiden sind.

Feature Next.js (App Router) Astro 5.x Altes Jamstack (Gatsby)
Standard Rendering Server (RSC) Statisch (SSG) Statisch (SSG)
Versendetes JavaScript Pro-Komponente Null per Default Ganzer React Runtime
Build-Zeiten (10k Seiten) ~3-5 Min ~1-2 Min ~15-30 Min
Dynamischer Inhalt Nativ (RSC/SSR) Server Islands Client-seitiges Abrufen
Personalisierung Eingebaut Middleware + Islands Im besten Fall hacky
CMS Integration Exzellent Exzellent Plugin-abhängig
Lernkurve Steil (RSC-Modell) Moderat Moderat-Hoch
Best für Apps + Inhalts-Hybrid Inhalts-first Sites Blogs (historisch)

Die Headless CMS Schicht: Stärker denn je

Hier ist die Sache, die mich am meisten dazu treibt, gegen die "Jamstack ist tot"-Erzählung zu argumentieren: Der Headless CMS Markt booming. Wenn die Architektur wirklich tot wäre, würde ihre Content-Infrastruktur nicht florieren.

Der Headless CMS Markt wurde 2024 auf ungefähr $2,1 Milliarden bewertet und soll bis 2030 $5,5 Milliarden erreichen (verschiedene Analyst-Schätzungen platzieren die CAGR bei 20-25%). Große Spieler posten alle starkes Wachstum:

  • Contentful dominiert weiterhin Enterprise Headless CMS, mit verbesserten Composability-Features in 2025
  • Sanity ist schnell gewachsen mit seiner echtzeit-kollaborativen Bearbeitung und GROQ-Abfragesprache
  • Storyblok hatte sich eine starke Nische mit seinem visuellen Editor gehauen, lösend das Preview-Problem, das frühes Jamstack plagte
  • Payload CMS (Open Source, selbst gehostet) hat ernsthaft Dynamik mit Entwicklern gewonnen, die volle Kontrolle wollen
  • Hygraph (ehemals GraphCMS) bedient weiterhin GraphQL-first-Teams

Das Headless CMS interessiert sich nicht, ob dein Frontend statische Generierung, Server-Komponenten oder Brieftauben verwendet. Es stellt strukturierte Inhalte über APIs bereit. Das ist alles. Die Rendering-Strategie ist das Problem deines Frontends.

Diese Entkopplung ist das haltbarste Jamstack-Erbe. Die Content-Schicht und die Präsentationsschicht getrennt zu haben ist kein Trend — es ist ein Architektur-Prinzip, das den Tod der Marke überlebt hat.

Wie moderne Architektur tatsächlich in 2026 aussieht

Also wenn wir es nicht Jamstack nennen, wie nennen wir die Art, auf die die meisten modernen Sites gebaut sind? Ich habe in Gesprächen "Headless Hybrid" verwendet, obwohl ich es nicht liebe. Die Industrie hat sich auf einen Begriff nicht geeinigt, was wahrscheinlich gut ist. Wir brauchen kein Marketing-Label für gute Architektur.

Hier ist, wie ein typisches Projekt in 2026 aussieht:

Content-Schicht: Ein Headless CMS (Sanity, Contentful, Payload, Storyblok — je nach Bedarf und Budget)

Frontend-Framework: Next.js für alles mit App-ähnlichen Features oder komplexer Interaktivität. Astro für inhalts-first Sites. SvelteKit oder Nuxt, wenn das Team diese Vorlieben hat.

Rendering-Strategie: Gemischt. Marketing-Seiten sind statisch generiert. Produktseiten verwenden ISR oder PPR. User-Dashboards verwenden Server-Side Rendering. Interaktive Widgets verwenden Client-Side Rendering. Das Framework handhabt das alles.

Hosting: Edge-first Plattformen. Vercel, Cloudflare Pages, Netlify, oder AWS (CloudFront + Lambda@Edge) je nach Skalierung und Budget.

Build-Prozess: Git-basiertes CI/CD mit Preview-Bereitstellungen. Webhook-getriggerte Revalidation vom CMS.

Wenn du die Augen zusammenkneifst, sieht das viel wie Jamstack mit mehr Flexibilität aus. Und das ist irgendwie der Punkt.

Die Architektur-Entscheidungen, die wir Kunden bei unseren Headless CMS Entwicklungs-Engagements helfen, widerspiegeln diese hybride Realität. Es gibt keine One-Size-Fits-All Rendering-Strategie. Die richtige Antwort hängt von Content-Volumen, Personalisierungsbedarf, Bearbeitungs-Workflow-Anforderungen und Budget ab. Wenn du diese Trade-Offs für dein eigenes Projekt abwägst, sprechen wir gerne darüber.

FAQ

Ist Jamstack 2026 tot?

Die Marke ist praktisch tot — du wirst "Jamstack" in vielen Stellenangeboten oder RFPs nicht sehen. Aber die Kern-Architektur-Prinzipien (entkoppelte Frontends, CDN-Auslieferung, API-getriebene Inhalte, Git-basierte Workflows) sind verbreiteter denn je. Sie wurden so gründlich in die Standard-Webentwicklung absorbiert, dass sie kein separates Label brauchen. Gatsby spezifisch ist tot. Die Philosophie bleibt.

Was ersetzte Jamstack?

Hybrid-Rendering-Frameworks wie Next.js (mit App Router und RSC), Astro, Nuxt 3 und SvelteKit haben den reinen statischen Generierungs-Ansatz ersetzt. Diese Frameworks lassen dich die richtige Rendering-Strategie pro Seite oder sogar pro Komponente wählen — statisch, server-gerendert oder client-seitig. Das Headless-Architektur-Muster (entkoppeltes CMS + Frontend-Framework + Edge-Hosting) bleibt der Standard; es trägt nur nicht das Jamstack-Label.

Ist statische Site-Generierung 2026 noch relevant?

Absolut. SSG ist immer noch die beste Wahl für Inhalte, die sich nicht häufig ändern und keine Personalisierung brauchen — Blogs, Dokumentation, Marketing-Seiten, Landing-Pages. Astro ist das Go-to-Framework für statisch-first Sites geworden. Next.js und Nuxt unterstützen immer noch SSG als eine Rendering-Option unter vielen. Was sich geändert hat, ist, dass SSG jetzt ein Werkzeug ist, das du erreichst, wenn angemessen, nicht eine ganze Architektur-Philosophie.

Was passierte mit Gatsby?

Gatsby wurde Anfang 2023 von Netlify übernommen und ist praktisch eingestellt worden. Sein letztes bedeutungsvolles Update war 2023. Das Ökosystem kollabierte, als Plugin-Betreuer weiterzogen und die Community zu Next.js, Astro und anderen Frameworks migrierten. Gatsbys Kernprobleme — excessive Build-Zeiten, erzwungene GraphQL-Datenschicht, schwere JavaScript-Bundles und ein komplexes Plugin-System — wurden nie angemessen gelöst.

Sollte ich 2026 immer noch ein Headless CMS verwenden?

Ja, und der Markt für Headless CMS Plattformen ist stärker denn je. Contentful, Sanity, Storyblok, Payload CMS und andere sind alle erheblich gereift. Headless CMS Entkopplung war das haltbarste Jamstack-Prinzip. Es lässt dich dein Frontend unabhängig wählen, Inhalte über Kanäle hinweg wiederverwenden und Vendor Lock-in zu einer monolithischen Plattform vermeiden. Es sei denn, du baust ein persönliches Blog (wo Markdown-Dateien in Ordnung sind), ist ein Headless CMS die Investition wert.

Wie ändern React Server Components die Jamstack-Gleichung?

RSC verschob den Default grundlegend von "pre-render zur Build-Zeit" zu "render auf dem Server zur Request-Zeit." Server-Komponenten laufen auf dem Server, versenden null JavaScript an den Browser und können Datenbanken und APIs direkt zugreifen. Das eliminiert viele der Workarounds, die Jamstack für dynamische Inhalte brauchte — kein Client-seitiges Abrufen mehr, keine Ladekreisel oder Layout-Verschiebung für Daten, die der Server in die erste Antwort hätte einbeziehen können. RSC machte Server-Rendering so ergonomisch wie statische Generierung.

Lohnt es sich, vom Next.js App Router aus einem Jamstack-Setup zu migrieren?

Es kommt darauf an, welche Probleme du löst. Wenn dein aktuelles statisches Setup deine Bedürfnisse handhabt — dein Inhalt ist größtenteils statisch, Builds sind schnell genug und du brauchst keine Personalisierung — gibt es keinen dringenden Grund zu migrieren. Wenn du gegen Build-Zeiten kämpfst, zunehmend komplexes Client-seitiges Datenabrufen hinzufügst oder mit Preview-Workflows zu kämpfen hast, ist das hybrid-Rendering-Modell des App Router wahrscheinlich die Migrations-Kosten wert. Die Lernkurve für RSC und den App Router ist real, also rechne das in deine Entscheidung ein.

Was ist das beste Framework für eine neue Content-Website in 2026?

Für reine Content-Sites (Blogs, Docs, Marketing) ist Astro schwer zu schlagen — null JavaScript per Default, schnelle Builds, exzellente DX und großartige Headless CMS Integrationen. Für Sites, die Inhalt mit Anwendungsmerkmalen mischen (E-Commerce, Benutzerkonten, Dashboards), gibt dir Next.js die meiste Flexibilität mit seinen Hybrid-Rendering-Optionen. Wenn dein Team Vue bevorzugt, bietet Nuxt 3 ähnliche Fähigkeiten wie Next.js. Es gibt keine falsche Antwort unter diesen dreien; die Wahl hängt von der Expertise deines Teams und den spezifischen Bedürfnissen deines Projekts ab.