nextjs.org

Next.js ist ein React-Framework zum Erstellen von Full-Stack-Webanwendungen. React stellt das Komponentenmodell für Benutzeroberflächen bereit; Next.js ergänzt Routing, Rendering, Konventionen für den Datenzugriff, Serverfunktionen, Kompilierung, Bündelung, Caching und produktionsorientierte Werkzeuge.

Das Hauptthema ist das Framework, nicht seine Domain. nextjs.org ist die offizielle Website, auf der Besucher gepflegte Dokumentation, Leitfäden, Community-Links und Informationen über das Projekt finden können.

Next.js ist besonders relevant, wenn ein Team mit React entwickeln und dabei mehr als eine reine Browseroberfläche unterstützen möchte. Ein Projekt kann vorgerenderte Seiten, Antworten zur Anfragezeit, serverseitigen Datenzugriff, API-ähnliche Endpunkte und interaktive Komponenten enthalten, die im Browser ausgeführt werden.

Was Next.js zu React hinzufügt

React hilft Entwicklern, Oberflächen als Komponenten zu beschreiben, schreibt jedoch keine vollständige Anwendungsarchitektur vor. Next.js stellt Konventionen dafür bereit, Dateien Routen zuzuordnen, festzulegen, wo Code ausgeführt wird, Daten zu laden, Antworten zu erzeugen und eine Anwendung für die Bereitstellung vorzubereiten.

Sein Nutzen geht daher über serverseitiges Rendering hinaus. Eine Next.js-Anwendung kann mehrere Rendering- und Bereitstellungsmethoden verwenden, manchmal innerhalb desselben Projekts. Das Framework koordiniert diese Methoden rund um React, anstatt jede Route in ein einziges Modell zu zwingen.

Eine hilfreiche Zusammenfassung der Aufteilung lautet:

• React definiert Komponenten, Zustand, Props und die Zusammensetzung der Oberfläche.
• Next.js definiert Routen, Layouts, Rendering-Optionen, Server-Einstiegspunkte und das Build-Verhalten.
• Die Anwendung definiert ihre Datenregeln, Client-Grenzen, Cache-Richtlinien und Bereitstellungsanforderungen.
• Die Hosting-Umgebung bestimmt, welche Laufzeitfunktionen verfügbar sind und wie sie arbeiten.

Diese Trennung ist wichtig, wenn Next.js mit einer React-Clientanwendung, einem Generator für statische Websites oder einem anderen Webframework verglichen wird. Das Framework bietet ein breites Spektrum an Funktionen, doch ein Projekt profitiert nur von den Funktionen, die es sinnvoll nutzt.

Server- und Client-Komponenten

Im App Router sind Layouts und Seiten standardmäßig Server Components. Server Components werden in einer Serverumgebung ausgeführt und können serverseitige Datenverarbeitung durchführen, ohne ihre Komponentenimplementierung an den Browser zu senden.

Client Components werden verwendet, wenn ein Teil der Oberfläche Browserzustand, Ereignisbehandler, Effekte oder reine Browser-APIs benötigt. Entwickler markieren eine Client-Grenze mit der Direktive use client, und Komponenten unterhalb dieser Grenze werden Teil des clientseitigen Modulgraphen.

Frage	Server Component	Client Component
Wo wird ihre Komponentenlogik ausgeführt?	In der Server-Rendering-Umgebung	Im Browser, nachdem sie in das Client-Bundle aufgenommen wurde
Kann sie Browserzustand oder Klick-Ereignisbehandler verwenden?	Nein	Ja
Kann sie direkt reine Browser-APIs verwenden?	Nein	Ja
Wird ihr Komponentencode an den Browser gesendet?	Nicht als Code einer Client Component	Ja
Typische Aufgabe	Datengestützte Inhalte, Layouts und serverseitige Zusammensetzung	Formulare, Menüs, Editoren, Filter und andere interaktive Steuerelemente

Eine Route muss sich nicht ausschließlich für einen Typ entscheiden. Eine Server Component kann Inhalte rendern und ausgewählte Client Components für die interaktiven Teile der Seite zusammensetzen. Dadurch können Teams Browser-JavaScript gezielt für bestimmte Anforderungen einsetzen, statt die gesamte Route als Clientanwendung zu behandeln.

Die Grenze muss dennoch sorgfältig gewählt werden. Wird ein großer Komponenten-Unterbaum hinter use client verschoben, kann mehr JavaScript an den Browser gesendet werden. Wird hingegen jedes kleine Steuerelement in eine eigene Grenze aufgeteilt, kann der Code schwerer verständlich werden. Repräsentative Seiten sollten gemessen und nicht allein anhand der Bezeichnung des Frameworks beurteilt werden.

