Next.js oder React + Vite: Eine Entscheidungshilfe

Die falsche Frage

"Next.js vs. React" ist eigentlich kein fairer Vergleich – Next.js baut schließlich auf React auf. Die eigentliche Frage lautet: Next.js vs. React + eigenes Tooling (Vite, React Router, TanStack Query/Router, eigenes Backend). Sobald man das klarstellt, verschwindet auch das Gefühl, sich für "das modernere" oder "das bessere" Framework entscheiden zu müssen. Es geht um Trade-offs, nicht um Religion.

Entscheidungskriterien

Bevor es an die konkreten Fälle geht, lohnt sich ein Blick auf die Kriterien, die wirklich den Ausschlag geben:

• Rendering-Anforderungen – Muss der Inhalt bereits fertig gerendert beim Browser bzw. bei Suchmaschinen-Crawlern ankommen (SSR, SSG, ISR), oder reicht es, wenn React die Seite komplett im Browser aufbaut (CSR)? Das entscheidet sich vor allem an SEO-Bedarf und daran, wie wichtig eine schnelle erste Anzeige der Inhalte ist – bei einer Login-App interessiert das niemanden, bei einer öffentlichen Content-Seite ist es entscheidend.

• Routing-Komplexität – Next.js bringt File-based Routing mit: Die Ordnerstruktur bestimmt die URL-Struktur, das spart Konfiguration, gibt aber auch Konventionen vor. Brauchst du dagegen sehr spezifisches, dynamisches oder verschachteltes Routing-Verhalten, das sich nicht gut in dieses Modell pressen lässt, bist du mit einem eigenen Router (z. B. React Router) oft flexibler.

• Deployment-Constraints – Next.js spielt seine Stärken (SSR, ISR, API-Routes) vor allem dann aus, wenn eine Node-Runtime läuft – typischerweise auf Vercel oder einem eigenen Node-Server. Kannst oder willst du nur auf klassischem Static Hosting deployen (z. B. S3, Cloudflare Pages, ein internes CDN ohne Server-Laufzeit), fällt ein großer Teil von Next.js' Mehrwert weg, und reines React ist oft die konsequentere Wahl.

• Team-Erfahrung – Next.js' App Router bringt mit Server und Client Components ein neues mentales Modell mit sich: Man muss verstehen, was wo läuft, wie Caching greift und wann man "use client" braucht. Ein Team, das damit noch nicht vertraut ist, verliert hier Zeit – ein bereits bekanntes, reines Client-Modell mit Vite senkt die Einstiegshürde.

• API-Layer – Existiert bereits ein eigenes Backend (z. B. ein separates REST- oder GraphQL-API-Projekt), das die Datenversorgung übernimmt, brauchst du Next.js' Route Handlers und Server Actions oft gar nicht – sie wären ein zweiter, redundanter Backend-Layer. Fehlt dagegen noch ein Backend oder soll bewusst alles in einem Repo liegen, sind Route Handlers eine schlanke Alternative zu einem eigenen Server.

Wann Next.js sinnvoll ist

1. SEO ist wichtig Content-Seiten, Blogs, Marketing-Sites, E-Commerce-Shops: SSR oder SSG liefern fertiges HTML an Crawler. Reines React (CSR) rendert client-seitig – ohne Zusatzaufwand schlechter für SEO.

2. Performance beim ersten Laden zählt Time-to-First-Byte und Largest Contentful Paint sind bei SSR/SSG deutlich besser – wichtig bei langsamen Verbindungen oder wenn die Absprungrate kritisch ist. Durch Server Components, automatische Bildoptimierung (next/image) und statische Vorgenerierung (SSG/ISR) erreichst du extrem schnelle First Contentful Paints.

3. Du brauchst Routing + Backend-Logik in einem Projekt File-based Routing spart Konfigurationsaufwand. API-Routes/Route Handlers ersetzen für einfache bis mittlere Anforderungen ein separates Backend, Server Actions (App Router) vereinfachen Mutations ohne eigene API-Schicht.

