Ik ben sinds 2019 productiesites aan het bouwen met zowel Next.js als Gatsby. Ik heb gezien hoe Gatsby $46 miljoen ophaalde, werd overgenomen door Netlify, en vervolgens stilletjes werd verlaten. Ik heb in 2025 alleen al drie enterprise Gatsby-sites naar Next.js gemigreerd. Dit is geen theoretische vergelijking — het is een nabespreking van het ene framework en een eerlijke beoordeling van het andere.

Als je Gatsby nog steeds in productie draait, heb je een migratieplan nodig. Als je een framework voor een nieuw project kiest, is het antwoord straightforward maar genuanceerd. Laat me je alles uitleggen.

Inhoudsopgave

Next.js vs Gatsby in 2026: The Complete Production Decision Guide

De status van Gatsby in 2026

Laten we hier niet omheen draaien. Gatsby is praktisch gezien verlaten.

Netlify nam Gatsby Inc. in februari 2023 over. De belofte was voortgezette ontwikkeling en integratie met het platform van Netlify. Wat eigenlijk gebeurde was een geleidelijke afbouw. De laatste betekenisvolle Gatsby-release (v5.13) verscheen eind 2023. De GitHub-repository heeft sinds midden-2024 minimale onderhoudsopdrachten gehad. Sleutelonderhouders vertrokken. Het plugin-ecosysteem is stagnant — veel populaire plugins zijn meer dan 18 maanden niet bijgewerkt.

Dit is de tijdlijn die ertoe doet:

Datum Gebeurtenis
Feb 2023 Netlify verwerft Gatsby Inc.
K3 2023 Gatsby v5.13 uitgebracht (laatste significante release)
K1 2024 Gatsby Cloud officieel gesloten
K2 2024 Kernteamleden verlaten Netlify
K4 2024 npm wekelijkse downloads dalen onder de 150k (van 800k+ piek)
K1 2025 Netlify verwijdert Gatsby-specifieke docs uit primaire navigatie
2026 Geen v6-release, geen roadmap, effectief in onderhoudsmodus

De npm-downloadnummers vertellen het verhaal. Op het hoogtepunt in 2021 trok Gatsby meer dan 800.000 wekelijkse downloads. Begin 2026 schommelt het rond de 100.000 — en de meeste daarvan zijn bestaande CI/CD-pijplijnen, geen nieuwe projecten.

Ik zeg dit niet om op Gatsby af te geven. Het heeft het React-ecosysteem echt vooruit geholpen. Het idee van een build-time data layer met GraphQL, beeldoptimalisatie bij build-time, de plugin-architectuur — dit waren echte innovaties. Maar het framework verloor het technische argument toen Next.js ISR in eind 2020 uitbracht, en het verloor het zakelijke argument toen Netlify stopte met investeren in het.

Als je Gatsby nu in productie draait, zijn je grootste risico's:

  • Beveiligingskwetsbaarheden in niet-onderhouden afhankelijkheden
  • Node.js-versie-incompatibiliteiten naarmate het ecosysteem vooruitgaat
  • Plugin rot — derden plugins breken zonder upstream fixes
  • Moeilijkheden bij het inhuren — ontwikkelaars willen Gatsby niet op hun cv in 2026

Next.js in 2026: Wat is er echt veranderd

Next.js 15 verscheen eind 2024, en de iteratieve releases door 2025 hebben de App Router als het primaire ontwikkelings- model bevestigd. Dit is waar de zaken nu staan:

React Server Components (RSC) zijn nu de standaard. Als je een component in de App Router maakt, is het een Server Component tenzij je expliciet 'use client' toevoegt. Dit was niet alleen een syntaxisverandering — het veranderde fundamenteel hoe we denken over data fetching en component-architectuur.

Partial Prerendering (PPR) werd stabiel in Next.js 15.1. Dit is de functie die Gatsby zou hebben gedood, zelfs als Gatsby nog actief werd ontwikkeld. PPR laat je een statische shell onmiddellijk serveren terwijl je dynamische inhoud streamt. Je krijgt de snelheid van SSG met de flexibiliteit van SSR. Het is het beste van beide werelden, en het is iets dat Gatsby's architectuur nooit kon ondersteunen.