Server Components unterscheiden sich außerdem von der Bereitstellungsstrategie einer Route. Eine Server Component kann zu vorgerenderten Ausgaben beitragen oder am dynamischen Rendering beteiligt sein. Die Beschreibung einer Komponente als serverseitig sagt allein nicht aus, ob die Route während eines Builds erzeugt, später aktualisiert oder für jede Anfrage erstellt wird.

App Router und Pages Router

Next.js dokumentiert derzeit zwei Routing-Systeme. Der App Router ist das neuere System und integriert React-Funktionen wie Server Components. Der Pages Router ist das ältere System und wird weiterhin unterstützt.

Bereich	App Router	Pages Router
Hauptstruktur der Routen	Das Verzeichnis app	Das Verzeichnis pages
Standardmäßiges Komponentenmodell	Layouts und Seiten sind Server Components	Verwendet das frühere Seitenmodell von Next.js
Gemeinsame Benutzeroberfläche	Verschachtelte Layouts sind eine zentrale Konvention	Wird üblicherweise über Anwendungs- und Seitenmuster zusammengesetzt
Bester Ausgangspunkt	Neue Projekte, die die aktuelle Architektur übernehmen	Bestehende Anwendungen oder Abhängigkeiten, die auf Pages-Router-APIs aufbauen

Eine Migration umfasst mehr als das Umbenennen von Ordnern. Code für den App Router führt ein serverorientiertes Komponentenmodell sowie andere Muster für Layouts, Datenzugriff, Ladezustände und Routenverhalten ein. Teams sollten diese konzeptionellen Änderungen erkennen, bevor sie eine ausgereifte Anwendung umstellen.

Neue Projekte sollten üblicherweise zuerst die Dokumentation zum App Router lesen, da sie das aktuelle Modell des Frameworks erläutert. Bestehende Pages-Router-Anwendungen sollten eine Migration anhand tatsächlicher Vorteile, Abhängigkeiten, des Testaufwands und der Wartungskosten bewerten, anstatt die fortgesetzte Unterstützung als Mangel zu betrachten.

Dokumentation und Beispiele können sich nur auf einen Router beziehen. Bevor Entwickler eine Implementierung übernehmen, sollten sie prüfen, welchen Router sie verwendet und ob die genannten APIs auf ihr Projekt anwendbar sind.

Rendering, Caching und Revalidierung

Next.js rendert nicht jede Seite auf dieselbe Weise. Eine Route kann vorbereitet werden, bevor ein Besucher eintrifft, anhand anfragespezifischer Informationen erzeugt, zwischengespeichert oder gemäß einer Revalidierungsrichtlinie aktualisiert werden.

Anforderung der Route	Wahrscheinlicher Bereitstellungsansatz	Zu prüfende Frage
Eingaben sind im Voraus bekannt	Vorgerenderte Ausgabe	Welches Ereignis sollte eine Änderung der Ausgabe auslösen?
Ausgabe hängt von Cookies, Headern oder Anfragedaten ab	Dynamisches Rendering	Kann ein Teil der Verarbeitung dennoch sicher zwischengespeichert werden?
Inhalte ändern sich nach einem kontrollierten Zeitplan	Zwischengespeicherte Ausgabe mit Revalidierung	Wie veraltet darf die Antwort werden?
Es wird keine reine Serverfunktion benötigt	Ein statischer Export könnte geeignet sein	Sind alle Routen und Assets mit den Einschränkungen des Exports kompatibel?

Caching ist kein einzelner Schalter, der unabhängig vom Datenzugriff verstanden werden kann. Teams müssen wissen, welche Vorgänge zwischengespeichert werden, welche Routen dynamisch werden und wie Invalidierung oder Revalidierung erfolgen. Diese Regeln sollten anhand realistischer Inhaltsänderungen getestet werden.

Dies ist besonders wichtig für authentifizierte Seiten, Preise, Bestände, Dashboards und andere Informationen mit ausdrücklichen Aktualitätsanforderungen. Die Bereitstellung zwischengespeicherter Ausgaben kann wertvoll sein, aber nur, wenn die Korrektheitsregeln der Anwendung dies zulassen.

Leistung und Sichtbarkeit in Suchmaschinen sollten nicht allein aus der Rendering-Bezeichnung abgeleitet werden. Vorrendering kann die Verarbeitung zur Anfragezeit reduzieren, und Server-Rendering kann aussagekräftiges anfängliches HTML bereitstellen. Die tatsächlichen Ergebnisse hängen jedoch von Seitenstruktur, Assets, Datenlatenz, Browser-JavaScript, Caching und Bereitstellungsverhalten ab.