4. Statische Inhalte mit gelegentlichen Updates ISR (Incremental Static Regeneration) ist ideal für Content, der sich selten ändert – Blogartikel, Produktseiten.

5. Team will "Convention over Configuration" Vercel-Ökosystem, Image- und Font-Optimierung, Caching – vieles ist vorkonfiguriert. Weniger eigene Build-Tooling-Entscheidungen (Webpack/Vite, Router-Wahl etc.).

6. Große Teams mit Standardisierungsbedarf Next.js gibt eine klare Ordnerstruktur und Konventionen vor (App Router, Caching, Routing), was die Zusammenarbeit in großen Entwicklerteams erleichtert.

Wann React + Vite die bessere Wahl ist

1. Interne Tools, Dashboards, Admin-Panels Keine SEO-Relevanz, da hinter Login – SSR bringt hier meist nur Overhead ohne Nutzen.

2. Reine SPA mit viel Client-State Komplexe interaktive Apps wie Editoren, Canvas-Tools oder Trading-Dashboards. Next.js' Server/Client-Component-Modell kann hier eher im Weg stehen als helfen.

3. Du willst volle Kontrolle über das Setup Eigene Build-Pipeline, eigener Router, eigenes State-Management ohne Framework-Vorgaben. Next.js' Opinionated-Ansatz (App Router, Caching-Verhalten) kann einschränken.

4. Kein eigenes Backend nötig oder bereits vorhanden Existiert bereits ein separates Backend (z. B. REST/GraphQL-API), brauchst du die API-Routes von Next.js oft gar nicht – reines React + Vite ist dann schlanker.

5. Deployment-Constraints Next.js entfaltet sein volles Potenzial primär mit Node-Runtime oder auf Vercel. Bei statischem Hosting ohne Node-Server (reines CDN/S3) ist output: 'export' zwar möglich, aber du verlierst SSR/ISR/API-Routes – dann ist reines React oft konsequenter.

6. Kleinere, einfache Projekte Lernprojekte, Prototypen, kleine Widgets: Next.js' zusätzliche Komplexität (Server/Client Components, Caching-Mentalmodell) lohnt sich nicht immer.

7. Offline-First & Mobile (Capacitor/Electron) Wenn du deine React-Codebasis eng mit Electron (Desktop) oder Capacitor/Ionic (Mobile) verknüpfen musst, oder extrem strikte Service-Worker-Logiken für Offline-Apps brauchst.

Die Grauzone

Nicht jeder Fall ist so eindeutig. Eine mittelgroße SaaS-App mit öffentlicher Marketing-Landingpage und privatem App-Bereich hinter Login ist ein klassischer Grenzfall: Next.js deckt beides in einem Projekt ab, aber der private Teil profitiert kaum von SSR – hier ist es Geschmackssache, ob man ein Projekt oder zwei getrennte Stacks pflegt.

Entscheidungsmatrix

Eine praktische Faustregel

Drei Fragen reichen oft schon aus:

1. Muss Google meine Inhalte gut indexieren? → Ja → Next.js

2. Brauche ich serverseitige Logik/Datenzugriff innerhalb meiner React-Anwendung? → Ja → Next.js wird sehr interessant

3. Ist es im Wesentlichen eine interaktive Anwendung hinter einem Login, die mit einem separaten Backend kommuniziert? → Ja → React + Vite reicht häufig völlig aus

Fazit

Die Entscheidung zwischen Next.js und reinem React ist selten eine Frage von "besser" oder "schlechter", sondern von passt zum Anwendungsfall. Öffentliche, SEO-relevante Plattformen profitieren enorm von Next.js' Rendering-Modell und Konventionen. Interne Tools und hochinteraktive Client-Anwendungen fahren dagegen oft besser mit einem schlanken React + Vite-Setup ohne Framework-Overhead. Wer sich für Next.js entscheidet und tiefer in Server Components einsteigen will, findet dazu mehr in React Server Components: Wann sie sich lohnen – und wann nicht.