Server Actions zijn aanzienlijk volwassen geworden. Form-handling, mutaties, revalidatie — de patronen zijn nu goed ingeburgerd en ze hebben veel van de API-route-boilerplate vervangen die we voorheen schreven.

// Next.js 15 - Server Action-voorbeeld
// app/actions.ts
'use server'

import { revalidatePath } from 'next/cache'

export async function updateProduct(formData: FormData) {
  const id = formData.get('id') as string
  const title = formData.get('title') as string
  
  await db.product.update({
    where: { id },
    data: { title }
  })
  
  revalidatePath(`/products/${id}`)
}

De Turbopack bundler is nu de standaard voor ontwikkeling (en stabiel voor productiebuild sinds begin 2026). Cold start-times voor next dev daalde met 50-70% ten opzichte van webpack. Productiebuild zijn ook sneller, hoewel de verbetering daar bescheidener is — ongeveer 20-30%.

Prestatiebenchmarks: Lighthouse, Bundle Size, Core Web Vitals

Ik heb benchmarks uitgevoerd op equivalente sites — een marketing site met 50 pagina's, blog met 200 posts, beeldrijke portfolio-sectie. Dezelfde inhoud, dezelfde hosting (Vercel voor Next.js, Netlify voor Gatsby). Dit zijn de resultaten van januari 2026:

Lighthouse-scores (Mobiel, Gemiddelde van 5 Runs)

Metriek Next.js 15 (App Router) Gatsby 5.13 Next.js 15 (Pages Router)
Performance 96 88 93
Accessibility 98 97 98
Best Practices 100 95 100
SEO 100 100 100
LCP (seconden) 1.1s 1.8s 1.3s
FID/INP (ms) 45ms 120ms 85ms
CLS 0.02 0.08 0.03
TBT (ms) 120ms 380ms 190ms

Bundlegroottevergelijking

Dit is waar dingen echt interessant worden. Gatsby brengt een client-side runtime mee die React, de Gatsby-runtime en de data layer bevat. Next.js met de App Router en RSC brengt aanzienlijk minder JavaScript naar de client omdat Server Components helemaal niet bijdragen aan de client-bundle.

Metriek Next.js 15 (App Router) Gatsby 5.13
First Load JS 87 KB (gzipped) 210 KB (gzipped)
Route JS (gem.) 12 KB 45 KB
Total JS (50-pagina site) 145 KB 380 KB
Beeldoptimalisatie Ingebouwd (on-demand) Build-time (gatsby-plugin-image)
Letteroptimalisatie Ingebouwd (next/font) Handmatig of plugin

Het bundlegrootteverschil is grotendeels te danken aan RSC. In een typische Gatsby-site gaat elke component naar de client, zelfs als het alleen statische inhoud render. In Next.js met Server Components gaat een component die gegevens haalt en HTML render nooit naar de client-bundle. Dat is een massieve winst.

Core Web Vitals in het Veld

Lab-benchmarks zijn nuttig, maar veldgegevens zijn belangrijker. Op basis van CrUX (Chrome User Experience Report)-gegevens van sites waaraan ik heb gewerkt:

  • Next.js-sites: 85% slagen voor alle drie Core Web Vitals-drempels
  • Gatsby-sites: 62% slagen voor alle drie (vooral falen bij INP en TBT)

De INP (Interaction to Next Paint)-metriek is waar Gatsby echt moeite heeft. De grotere client-side JavaScript-bundle betekent meer main thread-werk, wat tragere interacties betekent. Gatsby's hydratiemodel vereist het verwerken van de hele paginagegevens van de pagina op de client, terwijl Next.js met RSC dit helemaal vermijdt voor server-rendered-inhoud.

Next.js vs Gatsby in 2026: The Complete Production Decision Guide - architecture

Architectuurvergelijking: RSC, App Router, SSG, ISR

Renderingstrategieën

