Next.js vs. Nuxt vs. SvelteKit: Welches Framework passt zum Projekt?

Ein Inhalt vom CMS bis zum Seitenaufruf: Next.js, Nuxt und SvelteKit im Vergleich. Mit gemeinsamem Praxisbeispiel und einer Einordnung von Datenfluss, Caching und Übergabe.

Technologie 2. Januar 2026 Aktualisiert am 10. September 2026 6 min Lesezeit Tobias, Geschäftsführer

Praxisvergleich

Next.js, Nuxt und SvelteKit im Projektvergleich

Ein Inhalt. Drei Umsetzungen.

Einen Artikel laden und darstellen: dieselbe Aufgabe in Next.js, Nuxt und SvelteKit. Vergleichen Sie direkt im Code, wie Datenabruf, Fehlerbehandlung und Seitenausgabe aufgebaut sind.

Umsetzung vergleichenGleiche Aufgabe, andere Werkzeuge

So funktioniert es

Eine Server Component lädt den Inhalt und gibt die fertige Seite zurück. notFound übernimmt fehlende Inhalte; weitere Fehler gehen an die Fehlergrenze der Route.

Wann wir es wählen

Passt zu React-Projekten, bei denen serverseitige Inhalte und interaktive Komponenten gemeinsam geplant werden.

Was wir dabei abwägen

Server- und Client-Grenzen sowie Cache-Regeln müssen bewusst festgelegt werden. no-store macht das Beispiel nachvollziehbar, ist aber keine allgemeine Cache-Empfehlung.

Code in Next.js

app/beispiel/page.tsx

import { notFound } from 'next/navigation'

type Article = { title: string; summary: string }

export default async function Page() {
  const response = await fetch('https://cms.example.com/api/article', {
    cache: 'no-store',
  })
  if (response.status === 404) notFound()
  if (!response.ok) throw new Error('Der Inhalt konnte nicht geladen werden.')
  const article: Article = await response.json()

  return <article>
    <h1>{article.title}</h1>
    <p>{article.summary}</p>
  </article>
}

Next.js als Leistung Offizielle Dokumentation

So funktioniert es

useFetch lädt den Inhalt beim serverseitigen Rendern und übergibt ihn im Seiten-Payload an Vue. Das Template nutzt die geladenen Daten.

Wann wir es wählen

Passt, wenn Vue bereits gesetzt ist und Seiten, Datenabrufe sowie Server-Routen in einem gemeinsamen Projekt organisiert werden sollen.

Was wir dabei abwägen

Schlüssel und Lebensdauer gemeinsam genutzter Daten sowie Route Rules müssen abgestimmt sein. Ein voller Seitenaufruf ist nicht dasselbe wie jeder clientseitige Routenwechsel.

Code in Nuxt

app/pages/beispiel.vue

<script setup lang="ts">
type Article = { title: string; summary: string }

const { data: article, error } = await useFetch<Article>(
  'https://cms.example.com/api/article',
  { cache: 'no-store' },
)
if (error.value) {
  throw createError({
    statusCode: error.value.statusCode === 404 ? 404 : 502,
    statusMessage: 'Der Inhalt konnte nicht geladen werden.',
  })
}
if (!article.value) throw createError({ statusCode: 404 })
</script>

<template>
  <article v-if="article">
    <h1>{{ article.title }}</h1>
    <p>{{ article.summary }}</p>
  </article>
</template>

Nuxt als Leistung Offizielle Dokumentation

So funktioniert es

Eine serverseitige load-Funktion lädt den Inhalt. Die benachbarte Svelte-Seite erhält die Daten über ihre PageData und übernimmt die Darstellung.

Wann wir es wählen

Passt zu Svelte-Projekten, die Datenladen, Formularaktionen und Seitenansichten mit den Routenkonventionen von SvelteKit verbinden möchten.

Was wir dabei abwägen

Die Trennung zwischen serverseitigem und universellem Laden sowie der Deployment-Adapter müssen zu den Anforderungen passen.

Code in SvelteKit

src/routes/beispiel/+page.server.ts

import { error } from '@sveltejs/kit'
import type { PageServerLoad } from './$types'

type Article = { title: string; summary: string }

export const load: PageServerLoad = async ({ fetch }) => {
  const response = await fetch('https://cms.example.com/api/article', {
    cache: 'no-store',
  })
  if (response.status === 404) error(404, 'Inhalt nicht gefunden.')
  if (!response.ok) error(502, 'Der Inhalt konnte nicht geladen werden.')
  const article: Article = await response.json()
  return { article }
}

src/routes/beispiel/+page.svelte

<script lang="ts">
import type { PageData } from './$types'
let { data }: { data: PageData } = $props()
</script>

<article>
  <h1>{data.article.title}</h1>
  <p>{data.article.summary}</p>
</article>

SvelteKit als Leistung Offizielle Dokumentation

Rahmen des Beispiels