Statischer Export und Laufzeitanforderungen

Next.js kann einen statischen Export erzeugen, wenn das Projekt nicht von reinen Serverfunktionen des Frameworks abhängt. Die daraus entstehenden HTML-, CSS- und JavaScript-Dateien sowie Assets können von einer Infrastruktur bereitgestellt werden, die gewöhnliche statische Dateien unterstützt.

Statische Ausgaben können weiterhin Client Components enthalten. Die statische Bereitstellung beschreibt, wie das erstellte Ergebnis gehostet wird; sie bedeutet nicht, dass jede Oberfläche nicht interaktiv sein muss. Browserseitiger Code kann weiterhin Zustand, Ereignisse und anderes Clientverhalten bereitstellen.

Prüfen Sie vor der Wahl eines statischen Exports, dass das Projekt Folgendes nicht benötigt:

• Antworten, die aus anfragespezifischen Serverdaten erzeugt werden.
• Routenverhalten, das von einer aktiven Next.js-Laufzeit abhängt.
• Nicht unterstützte Bild-, Routing- oder Serverfunktionen.
• Aktualitätsregeln, die nicht durch einen erneuten Build oder einen anderen unterstützten Aktualisierungsprozess erfüllt werden können.
• Serverendpunkte, die zusammen mit der Anwendung ausgeführt werden müssen.

Wenn diese Funktionen erforderlich sind, benötigt die Anwendung eine kompatible Laufzeit. Dies erfordert keine Bereitstellung auf Vercel: Der offizielle Bereitstellungsleitfaden dokumentiert Self-Hosting und Plattformadapter. Die Unterstützung unterscheidet sich je nach Plattform, weshalb die Kompatibilität anhand der konkret verwendeten Funktionen geprüft werden sollte.

Route Handlers und serverseitige Endpunkte

Im App Router ermöglichen Route Handlers einer Anwendung, HTTP-Anfragebehandler mithilfe standardmäßiger Anfrage- und Antwortkonzepte zu definieren. Sie eignen sich für Endpunkte, die neben die Anwendung gehören, darunter Formularverarbeitung, Webhooks, Datenantworten oder Integrations-Callbacks.

Ein Route Handler ist nicht automatisch der richtige Ort für jedes Backend-System. Teams sollten weiterhin entscheiden, wie Authentifizierung, Autorisierung, Validierung, Ratenbegrenzungen, dauerhafte Verarbeitung und Fehlerbehandlung verwaltet werden. Lang laufende oder unabhängig skalierte Dienste sollten möglicherweise von der Webanwendung getrennt werden.

Eine praktische Prüfung stellt folgende Fragen:

1. Benötigt der Endpunkt Zugriff auf Anwendungscode oder gemeinsame Typen?
2. Benötigt er Geheimnisse zur Anfragezeit oder reine Serverabhängigkeiten?
3. Kann die Zielplattform den Handler wie dokumentiert ausführen?
4. Welches Caching-Verhalten ist für jede HTTP-Methode und Antwort korrekt?
5. Würde ein separater Dienst klarere Zuständigkeiten oder eine bessere Skalierung bieten?

Route Handlers machen die Full-Stack-Zusammensetzung komfortabel, doch dieser Komfort beseitigt nicht die üblichen Verantwortlichkeiten für API-Design und Sicherheit.

Wo Next.js eine praktische Wahl ist

Next.js ist ein starker Kandidat für Teams, die bereits mit React vertraut sind und Anwendungsrouting sowie Serverfunktionen in derselben Codebasis benötigen. Es kann sich auch für Produkte eignen, deren verschiedene Routen deutlich unterschiedliche Bereitstellungsanforderungen haben.

Typische Einsatzgebiete sind:

• Kontobereiche und Dashboards mit Serverdaten und interaktiven Steuerelementen.
• Handels- oder Katalogerlebnisse, die stabile Inhalte mit anfrageabhängigen Informationen kombinieren.
• Dokumentations- oder Marketing-Websites, die auch Anwendungsabläufe enthalten.
• Produkte, die HTML-Antworten, Clientinteraktion und Serverendpunkte gemeinsam benötigen.
• React-Anwendungen, deren Routen von getrennten Caching- und Rendering-Richtlinien profitieren.

Für eine einfache Inhaltswebsite kann das Framework mehr Komplexität mitbringen als nötig. Ein Team, das überwiegend statische Artikel veröffentlicht, sollte seine Anforderungen mit Werkzeugen vergleichen, die auf die Bereitstellung von Inhalten ausgerichtet sind, insbesondere wenn nur ein kleiner Teil der Website React-Interaktion benötigt.