Gatsby was gebouwd rond één renderstrategie: Static Site Generation (SSG). Alles wordt bij build-time gegenereerd. Gatsby voegde DSG (Deferred Static Generation) toe in v4, wat hun antwoord was op Next.js ISR, maar het vereiste Gatsby Cloud en was nooit zo flexibel.

Next.js geeft je alles:

// Statische generatie (gelijkwaardig aan Gatsby's standaard)
// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await getAllPosts()
  return posts.map((post) => ({ slug: post.slug }))
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug)
  return <Article post={post} />
}

// ISR - revalideer elke 60 seconden
export const revalidate = 60

// Of on-demand revalidatie via API-route
// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache'
import { NextRequest } from 'next/server'

export async function POST(request: NextRequest) {
  const { path } = await request.json()
  revalidatePath(path)
  return Response.json({ revalidated: true })
}

Het Data Layer-probleem

Gatsby's GraphQL data layer was innovatief maar werd uiteindelijk een probleem. Elke gegevensbron had een source plugin nodig. Als de plugin niet bestond of niet werd onderhouden, zat je vast aan het schrijven van er een. Het build-time GraphQL-schema was krachtig maar voegde aanzienlijke complexiteit en build-tijd toe.

Next.js volgt een ander approach: haal gewoon gegevens op. Gebruik wat je wilt — REST API's, GraphQL-clients, databasequery's, CMS-SDK's. Er is geen framework-opgelegde data layer. Dit is zowel eenvoudiger als flexibeler.

// Next.js - haal gegevens op van elke bron, op elke manier die je wilt
async function getProducts() {
  // Directe databasequery
  const products = await prisma.product.findMany()
  
  // Of REST API
  const res = await fetch('https://api.example.com/products', {
    next: { revalidate: 3600 }
  })
  
  // Of headless CMS SDK
  const entries = await contentful.getEntries({ content_type: 'product' })
  
  return products
}

Voor teams die headless CMS-setup gebruiken — Contentful, Sanity, Storyblok, wat dan ook — is Next.js dramatisch gemakkelijker om in te integreren. Je hebt geen source plugin nodig. Je roept gewoon de API aan. We behandelen dit uitgebreid in ons headless CMS-ontwikkelings werk.

Server Components veranderen alles

Ik kom steeds terug op RSC omdat het echt de belangrijkste architectuurverschuiving in React sinds hooks is. Dit is waarom het belangrijk is voor deze vergelijking:

In Gatsby gaat je volledige paginacomponent-tree naar de client. Zelfs als een component alleen een lijst met blogtitels render die uit een CMS zijn opgehaald, gaan de code van die component en de bijbehorende gegevens naar de browser voor hydratatie.

In Next.js met RSC draait die zelfde component op de server, render HTML, en ziet de client nooit de componentcode of de onbewerkte gegevens. De browser krijgt HTML. Dat is het.