Die Beispiele erwarten eine öffentliche CMS-Schnittstelle mit JSON-Feldern title und summary oder HTTP 404. cms.example.com ist eine Platzhalteradresse, die Sie beim Übernehmen durch Ihren Endpunkt ersetzen. Gezeigt wird ein neuer serverseitiger Seitenaufruf ohne vorgeschalteten CMS-Cache oder Prerendering.

Next.js, Nuxt und SvelteKit verbinden Seiten, Datenabrufe und serverseitige Funktionen in einem Anwendungsframework. Sie bauen auf React, Vue beziehungsweise Svelte auf. Wer eine Agentur-Website, ein Inhaltsportal oder eine Webanwendung plant, sollte deshalb sowohl die vorhandene Frontend-Basis als auch die Anforderungen an Inhalte, Interaktion und Betrieb betrachten. Unser gemeinsames Beispiel zeigt einen klar abgegrenzten Ablauf: einen veröffentlichten CMS-Inhalt bei einem neuen Seitenaufruf darstellen.

Derselbe Artikel, drei Codebeispiele

Die Aufgabe ist in allen drei Varianten gleich: einen Artikel laden, fehlende Inhalte erkennen und Titel sowie Zusammenfassung ausgeben. Next.js verbindet den Abruf mit JSX in einer Server Component. Nuxt verwendet useFetch und ein Vue-Template. SvelteKit verteilt den Abruf und die Darstellung auf zwei Dateien derselben Route. Die Tabs zeigen diese Unterschiede direkt im Quelltext.

Die Codebeispiele erwarten dieselbe Antwort: einen Titel und eine Zusammenfassung als JSON oder HTTP 404. Die Adresse cms.example.com dient als Platzhalter für einen eigenen Endpunkt. In allen drei Varianten wird bei einem neuen serverseitigen Seitenaufruf frisch gelesen. Prerendering und vorgeschaltete CMS-Caches sind für diese Aufgabe ausgenommen.

Next.js: Inhalte in einer Server Component laden

Im Next.js-Beispiel übernimmt eine asynchrone Server Component den Datenabruf und die Darstellung. Eine fehlende Veröffentlichung ruft notFound auf. Andere fehlgeschlagene Antworten lösen einen Fehler aus, den eine Fehlergrenze der Route behandeln kann. cache: no-store macht die gewünschte Aktualität dieses Beispiels ausdrücklich. Die interaktive Bedienung einer echten Anwendung würde dort ergänzt, wo sie benötigt wird.

Wir betrachten Next.js besonders dann, wenn React bereits Teil der vorhandenen Anwendung ist und serverseitige Inhalte mit interaktiven Bereichen verbunden werden sollen. Dabei klären wir früh, welche Komponenten auf dem Server arbeiten, welche im Browser laufen und welche Daten die Grenze überqueren dürfen. Auch eine übersichtliche Server Component ersetzt keine Planung für Berechtigungen, Fehlerbehandlung und das Aktualisieren veröffentlichter Inhalte.

Nuxt: Daten für Server und Vue-Seite verbinden

Nuxt stellt mit useFetch einen auf seinen Seitenlebenszyklus abgestimmten Datenabruf bereit. Beim serverseitigen Rendern geladene Daten werden im Payload an den Browser übergeben. Das vermeidet einen allein durch die Übernahme der Seite ausgelösten zweiten Abruf. Im Beispiel liest das Vue-Template den Titel und die Zusammenfassung aus dem Ergebnis; createError übernimmt Fehlerantworten.

Nuxt ist für uns eine naheliegende Wahl, wenn ein Team mit Vue arbeitet und Seiten, Datenabrufe und Server-Routen gemeinsam organisieren möchte. Die Schlüssel und Lebensdauer gemeinsam genutzter Daten sowie die Route Rules gehören dabei in die Architekturentscheidung. Ein vollständiger neuer Seitenaufruf und eine Navigation innerhalb der laufenden Anwendung sind unterschiedliche Situationen. Für beide muss klar sein, wann vorhandene Daten wiederverwendet oder neu geladen werden.

SvelteKit: serverseitig laden, in der Seite darstellen

Im SvelteKit-Beispiel liegt der Abruf in einer +page.server.ts-Datei. Die load-Funktion liefert die Artikeldaten an die benachbarte +page.svelte-Datei. Fehlende Inhalte und andere Abruffehler werden getrennt behandelt. Die Darstellung greift auf die generierten Seitentypen zurück. Damit bleiben serverseitiger Datenzugriff und Komponentenansicht in unterschiedlichen Dateien derselben Route.

Wir ziehen SvelteKit in Betracht, wenn Svelte die passende Frontend-Basis ist und die Routenkonventionen zu den geplanten Seiten und Formularabläufen passen. Für ein Projekt prüfen wir die benötigten Integrationen und den vorgesehenen Deployment-Adapter. Außerdem unterscheiden wir serverseitige und universelle Ladefunktionen bewusst. Zugangsdaten und serverseitige Verantwortung dürfen nicht versehentlich in Code geraten, der auch im Browser ausgeführt wird.

Caching ist eine Inhaltsentscheidung

