Nuxt: Das Fullstack-Vue-Framework, erklärt

Vue ist großartig. Warum also Nuxt?

Vue alleine ist ein hervorragendes Framework für client-seitige Anwendungen. Aber sobald man anfängt, Fragen zu stellen — Wie kommt die Seite in Suchmaschinen? Wie wird initiales HTML schnell ausgeliefert? Wo läuft die Serverlogik? — landet man schnell an den Grenzen dessen, was ein reines SPA sinnvoll leisten kann.

Nuxt füllt diese Lücken. Nicht durch Komplexität, sondern durch Konventionen: ein Projekt-Setup, das SEO, Performance, Routing und Server-Logik als Erstklassige Bürger behandelt — ohne dass man alles manuell verdrahten muss.

Rendering-Strategien: mehr als nur SSR

Das Erste, womit man Nuxt gleichsetzt, ist Server-Side Rendering. Das stimmt, aber es ist nur ein Teil des Bildes.

SSR (Server-Side Rendering) — Das HTML wird bei jedem Request auf dem Server gerendert. Der Browser bekommt sofort fertiges HTML, was Time-to-First-Byte und SEO verbessert. Anschließend übernimmt Vue client-seitig (Hydration).

SSG (Static Site Generation) — Seiten werden zur Build-Zeit gerendert und als statische HTML-Dateien ausgeliefert. Null Server-Overhead im Betrieb, maximale Performance. Ideal für Inhalte, die sich selten ändern.

SWR / ISR (Stale-While-Revalidate / Incremental Static Regeneration) — Das Beste aus beiden Welten: Seiten werden gecacht und nach einem konfigurierbaren Zeitraum im Hintergrund neu gebaut. Der Benutzer bekommt immer eine sofortige Antwort, während der Cache sich still aktualisiert.

Hybrid Rendering — Nuxt erlaubt es, all diese Strategien auf Route-Ebene zu mischen. routeRules in nuxt.config.ts macht es möglich:

routeRules: {
  '/':          { prerender: true },
  '/blog/**':   { swr: 3600 },
  '/dashboard': { ssr: false },
}

Diese Flexibilität ist ein Hauptargument für Nuxt in realen Projekten, bei denen nicht jede Seite dieselben Anforderungen hat.

Auto-Imports: weniger Boilerplate, mehr Fokus

In einem Standard-Vue-Projekt importiert man explizit alles — Komponenten, Composables, Vue-APIs:

import { ref, computed } from 'vue'
import { useRoute } from 'vue-router'
import MyComponent from '~/components/MyComponent.vue'

Nuxt eliminiert das. Alles in components/, composables/ und utils/ wird automatisch importiert und ist überall verfügbar. Ebenso alle Vue-APIs und die Nuxt-eigenen Composables:

// Kein Import nötig
const route = useRoute()
const { data } = await useFetch('/api/posts')
const count = ref(0)

Das klingt nach einem kleinen Detail — in der Praxis reduziert es den Overhead beim Schreiben neuer Dateien erheblich. Man startet direkt mit der Logik, ohne zuerst eine Handvoll Imports zusammenzustellen.

Datei-basiertes Routing

Nuxt generiert die Router-Konfiguration automatisch aus der Ordnerstruktur unter pages/:

pages/
  index.vue          →  /
  blog/
    index.vue        →  /blog
    [slug].vue       →  /blog/:slug
  [...slug].vue      →  /:slug* (Catch-All)

Verschachtelte Layouts, Middleware, Routen-Guards — alles lässt sich auf Datei-Ebene definieren. Die Route ist das Layout. Man muss keine Router-Instanz manuell konfigurieren.

Nitro: der Server unter der Haube

Nuxt baut auf Nitro, einer eigenständigen Server-Engine, die vollständig von Nuxt entkoppelt ist. Nitro ist:

• Plattform-unabhängig — ein Build läuft auf Node.js, Cloudflare Workers, Vercel Edge, Deno, Bun und mehr
• Universell — derselbe Code wird für SSR, API-Routes und statische Auslieferung verwendet
• Effizient — Code-Splitting, Tree-Shaking und Cold-Start-Optimierungen sind eingebaut

Server-Routes in Nuxt sind nichts anderes als Dateien in server/api/:

// server/api/contact.post.ts
export default defineEventHandler(async (event) => {
  const body = await readBody(event)
  // E-Mail senden, Datenbank schreiben, etc.
  return { success: true }
})

Das Ergebnis ist ein echter API-Endpunkt (POST /api/contact), der direkt neben dem Frontend liegt, in derselben Codebasis, typisiert mit denselben TypeScript-Typen.

Das Modul-Ökosystem

Einer der größten praktischen Vorteile von Nuxt ist das Ökosystem an offiziellen und community-gepflegten Modulen. Statt selbst Integrationen für häufige Anforderungen zu bauen, reicht ein Eintrag in nuxt.config.ts:

• @nuxt/content — Datei-basiertes CMS mit MDC und Collection-Schemas
• @nuxtjs/i18n — Internationalisierung mit SSR-Support und lokalisierten Routen
• @nuxt/image — Automatische Bildoptimierung mit <NuxtImg>
• @nuxt/ui — Komponentenbibliothek auf Basis von Tailwind CSS und Reka UI
• @nuxtjs/seo — SEO-Meta-Tags, Sitemap, robots.txt mit einem Modul

Jedes Modul integriert sich tief in das Nuxt-Build-System — nicht als externe Library, sondern als First-Class-Erweiterung mit eigenen Auto-Imports, Composables und Konfigurationsoptionen.

Wann sollte man Nuxt einsetzen?

Nuxt macht immer dann Sinn, wenn mindestens eines der folgenden zutrifft:

• SEO ist relevant — Content-Seiten, Marketing-Seiten, Blogs, Portfolios
• Performance ist kritisch — Der erste Seitenaufruf muss schnell sein
• Fullstack in einer Codebasis — API-Routes und Frontend ohne separates Backend-Projekt
• Internationalisierung — Lokalisierte Routen und SSR-kompatible Übersetzungen
• Teamgröße wächst — Konventionen über Konfiguration reduziert Onboarding-Overhead

Für reine Single-Page-Apps hinter einem Login — Dashboards, Admin-Panels, interne Tools ohne SEO-Anforderungen — kann ein reines Vue-Projekt die richtigere Wahl sein. Nuxt bringt Build-Komplexität mit, die sich erst auszahlt, wenn man die Features braucht.

Fazit

Nuxt ist kein aufgeblasenes Vue. Es ist Vue mit Meinungen: über Routing, über Rendering, über wie ein Projekt strukturiert sein sollte. Diese Meinungen sind das Produkt von jahrelanger Praxis mit echten Projekten, und sie sind in den allermeisten Fällen die richtigen.

Wer Vue kennt und noch nicht in Nuxt reingeschaut hat, sollte es tun. Nicht für die Features-Liste — sondern um zu sehen, wie viel Overhead bei modernen Web-Projekten einfach verschwindet.