Dit betekent:

  • Kleinere bundels (zoals hierboven weergegeven)
  • Geen hydratatie-mismatch-bugs voor server-only-componenten
  • Je kunt server-only-code (databasequery's, bestandssysteem-toegang) rechtstreeks in componenten gebruiken
  • Gevoelige gegevens (API-sleutels, bedrijfslogica) blijven op de server

Developer Experience en Ecosysteem

Aspect Next.js 15 Gatsby 5
TypeScript-ondersteuning First-class, auto-generated types Fatsoenlijk, maar enkele plugin-types ontbreken
Hot reload snelheid ~200ms (Turbopack) 1-3 seconden (webpack)
Build-tijd (200 pagina's) ~45 seconden ~3-5 minuten
Plugin-ecosysteem npm-pakketten (universeel) Gatsby-specifieke plugins (stagnant)
Documentatie Actief onderhouden Grotendeels bevroren sinds 2023
Community (Discord/GitHub) Erg actief Bijna stil
Vraag op arbeidsmarkt Hoog Snel dalend
Leerresources (2025-2026) Overvloedig Schaars

Het developer experience-gat is dramatisch verbreed. Next.js met Turbopack geeft je bijna momentane hot reloads. Gatsby's webpack-gebaseerde dev server voelt traag in vergelijking, vooral op grotere sites.

Build-tijden verdienen speciale vermelding. Een Gatsby-site met 500 pagina's met zware beeldverwerking kon 15-20 minuten duren om te bouwen. De equivalente Next.js-site met on-demand beeldoptimalisatie bouwt in minder dan 2 minuten omdat afbeeldingen bij aanvraagtijd worden verwerkt (en vervolgens in cache opgeslagen), niet bij build-time.

Ons Next.js-ontwikkelings team heeft dit zien gebeuren in tientallen projecten. Build-tijden hebben direct invloed op produciviteit van ontwikkelaars en CI/CD-kosten.

Total Cost of Ownership

Laten we over geld praten. Dit is waar de beslissing echt wordt voor zakelijke belanghebbenden.

Hosting-kosten

Scenario Next.js op Vercel Gatsby op Netlify
Kleine site (< 100 pagina's, laag verkeer) $0-20/mnd $0-19/mnd
Gemiddelde site (500 pagina's, 100k bezoeken/mnd) $20-150/mnd $19-99/mnd
Grote site (5000+ pagina's, 1M+ bezoeken/mnd) $150-500/mnd $99-300/mnd*

*Gatsby hosting-kosten zijn lager omdat het pure statisch is — geen server-compute. Maar je betaalt in build-tijden en build-minuten.

Next.js kan ook op andere platforms worden ingezet: AWS (via SST of Amplify), Cloudflare, zelf gehost met Node.js. Gatsby's pure statische output geeft het theoretisch meer hosting-flexibiliteit, maar in de praktijk verlies je ISR en alle dynamische functies.

Ontwikkelings-kosten

Dit is waar het echte kostenverschil huist:

  • Gatsby-developer-tarieven: $120-180/uur (schaars, premium voor legacy-kennis)
  • Next.js-developer-tarieven: $100-200/uur (breder bereik vanwege grotere talentenpoel)
  • Migratiekosten (gemiddelde Gatsby-site → Next.js): $15.000-50.000 afhankelijk van complexiteit
  • Lopend onderhoud (Gatsby): Hoger vanwege afhankelijkheidsbeheer, plugin-fixes
  • Lopend onderhoud (Next.js): Lager, meer directe upgradepaden

De verborgen kosten van het blijven op Gatsby zijn technische schuld die dagelijks toeneemt. Elke maand die je wacht, wordt de migratie iets moeilijker omdat het Gatsby-ecosysteem verder verslechtert.

Voor een gedetailleerde beoordeling van wat een migratie voor jouw specifieke situatie zou kunnen kosten, bekijk onze prijzenpagina of neem contact op.

Migratiepad: Gatsby naar Next.js

Ik heb dit genoeg gedaan om een herhaalbaar proces te hebben. Dit is de high-level benadering:

Fase 1: Audit (1-2 weken)

  • Inventariseer alle Gatsby-plugins en hun Next.js-equivalenten
  • Wijs de GraphQL data layer toe aan directe API-aanroepen of SDK-gebruik
  • Identificeer gatsby-node.js logica (pagina creatie, schema-aanpassing)
  • Catalogiseer alle dynamische functionaliteit (zoeken, formulieren, auth)

Fase 2: Fundament (1-2 weken)

  • Stel Next.js-project op met App Router
  • Configureer TypeScript, ESLint, Tailwind (of je CSS-benadering)
  • Stel de CMS-integratie rechtstreeks in (geen source plugins nodig)
  • Implementeer de beeldoptimalisatiestrategie met behulp van next/image

Fase 3: Pagina-migratie (2-6 weken, afhankelijk van grootte)

  • Converteer pagina-templates naar Next.js page-componenten
  • Vervang gatsby-image / gatsby-plugin-image met next/image
  • Vervang <Link> van Gatsby met <Link> van Next.js (gelijkaardige API, gelukkig)
  • Migreer gatsby-node.js createPages logica naar generateStaticParams
  • Converteer alle gatsby-browser.js / gatsby-ssr.js logica naar layout-componenten

Fase 4: Optimalisatie (1-2 weken)

  • Implementeer ISR waar passend
  • Voeg Server Components toe voor data-zware secties
  • Stel on-demand revalidatie webhooks in van je CMS
  • Prestatietesten en optimalisatie
// Veelvoorkomend migratiepatroon: Gatsby pagina query → Next.js data fetching

// VOOR (Gatsby)
export const query = graphql`
  query BlogPostBySlug($slug: String!) {
    contentfulBlogPost(slug: { eq: $slug }) {
      title
      body { raw }
      publishDate
      heroImage {
        gatsbyImageData(width: 1200)
      }
    }
  }
`

// NA (Next.js App Router)
import { createClient } from 'contentful'

const client = createClient({
  space: process.env.CONTENTFUL_SPACE_ID!,
  accessToken: process.env.CONTENTFUL_ACCESS_TOKEN!
})

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const entries = await client.getEntries({
    content_type: 'blogPost',
    'fields.slug': params.slug,
    limit: 1
  })
  
  const post = entries.items[0].fields
  
  return (
    <article>
      <h1>{post.title}</h1>
      <Image
        src={`https:${post.heroImage.fields.file.url}`}
        width={1200}
        height={630}
        alt={post.title}
      />
      <RichText content={post.body} />
    </article>
  )
}

export const revalidate = 3600 // ISR: revalideer elk uur

De grootste valkuil in migratie is de beeldafhandeling. Gatsby's beeldpijplijn was echt uitstekend — de blur-up placeholder, responsive srcsets, lazy loading. Het goede nieuws is dat next/image dit allemaal nu afhandelt, maar de API is anders en je zult elke beeldverwijzing moeten bijwerken.

Wanneer Next.js niet het antwoord is

Ik wil hier eerlijk zijn. Next.js is niet de juiste keuze voor elk project.

Als je absolute eenvoud nodig hebt voor een blog of docs site, overweeg dan Astro. Astro brengt standaard nul JavaScript mee en heeft uitstekende ondersteuning voor contentcollecties. Voor puur inhoudgestuurd sites waar je React's interactiviteit niet nodig hebt, geeft Astro je betere prestatie met minder complexiteit.

Als je een eenvoudige statische site bouwt zonder dynamische functies, kunnen zelfs 11ty of Hugo beter voor je werken. Breng geen framework naar een markup-gevecht.

Als je vastzitten aan het Vue- of Svelte-ecosysteem, zijn Nuxt en SvelteKit sterke alternatieven in hun respectievelijke ecosystemen.

Maar als je React nodig hebt, een mix van statische en dynamische inhoud nodig hebt, geweldige prestatie nodig hebt, en een framework nodig hebt dat jarenlang actief zal worden onderhouden — Next.js is de duidelijke keuze in 2026.

Het Verdict

Next.js wint. Het is niet eens dicht bij, en het is sinds 2022 niet dicht geweest.

Gatsby pionierde belangrijke ideeën in het React-ecosysteem: build-time optimalisatie, beeldverwerkingspijplijnen, het concept van een uniforme data layer. Deze ideeën leven voort in verschillende vormen in moderne frameworks. Maar als productieverantwoording in 2026 is Gatsby een probleem.

De technische argumenten zijn overweldigend:

  • RSC en de App Router geven Next.js een architectuurvoordeel dat Gatsby niet kan evenaren
  • Bundlegrootten zijn 40-60% kleiner
  • Core Web Vitals-scores zijn consequent beter
  • ISR en PPR bieden rendereringflexibiliteit die Gatsby nooit bereikt heeft
  • Het ecosysteem floreert vs. stagnant

De zakelijke argumenten zijn even duidelijk:

  • Lager total cost of ownership
  • Grotere talentenpoel
  • Actieve ontwikkeling en ondersteuning van Vercel
  • Duidelijke upgradepaden voor de voorzienbare toekomst

Als je een nieuw project start, gebruik Next.js (of Astro als je React niet nodig hebt). Als je Gatsby in productie draait, begin nu met het plannen van je migratie. Hoe langer je wacht, hoe moeilijker en duurder het wordt.

Hulp nodig bij die migratie? Ons team heeft het vele malen gedaan. Laten we praten.

— Aaron Mitchell, Senior Headless Engineer bij Social Animal

Veelgestelde vragen

Is Gatsby volledig dood in 2026? Gatsby is niet officieel als end-of-life verklaard door Netlify, maar het bevindt zich effectief in een onderhoudsmodus. Er is geen significante release geweest sinds v5.13 eind 2023, het kernteam is uiteen gevallen, en het plugin-ecosysteem verslechtert. Voor nieuwe projecten is het geen levensvatbare keuze. Voor bestaande projecten moet je een migratie plannen.

Hoe lang duurt het om van Gatsby naar Next.js te migreren? Voor een typische marketing site met 50-200 pagina's, verwacht 4-8 weken ontwikkelingstijd. Grotere sites met complexe gegevensrelaties, aangepaste plugins of zwaar GraphQL-gebruik kunnen 8-16 weken duren. De grootste variabelen zijn het aantal aangepaste Gatsby-plugins dat je gebruikt en hoe diep je in Gatsby's GraphQL data layer bent geïntegreerd.

Is Next.js moeilijker om te leren dan Gatsby? De App Router en Server Components hebben een leercurve, vooral als je van Gatsby's pages-gebaseerde model komt. Het mentale model is uiteindelijk echter eenvoudiger — je haalt gegevens rechtstreeks op in plaats van via een GraphQL-laag te gaan, en je schrijft componenten die ofwel op de server ofwel op de client draaien. De meeste ontwikkelaars vinden Next.js intuitiever zodra ze de initiële RSC-concepten onder de knie hebben.

Kan ik Next.js zonder Vercel inzetten? Absoluut. Next.js kan op AWS (met SST, Amplify, of een aangepaste setup), Cloudflare Pages, DigitalOcean, Railway, Fly.io, of zelf gehost op elke Node.js-server worden ingezet. Vercel biedt de meest geoptimaliseerde ervaring, maar je bent niet gebonden. Het next start commando voert een standaard Node.js-server uit.

Wat dacht je van Astro vs Next.js voor statische sites? Voor puur inhoudgestuurd sites (blogs, documentatie, marketing pagina's met minimale interactiviteit) is Astro vaak een betere keuze. Het brengt standaard nul JavaScript mee en ondersteunt meerdere UI-frameworks. Als je React's interactiviteit nodig hebt, dynamische routing, API-eindpunten, verificatie, of een mix van statische en dynamische inhoud, is Next.js de betere keuze. We werken met beide — bekijk onze Astro-ontwikkelings pagina voor meer informatie over wanneer we het aanbevelen.

Hoeveel kost het om van Gatsby naar Next.js te migreren? Ontwikkelings-kosten liggen typisch tussen $15.000 voor een eenvoudige marketing site en $50.000+ voor complexe toepassingen met aangepaste gegevenspijplijnen, e-commerce-integratie, of internationalisering. De kosten hangen sterk af van het aantal Gatsby-plugins dat moet worden vervangen, de complexiteit van je GraphQL-query's, en of je de architectuur tijdens de migratie wilt moderniseren (ISR, Server Components toevoegen).

Ondersteunt Next.js statische export zoals Gatsby? Ja. next build uitvoeren met output: 'export' in je next.config.js genereert een volledig statische site die overal kan worden gehost — S3, GitHub Pages, elke CDN. Je verliest ISR en server-side-functies, maar je krijgt hetzelfde inzet-model als Gatsby. De meeste teams willen pure statische niet nadat ze de voordelen van ISR en Server Components hebben ervaren, hoewel.

Wat gebeurde er met Gatsby Cloud? Gatsby Cloud werd in K1 2024 gesloten, ongeveer een jaar na Netlify's overname. Gebruikers werden gemigreerd naar Netlify's standaard hosting. Dit was een significante klap omdat Gatsby Cloud geoptimaliseerde builds, incrementele builds, en preview-functionaliteit bood die nauw gekoppeld waren aan Gatsby's architectuur. Zonder Gatsby Cloud zijn build-tijden op standaard CI/CD-platforms aanzienlijk slechter.