Zum Inhalt springen

Künstliche Intelligenz verändert digitale Produkte. Nutzen Sie die Chancen für Ihr Unternehmen.

Zurück zum Blog
Dominik Weber

Nuxt 4: Warum wir es als Standard-Framework gewählt haben

Next.js, Astro, SvelteKit oder Nuxt 4? Wir erklären verständlich, warum wir meist Nuxt 4 einsetzen — und wann eine andere technische Grundlage besser passt.

Dominik WeberAI-first Einblicke

Die Wahl des technischen Grundgerüsts (Framework) entscheidet über mehr als die eingesetzten Technologien. Sie bestimmt, wie schnell ein Projekt live geht, was die Wartung in drei Jahren kostet und ob die Website bei Google eine Chance hat. Wir haben in Kundenprojekten mit Next.js, Astro, SvelteKit und Nuxt gearbeitet. Seit 2025 ist Nuxt 4 unser Standard, und zwar aus Gründen, die sich in Rechnungen und Rankings messen lassen, nicht in GitHub-Sternen.

Seitenerzeugung: pro Route entscheiden statt pro Projekt

Der praktische Vorteil von Nuxt 4 ist die flexible Seitenerzeugung, in der Fachsprache hybrides Rendering genannt. Über routeRules legt eine einzige Konfigurationszeile fest, ob eine Seite vorab erzeugt, bei einem Aufruf auf dem Server erzeugt oder zwischengespeichert wird:

routeRules: {
  '/': { prerender: true },
  '/blog/**': { swr: 3600 },
  '/api/**': { cors: true }
}

Marketing-Seiten kommen als fertiger Seitenquelltext (statisches HTML) in Millisekunden, der Blog wird stündlich neu zwischengespeichert, dynamische Bereiche werden weiterhin auf dem Server erzeugt. Bei anderen Frameworks ist so ein Mix möglich, aber über Erweiterungen, Zwischenschichten und Einstellungen für die Veröffentlichung verteilt. In Nuxt steht er an einer Stelle und jeder im Team versteht ihn.

Suchmaschinenoptimierung (SEO) ist eingebaut, nicht angeschraubt

Suchmaschinen bewerten, was im ausgelieferten Seitenquelltext steht. Webanwendungen, die Inhalte erst im Browser nachladen, starten deshalb ohne Server-Erzeugung mit einem Nachteil. Nuxt erzeugt Seiten auf dem Server, und das SEO-Modul erledigt die Pflichtarbeit gleich mit: Sitemap, Regeln für Suchmaschinen (robots.txt), bevorzugte Seitenadressen (Canonical-URLs), Vorschauinformationen für soziale Netzwerke (Open-Graph-Tags) und strukturierte Daten nach Schema.org kommen aus einer Konfiguration statt aus handgepflegten Metadaten.

Diese Website hier ist das Beispiel: zweisprachig mit korrekten Verweisen zwischen den Sprachversionen (hreflang), strukturierten Daten auf jeder Seite und Blog-Beiträgen, die automatisch in der Sitemap erscheinen. Der Aufwand dafür lag bei Stunden, nicht Tagen. Wie viel Suchmaschinenoptimierung kosten darf und was sie bringt, haben wir in unserer SEO-Kostenübersicht aufgeschlüsselt.

Gute Entwicklungsabläufe helfen auch der künstlichen Intelligenz

Automatische Importe, eine Seitenstruktur anhand von Dateien und TypeScript ohne aufwendige Einrichtung: Das macht menschliche Entwickler schneller. Es macht aber auch Werkzeuge mit künstlicher Intelligenz (AI) besser. Nuxt-Konventionen sind so eindeutig, dass Claude und vergleichbare Modelle Komponenten, wiederverwendbare Logikbausteine und Server-Routen in der korrekten Projektstruktur erzeugen, ohne dass wir die Ordnerlogik erklären müssen. Konvention schlägt Konfiguration, für Menschen wie für Maschinen.

Dazu kommt die Komponentenbibliothek Nuxt UI: barrierefreie, produktionsreife Bausteine auf Basis des Designsystems Tailwind. Ein Formular mit Eingabeprüfung, ein Dialogfenster oder eine Tabelle mit Sortierung – das sind bei uns Minuten, keine Nachmittage. In Summe ist das der Kern unseres Versprechens, Websites deutlich schneller und günstiger zu bauen als klassische Teams.

Und die Alternativen?

Kurz und ehrlich:

  • Next.js ist technisch ebenbürtig, aber das App-Router-Ökosystem wechselt seine Best Practices schneller, als Projekte alt werden. Für Teams, die tief im React-Umfeld stecken, trotzdem eine gute Wahl.
  • Astro glänzt bei reinen Content-Seiten. Sobald echte App-Funktionalität dazukommt, wächst der Kleber-Code.
  • SvelteKit ist elegant, hat aber den kleinsten Talent-Pool. Für Kundenprojekte, die später andere Teams warten, ein reales Risiko.

Wann wir Nuxt nicht einsetzen

Ein Framework-Standard ist kein Dogma. Bei Anforderungen großer Unternehmen mit komplexen Redaktionsabläufen, fein abgestuften Rechten und Dutzenden Redakteuren bleibt TYPO3 unsere Empfehlung, oft kombiniert mit Nuxt als Frontend über eine Programmierschnittstelle für Inhalte (Content-API). Und für eine Landingpage, die sich nie ändert, braucht niemand einen Node.js-Server.

Das Werkzeug folgt dem Projekt. Aber wenn das Projekt eine moderne, mehrsprachige, suchmaschinenrelevante Website oder Web-App ist, führt für uns aktuell kein Weg an Nuxt 4 vorbei. Welche Bausteine wir sonst einsetzen, steht in unserem Frontend-Stack.