Next.js kann außerdem ungeeignet sein, wenn das Team seine Laufzeitanforderungen nicht unterstützen kann, keine frameworkspezifischen Rendering-Konzepte möchte oder Schwierigkeiten hätte, klare Server- und Client-Grenzen beizubehalten. Flexibilität ist nur dann wertvoll, wenn die Architektur verständlich bleibt.

Vergleich von Next.js mit Astro und anderen Optionen

Next.js und Astro werden häufig für Projekte bewertet, die Inhalte mit interaktiven Elementen kombinieren, doch ihre Standardvorgaben und Denkmodelle unterscheiden sich. Die geeignete Wahl hängt von den tatsächlichen Routen ab, nicht von einer allgemeinen Behauptung, ein Framework sei schneller oder besser.

Erstellen Sie für einen sinnvollen Vergleich dieselbe repräsentative Seite mit jedem Kandidaten und halten Sie Folgendes fest:

• Wie viel JavaScript vor und nach einer Interaktion den Browser erreicht.
• Wie Daten geladen und ihre Aktualität gesteuert werden.
• Ob Server-Laufzeitfunktionen erforderlich sind.
• Wie Routing, Layouts, Formulare und Fehlerzustände implementiert werden.
• Ob der Zielhost jede erforderliche Funktion unterstützt.
• Wie einfach das Team die entstehende Architektur testen und erklären kann.

Astro verdient besondere Beachtung für inhaltsorientierte Websites, bei denen der größte Teil der Ausgabe statisch bleiben kann und interaktive Inseln begrenzt sind. Next.js wird attraktiver, wenn React das zentrale Anwendungsmodell ist und Server- sowie Clientfunktionen im gesamten Produkt zusammengesetzt werden müssen.

Keiner der Vergleiche sagt einen Leistungswert voraus. Bilder, Schriftarten, Skripte von Drittanbietern, die Wahl der Komponenten, Datenlatenz und Client-Grenzen können die Standardvorgaben des Frameworks überwiegen.

Ursprünge, Governance und Community

Die offizielle Governance-Seite gibt an, dass das Vercel-Team Next.js im Jahr 2016 entwickelt hat. Sie erklärt außerdem, dass das Kernteam bei Vercel die Forschung und Entwicklung des Projekts leitet. Dies ist eine Aussage über Ursprung und Governance auf Teamebene; sie sollte nicht durch eine unbelegte Behauptung über einen einzelnen Gründer ersetzt werden.

Wie auf den am 27. August 2026 verfügbaren Governance- und Dokumentationsseiten dokumentiert, gehören zu den öffentlichen Beteiligungsmöglichkeiten des Projekts:

• Das offizielle GitHub-Repository für Quellcode, Issues und Projektaktivitäten.
• GitHub Discussions für Fragen und RFC-Diskussionen der Community.
• Der Next.js Discord für kostenlosen Community-Support.
• Gepflegte Dokumentation sowohl für den App Router als auch den Pages Router.

Diese Kanäle bieten unterschiedliche Arten von Unterstützung. Die Dokumentation sollte die erste Referenz für das Verhalten des Frameworks sein, Discussions können Vorschläge und gemeinsame Fragen sichtbar machen und Discord kann den Austausch in der Community unterstützen. Keiner davon ersetzt projektspezifische Tests oder den eigenen Produktionssupport eines Teams.

Eine Entscheidungscheckliste

Vor der Einführung von Next.js sollten Teams diese Fragen mit einem funktionierenden Prototyp beantworten:

• Welche Routen sind statisch, dynamisch, zwischengespeichert oder revalidiert?
• Welche Komponenten benötigen tatsächlich Zustand, Effekte, Ereignisse oder Browser-APIs?
• Wie viel Client-JavaScript liefert jede repräsentative Route aus?
• Welche Endpunkte gehören in Route Handlers und welche an eine andere Stelle?
• Kann die Zielplattform jede erforderliche Next.js-Funktion ausführen?
• Wie werden Cache-Aktualität, Ausfälle, Protokolle und Bereitstellungen verwaltet?
• Versteht das Team die Unterschiede zwischen dem gewählten Router und Beispielen, die für den anderen Router geschrieben wurden?

Bei Next.js geht es darum, React auf eine vollständige Webanwendung anzuwenden und dabei bewusst zu entscheiden, wo Verarbeitung stattfindet und wie jede Route bereitgestellt wird. Die dokumentierte Flexibilität ist beträchtlich, garantiert jedoch weder Leistung noch Suchergebnisse, niedrige Betriebskosten oder architektonische Einfachheit. Diese Ergebnisse müssen durch Implementierung und Messung nachgewiesen werden.