Next.js voegt routing, rendering en serverfuncties toe aan React
Next.js is een React-framework voor het bouwen van full-stack webapplicaties. React biedt het componentmodel voor gebruikersinterfaces; Next.js voegt routing, rendering, conventies voor gegevenstoegang, servermogelijkheden, compilatie, bundeling, caching en productiegerichte hulpmiddelen toe.
Het primaire onderwerp is het framework, niet het domein. nextjs.org is de officiële website waar bezoekers onderhouden documentatie, handleidingen, communitylinks en informatie over het project kunnen vinden.
Next.js is vooral relevant wanneer een team met React wil bouwen en meer wil ondersteunen dan alleen een browserinterface. Eén project kan vooraf gerenderde pagina's, antwoorden tijdens een verzoek, gegevenstoegang aan de serverzijde, API-achtige eindpunten en interactieve componenten die in de browser worden uitgevoerd bevatten.
Wat Next.js toevoegt aan React
React helpt ontwikkelaars interfaces als componenten te beschrijven, maar schrijft geen volledige applicatiearchitectuur voor. Next.js biedt conventies om bestanden aan routes te koppelen, te bepalen waar code wordt uitgevoerd, gegevens te laden, antwoorden te produceren en een applicatie voor implementatie voor te bereiden.
De waarde ervan is daarom breder dan server-side rendering. Een Next.js-applicatie kan verschillende rendering- en leveringsmethoden gebruiken, soms binnen hetzelfde project. Het framework coördineert die methoden rond React in plaats van elke route tot één model te dwingen.
Een nuttige samenvatting van deze verdeling is:
- React definieert componenten, state, props en de samenstelling van interfaces.
- Next.js definieert routes, layouts, renderingkeuzes, serveringangen en buildgedrag.
- De applicatie definieert haar gegevensregels, clientgrenzen, cachebeleid en implementatievereisten.
- De hostingomgeving bepaalt welke runtimefuncties beschikbaar zijn en hoe ze werken.
Deze scheiding is belangrijk bij het vergelijken van Next.js met een React-clientapplicatie, een generator voor statische sites of een ander webframework. Het framework biedt uiteenlopende mogelijkheden, maar een project profiteert alleen van de mogelijkheden die het goed gebruikt.
Server- en Client Components
In de App Router zijn layouts en pagina's standaard Server Components. Server Components worden uitgevoerd in een serveromgeving en kunnen gegevenswerk aan de serverzijde verrichten zonder hun componentimplementatie naar de browser te sturen.
Client Components worden gebruikt wanneer een deel van de interface browserstate, eventhandlers, effecten of uitsluitend in de browser beschikbare API's nodig heeft. Ontwikkelaars markeren een clientgrens met de instructie use client, waarna componenten onder die grens deel worden van de client-side modulegrafiek.
| Vraag | Server Component | Client Component |
|---|---|---|
| Waar wordt de componentlogica uitgevoerd? | In de renderingomgeving van de server | In de browser nadat deze in de clientbundel is opgenomen |
| Kan het browserstate of klikhandlers gebruiken? | Nee | Ja |
| Kan het rechtstreeks uitsluitend in de browser beschikbare API's gebruiken? | Nee | Ja |
| Wordt de componentcode naar de browser gestuurd? | Niet als Client Component-code | Ja |
| Typische rol | Content op basis van gegevens, layouts en samenstelling aan de serverzijde | Formulieren, menu's, editors, filters en andere interactieve bedieningselementen |
Een route hoeft niet uitsluitend voor één type te kiezen. Een Server Component kan content renderen en geselecteerde Client Components samenstellen voor de interactieve delen van de pagina. Zo kunnen teams browser-JavaScript rond specifieke behoeften plaatsen in plaats van de hele route als een clientapplicatie te behandelen.
De grens vereist nog steeds zorgvuldigheid. Als een grote substructuur van componenten achter use client wordt geplaatst, kan er meer JavaScript naar de browser worden gestuurd, terwijl het opsplitsen van elk klein bedieningselement in een afzonderlijke grens de code moeilijker te begrijpen kan maken. Representatieve pagina's moeten worden gemeten in plaats van uitsluitend op basis van het frameworklabel te worden beoordeeld.
Server Components staan ook los van de leveringsstrategie van een route. Een Server Component kan bijdragen aan vooraf gerenderde uitvoer of deelnemen aan dynamische rendering. Een component als server-side beschrijven, geeft op zichzelf niet aan of de route tijdens een build wordt gegenereerd, later wordt vernieuwd of voor elk verzoek wordt geproduceerd.
App Router en Pages Router
Next.js documenteert momenteel twee routingsystemen. De App Router is het nieuwere systeem en bevat React-functies zoals Server Components. De Pages Router is het oudere systeem en wordt nog steeds ondersteund.
| Onderdeel | App Router | Pages Router |
|---|---|---|
| Belangrijkste routestructuur | De map app |
De map pages |
| Standaard componentmodel | Layouts en pagina's zijn Server Components | Gebruikt het eerdere paginamodel van Next.js |
| Gedeelde UI | Geneste layouts zijn een centrale conventie | Wordt doorgaans samengesteld via applicatie- en paginapatronen |
| Beste uitgangspunt | Nieuw werk dat de huidige architectuur overneemt | Bestaande applicaties of afhankelijkheden die rond Pages Router-API's zijn gebouwd |
Een migratie omvat meer dan het hernoemen van mappen. Code voor de App Router introduceert een server-first componentmodel en andere patronen voor layouts, gegevenstoegang, laadstatussen en routegedrag. Teams moeten deze conceptuele veranderingen identificeren voordat ze een volwassen applicatie omzetten.
Nieuwe projecten moeten doorgaans eerst de documentatie van de App Router bestuderen, omdat die het huidige model van het framework uitlegt. Bestaande Pages Router-applicaties moeten een migratie beoordelen aan de hand van werkelijke voordelen, afhankelijkheden, testinspanning en onderhoudskosten, in plaats van voortdurende ondersteuning als een tekortkoming te beschouwen.
Documentatie en voorbeelden kunnen slechts op één router zijn gericht. Voordat ontwikkelaars een implementatie kopiëren, moeten ze nagaan welke router deze gebruikt en of de genoemde API's op hun project van toepassing zijn.
Rendering, caching en revalidatie
Next.js rendert niet elke pagina op dezelfde manier. Een route kan worden voorbereid voordat een bezoeker arriveert, worden gegenereerd met verzoekspecifieke informatie, in de cache worden opgeslagen of volgens een revalidatiebeleid worden vernieuwd.
| Behoefte van de route | Waarschijnlijke leveringsaanpak | Te verifiëren vraag |
|---|---|---|
| Invoer is vooraf bekend | Vooraf gerenderde uitvoer | Welke gebeurtenis moet ervoor zorgen dat de uitvoer verandert? |
| Uitvoer is afhankelijk van cookies, headers of verzoekgegevens | Dynamische rendering | Kan een deel van het werk nog steeds veilig worden gecachet? |
| Content verandert volgens een gecontroleerd schema | Gecachete uitvoer met revalidatie | Hoe verouderd mag het antwoord worden? |
| Er is geen server-only functie vereist | Statische export kan geschikt zijn | Zijn alle routes en assets compatibel met de beperkingen van export? |
Caching is geen enkele schakelaar die los van gegevenstoegang kan worden begrepen. Teams moeten weten welke bewerkingen worden gecachet, welke routes dynamisch worden en hoe invalidatie of revalidatie plaatsvindt. Die regels moeten met realistische contentwijzigingen worden getest.
Dit is vooral belangrijk voor geverifieerde pagina's, prijzen, voorraad, dashboards en andere informatie met expliciete actualiteitsvereisten. Het aanbieden van gecachete uitvoer kan waardevol zijn, maar alleen wanneer de correctheidsregels van de applicatie dit toestaan.
Prestaties en zichtbaarheid in zoekmachines mogen niet alleen uit het renderinglabel worden afgeleid. Vooraf renderen kan de hoeveelheid werk tijdens een verzoek verminderen en serverrendering kan zinvolle oorspronkelijke HTML leveren, maar de werkelijke resultaten hangen af van de paginastructuur, assets, gegevenslatentie, browser-JavaScript, caching en het implementatiegedrag.
Statische export en runtimevereisten
Next.js kan een statische export genereren wanneer het project niet afhankelijk is van server-only frameworkfuncties. De resulterende HTML, CSS, JavaScript en assets kunnen worden aangeboden door infrastructuur die gewone statische bestanden ondersteunt.
Statische uitvoer kan nog steeds Client Components bevatten. Statische levering beschrijft hoe het gebouwde resultaat wordt gehost; het betekent niet dat elke interface niet-interactief moet zijn. Code aan de browserzijde kan nog steeds state, events en ander clientgedrag bieden.
Controleer voordat je voor statische export kiest of het project geen behoefte heeft aan:
- Antwoorden die worden gegenereerd uit verzoekspecifieke servergegevens.
- Routegedrag dat afhankelijk is van een actieve Next.js-runtime.
- Niet-ondersteunde functies voor afbeeldingen, routing of servers.
- Actualiteitsregels waaraan niet kan worden voldaan door opnieuw te bouwen of een ander ondersteund updateproces.
- Servereindpunten die naast de applicatie moeten worden uitgevoerd.
Wanneer deze mogelijkheden vereist zijn, heeft de applicatie een compatibele runtime nodig. Hiervoor is implementatie op Vercel niet vereist: de officiële implementatiehandleiding documenteert zelfhosting en platformadapters. De ondersteuning verschilt per platform, dus de compatibiliteit moet worden gecontroleerd aan de hand van de specifieke functies die worden gebruikt.
Route Handlers en server-side eindpunten
In de App Router laten Route Handlers een applicatie HTTP-verzoekhandlers definiëren aan de hand van standaardconcepten voor verzoeken en antwoorden. Ze zijn nuttig voor eindpunten die bij de applicatie horen, waaronder formulierverwerking, webhooks, gegevensantwoorden of callbacks voor integraties.
Een Route Handler is niet automatisch de juiste plek voor elk backendsysteem. Teams moeten nog steeds bepalen hoe authenticatie, autorisatie, validatie, snelheidsbeperkingen, duurzaam werk en foutafhandeling worden beheerd. Langdurige of onafhankelijk geschaalde diensten kunnen beter van de webapplicatie worden gescheiden.
Een praktische beoordeling stelt de volgende vragen:
- Heeft het eindpunt toegang tot applicatiecode of gedeelde typen nodig?
- Vereist het geheimen tijdens het verzoek of server-only afhankelijkheden?
- Kan de beoogde implementatie de handler uitvoeren zoals gedocumenteerd?
- Welk cachegedrag is correct voor elke HTTP-methode en elk antwoord?
- Zou een afzonderlijke dienst duidelijker eigenaarschap of betere schaalbaarheid bieden?
Route Handlers maken full-stack samenstelling gemakkelijk, maar gemak neemt de normale verantwoordelijkheden voor API-ontwerp en beveiliging niet weg.
Waar Next.js een praktische keuze is
Next.js is een sterke kandidaat voor teams die al vertrouwd zijn met React en applicatierouting en servermogelijkheden in dezelfde codebase nodig hebben. Het kan ook geschikt zijn voor producten waarvan verschillende routes aanzienlijk uiteenlopende leveringsbehoeften hebben.
Veelvoorkomende toepassingen zijn onder meer:
- Accountgedeelten en dashboards met zowel servergegevens als interactieve bedieningselementen.
- Commerce- of cataloguservaringen die stabiele content combineren met informatie die van het verzoek afhankelijk is.
- Documentatie- of marketingsites die ook applicatieworkflows bevatten.
- Producten die HTML-antwoorden, clientinteractie en servereindpunten samen nodig hebben.
- React-applicaties waarvan de routes profiteren van afzonderlijke beleidsregels voor caching en rendering.
Het framework kan meer techniek omvatten dan een eenvoudige contentsite nodig heeft. Een team dat voornamelijk statische artikelen publiceert, moet zijn behoeften vergelijken met hulpmiddelen die gericht zijn op contentlevering, vooral als slechts een klein deel van de site React-interactie nodig heeft.
Next.js kan ook ongeschikt zijn wanneer het team de runtimevereisten niet kan ondersteunen, geen framework-specifieke renderingconcepten wil of moeite zou hebben om duidelijke server- en clientgrenzen te onderhouden. Flexibiliteit is alleen waardevol wanneer de architectuur begrijpelijk blijft.
Next.js vergelijken met Astro en andere opties
Next.js en Astro worden vaak beoordeeld voor projecten die content met interactieve elementen combineren, maar hun standaardinstellingen en mentale modellen verschillen. De juiste keuze hangt af van de werkelijke routes, niet van een algemene bewering dat het ene framework sneller of beter is.
Bouw voor een zinvolle vergelijking dezelfde representatieve pagina in elke kandidaat en leg het volgende vast:
- Hoeveel JavaScript de browser bereikt voor en na interactie.
- Hoe gegevens worden geladen en hoe de actualiteit wordt beheerd.
- Of serverruntimefuncties vereist zijn.
- Hoe routing, layouts, formulieren en foutstatussen worden geïmplementeerd.
- Of de beoogde host elke vereiste functie ondersteunt.
- Hoe gemakkelijk het team de resulterende architectuur kan testen en uitleggen.
Astro verdient bijzondere aandacht voor contentgerichte sites waar de meeste uitvoer statisch kan blijven en interactieve eilanden beperkt zijn. Next.js wordt aantrekkelijker wanneer React het centrale applicatiemodel is en server- en clientfuncties in het hele product moeten worden gecombineerd.
Geen van beide vergelijkingen voorspelt een prestatiescore. Afbeeldingen, lettertypen, scripts van derden, componentkeuzes, gegevenslatentie en clientgrenzen kunnen zwaarder wegen dan de standaardinstellingen van het framework.
Oorsprong, bestuur en community
De officiële bestuurspagina vermeldt dat het Vercel-team Next.js in 2016 heeft gemaakt. Er staat ook dat het kernteam bij Vercel het onderzoek en de ontwikkeling van het project leidt. Dit is een verklaring over de oorsprong en het bestuur op teamniveau; deze mag niet worden vervangen door een niet-onderbouwde bewering over een individuele oprichter.
Zoals gedocumenteerd op de bestuurs- en documentatiepagina's die op 27 augustus 2026 beschikbaar waren, omvatten de openbare participatiemogelijkheden van het project:
- De officiële GitHub-repository voor broncode, issues en projectactiviteit.
- GitHub Discussions voor vragen en RFC-discussies binnen de community.
- De Next.js Discord voor gratis communityondersteuning.
- Onderhouden documentatie voor zowel de App Router als de Pages Router.
Deze kanalen bieden verschillende soorten hulp. Documentatie moet de eerste referentie zijn voor frameworkgedrag, Discussions kan voorstellen en gedeelde vragen naar voren brengen en Discord kan gesprekken binnen de community ondersteunen. Geen ervan vervangt projectspecifieke tests of het eigen productieondersteuningsproces van een team.
Een beslissingschecklist
Voordat teams Next.js invoeren, moeten ze deze vragen beantwoorden met een werkend prototype:
- Welke routes zijn statisch, dynamisch, gecachet of gerevalideerd?
- Welke componenten vereisen werkelijk state, effecten, events of browser-API's?
- Hoeveel client-JavaScript levert elke representatieve route?
- Welke eindpunten horen in Route Handlers en welke horen elders?
- Kan het beoogde platform elke vereiste Next.js-functie uitvoeren?
- Hoe worden de actualiteit van de cache, storingen, logs en implementaties beheerd?
- Begrijpt het team de verschillen tussen de gekozen router en voorbeelden die voor de andere router zijn geschreven?
Next.js draait om het toepassen van React in een volledige webapplicatie, waarbij bewust wordt gekozen waar werk plaatsvindt en hoe elke route wordt geleverd. De gedocumenteerde flexibiliteit is aanzienlijk, maar garandeert geen prestaties, zoekresultaten, lage operationele kosten of architectonische eenvoud. Die resultaten moeten door implementatie en metingen worden vastgesteld.
Een geslaagde reactie is geen veiligheidsgarantie. Metingen beschrijven één waarneming op een bepaald moment.