Hugo vs. Next.js – wann reicht Static Site Generation?

Jedes Mal, wenn ich jemandem sage, dass dieser Blog mit Hugo gebaut ist, kommt dieselbe Frage: „Warum nicht Next.js?" Die Antwort ist nicht „weil Hugo besser ist" – sondern weil es auf das Projekt ankommt. Und dieser Unterschied wird erstaunlich oft ignoriert.

Hier ist meine ehrliche Einschätzung nach Projekten mit beiden Tools.

Erstmal: Was macht eigentlich was?

Hugo ist ein Static Site Generator. Du gibst ihm Markdown-Dateien und Templates, er baut daraus HTML. Das war’s. Kein JavaScript-Runtime, kein Node.js auf dem Server, keine Datenbank. Das fertige Ergebnis ist ein Ordner voller HTML-Dateien, den du einfach irgendwo hochlädst.

Next.js ist ein React-Framework. Es kann statische Seiten generieren (Static Site Generation, kurz SSG), aber auch Seiten dynamisch auf dem Server rendern (Server-Side Rendering), API-Routen bereitstellen, Authentifizierung verwalten und vieles mehr. Es lebt in der Node.js-Welt.

Hugo:    Markdown + Templates → HTML-Dateien → fertig
Next.js: React-Komponenten → SSG/SSR/ISR + API → Node.js-Server

Das ist kein qualitativer Unterschied – es ist ein Unterschied im Anwendungsfall.

Wann Hugo die richtige Wahl ist

Hugo ist schnell. Wirklich schnell. Tausend Seiten in unter einer Sekunde gebaut – das ist kein Marketing, das ist die Realität. Und für bestimmte Projekte ist das genau das, was man braucht.

Blogs und Portfolio-Seiten – Content ändert sich selten, braucht keine Benutzeranmeldung, keine personalisierten Inhalte. Hugo baut die Seite einmal, der Browser lädt statisches HTML. Keine Cold Starts, kein JavaScript-Bundle das der Browser erst auspacken muss.

Dokumentation – Libraries, Open-Source-Projekte, technische Handbücher. Markdown rein, strukturiertes HTML raus. Hugo’s Template-System ist dafür gemacht.

Landing Pages und kleine Unternehmenswebseiten – Wenn die „Dynamik" sich auf ein Kontaktformular beschränkt (das man prima mit einem externen Service oder einem PHP-Script löst), ist ein React-Framework Overkill.

Faustregel:
Gibt es Benutzerkonten? → Nein → Hugo prüfen
Gibt es personalisierte Inhalte? → Nein → Hugo prüfen
Gibt es häufig wechselnde Daten aus einer DB? → Nein → Hugo prüfen

Wann Next.js die richtige Wahl ist

Next.js macht erst dann Sinn, wenn statisches HTML nicht mehr ausreicht.

Authentifizierung – Geschützte Seiten, die nur eingeloggten Nutzern zugänglich sind. Hugo kann das nicht – er kennt keine Nutzer.

Personalisierte Inhalte – Ein Dashboard, ein Feed, der sich nach Benutzerverhalten richtet. Das erfordert zur Laufzeit Entscheidungen, die Hugo zur Build-Zeit nicht treffen kann.

Häufig wechselnde Daten – Wenn Preise, Lagerbestände oder Live-Daten auf der Seite erscheinen sollen. Natürlich kann Hugo bei jedem Push neu bauen, aber bei tausenden Produkten mit stündlichen Änderungen stößt das an Grenzen.

API-Routen – Wenn das Backend direkt im selben Projekt leben soll. Next.js erlaubt /app/api/route.ts – ein vollwertiger API-Endpunkt, der in der Cloud-Funktion läuft.

Der Hybrid-Fall: Next.js als Static Site Generator

Next.js kann auch rein statisch ausgespielt werden – output: 'export' in der Config, und du bekommst dasselbe HTML-Bundle wie von Hugo. Warum also dann überhaupt Hugo?

Weil Hugo für Content-fokussierte Sites einfach angenehmer ist:

• Markdown mit TOML-Frontmatter statt MDX
• Taxonomien (Tags, Kategorien) out of the box
• Kein node_modules, kein Build-Setup, kein JavaScript-Toolchain
• Ein Binary, das überall läuft

Next.js als reiner Static Generator fühlt sich an wie ein Sportwagen zum Einkaufen fahren. Es funktioniert – aber es bringt auch alle Komplexität eines Sportwagens mit.

Ein konkreter Vergleich: Dieser Blog

Dieser Blog hat:

• Artikel in Markdown
• Tags und Kategorien
• Eine Kontaktseite mit Formular
• Projekte-Portfolio
• Code-Demos mit Live-Vorschau

Kein Login, keine personalisierten Inhalte, keine Datenbank. Hugo baut alles in unter einer Sekunde. Das Formular läuft über ein PHP-Script auf dem Server. Die Code-Demos sind iFrames mit Base64-encoded Snippet-Inhalten aus dem Frontmatter.

Mit Next.js wäre das machbar gewesen – aber ich hätte React-Komponenten statt Templates geschrieben, einen Node-Server oder Vercel benötigt, und das für eine Seite, die sich selten ändert.

Die ehrliche Antwort

Die Frage „Hugo oder Next.js?" ist oft die falsche Frage. Die richtige lautet:

Brauche ich eine Webanwendung – oder eine Website?

Eine Website zeigt Inhalte. Eine Webanwendung verarbeitet sie, reagiert auf Nutzeraktionen, speichert Zustände.

Hugo baut Websites. Next.js baut (auch) Webanwendungen.

Für die meisten Blogs, Portfolios und Marketing-Seiten da draußen ist Hugo die einfachere, schnellere und wartungsärmere Wahl. Und manchmal ist einfacher das Beste, was ein Werkzeug sein kann.