Unser Beispiel lädt absichtlich frisch, damit eine Veröffentlichung beim nächsten Abruf nachvollziehbar wird. Daraus folgt keine Empfehlung, jede produktive Seite ungecacht auszuliefern. Eine öffentliche Inhaltsseite, eine persönliche Kontoansicht und eine redaktionelle Vorschau haben unterschiedliche Anforderungen. Wir legen deshalb pro Datenbereich fest, wer die Inhalte sehen darf und wann sie erneuert werden müssen.

Für ein CMS-Projekt klären wir insbesondere:

Veröffentlichung: Soll eine Änderung beim nächsten Abruf erscheinen oder darf ein älterer öffentlicher Stand vorübergehend bestehen bleiben?
Aktualisierung: Welche Cache-Ebenen gibt es und wie werden sie nach einer Veröffentlichung erneuert?
Vorschau: Wie sieht die Redaktion einen Entwurf, ohne ihn öffentlich zugänglich zu machen?
Fehler: Was passiert, wenn das CMS nicht erreichbar ist oder ein Inhalt entfernt wurde?
Berechtigung: Welche Antworten dürfen öffentlich wiederverwendet werden und welche gehören ausschließlich zu einem angemeldeten Nutzer?

Die Antworten beeinflussen den Datenfluss stärker als die Frage, ob ein Abruf in einer Server Component, einem Composable oder einer load-Funktion steht. Sie müssen bei der Übergabe dokumentiert sein. Sonst wirkt eine technisch erfolgreiche Veröffentlichung für die Redaktion wie ein Fehler, weil die sichtbare Seite noch einen anderen Stand verwendet.

So wählen wir das Framework für ein Agenturprojekt

Eine bestehende React-, Vue- oder Svelte-Codebasis ist ein wichtiger Ausgangspunkt. Wir prüfen, was sich zuverlässig weiterverwenden lässt und wo tatsächliche Grenzen liegen. Bei einem neuen Projekt betrachten wir das CMS, die erforderlichen Integrationen, die interaktiven Abläufe und die Kenntnisse des späteren Betreuungsteams gemeinsam. Ein kleines Beispiel hilft, die Arbeitsweise zu verstehen. Eine belastbare Auswahl braucht zusätzlich die schwierigsten Anforderungen des konkreten Projekts.

Zum Betrieb gehören der vorgesehene Hosting-Modus, Veröffentlichung und Rücknahme von Änderungen sowie der Zugriff auf Fehlerprotokolle. Diese Punkte prüfen wir für die gewählte Kombination aus Framework und Hosting. Die Unterstützung eines Features im Framework allein sagt noch nicht, dass es im vorgesehenen Deployment genauso betrieben werden kann. Für die Übergabe halten wir deshalb sowohl den Codeaufbau als auch die Betriebsannahmen fest.

Was wir aus dem Beispiel nicht ableiten

Eine kürzere Datei ist kein Nachweis für bessere Wartbarkeit. Eine zusätzliche Datei kann eine klare Zuständigkeit abbilden. Auch aus der Syntax lässt sich nicht ableiten, welches Framework für ein bestimmtes Projekt schneller ist. Solche Aussagen brauchen ein festgelegtes Szenario und nachvollziehbare Messungen. Hier zeigt der Vergleich, wie derselbe Datenfluss ausgedrückt wird und welche Fragen vor einem realen Projekt beantwortet werden müssen.

Alle drei Lösungen können zu einer nachvollziehbaren Implementierung führen. Wir empfehlen die Variante, deren Komponenten, Datenfluss und Betrieb zu den Anforderungen und zum Team passen. Der Vergleich soll diese Entscheidung verständlich machen, ohne eine allgemeine Rangliste zu behaupten.

Quellen zum Vergleich

Technische Grundlagen und weiterführende Dokumentation, geprüft am 9. September 2026. Die Empfehlungen zur Projektwahl sind unsere Einordnung.

Passende Technologien

Next.js Nuxt SvelteKit

Themen

Next.js
Nuxt
SvelteKit
SSR
CMS
Technologievergleich

Weiterführende Artikel

Und Ihr Projekt?

Sprechen Sie mit uns über die technischen und organisatorischen Fragen, die Sie gerade beschäftigen.

Kontakt aufnehmen

Next.js vs. Nuxt vs. SvelteKit: Welches Framework passt zum Projekt?

Next.js, Nuxt und SvelteKit im Projektvergleich

Ein Inhalt. Drei Umsetzungen.

Derselbe Artikel, drei Codebeispiele

Next.js: Inhalte in einer Server Component laden

Nuxt: Daten für Server und Vue-Seite verbinden

SvelteKit: serverseitig laden, in der Seite darstellen

Caching ist eine Inhaltsentscheidung

So wählen wir das Framework für ein Agenturprojekt

Was wir aus dem Beispiel nicht ableiten

Quellen zum Vergleich

Passende Technologien

Weiterführende Artikel

React vs. Vue vs. Svelte: Welches Frontend passt zum Projekt?

CMS auswählen: WordPress, Sanity, Strapi oder Contentful?

WordPress-Relaunch: Bestehendes verbessern oder Headless umbauen?

Und Ihr Projekt?