Static Site Generators From Zero: Vokabular, Geschichte und erster Build
Lernen Sie die Begriffe, von denen SSG-Dokumente voraussetzen, dass Sie sie kennen – wie Layouts, Teile und Front Matter zusammenpassen, woher Generatoren stammen und wie man ohne Probleme einen auswählt.
Static Site Generatoren versprechen eine einfache Lösung: Man schreibt Beiträge in Markdown, legt Header und Footer an einem Ort ab und erhält so eine schnelle Website aus einfachen Dateien. Für viele Anfänger stellt sich jedoch die Realität als eine Mauer aus unerklärlichem Jargon, ein Terminal, das Stack-Traces ausgibt, sowie Dokumentation dar, die von jahrelangen Vorkenntnissen ausgeht. Dieser Leitfaden schließt diese Lücke von Grund auf. Sie lernen, welche Fähigkeiten Sie vor dem Start benötigen, was jeder wiederkehrende Begriff in der Generator-Dokumentation tatsächlich bedeutet, wie die Bestandteile eines typischen Eleventy-Projekts zusammenpassen, woher diese Tools stammen und welche leichteren Alternativen es gibt, wenn die beliebten Tools zu aufwendig erscheinen.
Vor dem Auswahl eines Generators: Die zugrundeliegenden Fähigkeiten
Ein Static Site Generator (SSG) ist eine Abstraktionsschicht über den Webseiten. Wenn Sie noch nie eine Webseite von Hand erstellt haben, versteckt diese Abstraktion genau die Dinge, die Sie verstehen müssen, wenn etwas schiefgeht. Für Ihre ersten Websites ist es ein besserer Lernweg, das HTML und CSS selbst zu schreiben. Sie werden die Mühe spüren, dieselbe Navigation in zehn Dateien zu kopieren – und genau diese Mühe sorgt später dafür, dass Sie einen Generator nutzen möchten.
Fast jeder Generator geht stillschweigend davon aus, dass Sie mit HTML und CSS vertraut sind, oft auch ein wenig JavaScript sowie grundlegende Programmierkonzepte wie Variablen und Schleifen, die Kommandozeile und in der Regel Git. Niemand muss all das zunächst beherrschen. Entscheidend ist, dass ein grundlegendes mentales Modell jeder Schicht einen unklaren Build-Fehler in ein lösbares Problem statt in ein Rätsel verwandelt.
Ein Lernpfad mit kostenlosen Ressourcen
Die folgenden Ressourcen funktionieren in etwa in dieser Reihenfolge am besten. Erstellen Sie im Laufe des Prozesses kleine, vorübergehende Websites, anstatt die Liste als Hausaufgabe zu betrachten, die zuerst erledigt werden muss.
- HTML: „HTML for People“ ist für Leser ohne jegliche Programmiererfahrung geschrieben. Wenn Sie mehr über semantische Elemente und Barrierefreiheit erfahren möchten, wenden Sie sich dem MDN-Modul zur Strukturierung von Inhalten zu.
- CSS: Das MDN-Modul zu Grundlagen des Stylings behandelt Konzepte wie das Box-Modell und die Layouts. Falls Ihnen praktische Übungen besser gefallen, führt der freeCodeCamp-Kurs zum responsiven Design durch HTML, CSS, Barrierefreiheit sowie ein responsives (praktisch: mobilfreundliches) Design.
- JavaScript: Das MDN-Modul zum Scripting baut nahtlos auf den Inhalten zu HTML und CSS auf, während das freeCodeCamp-Programm für JavaScript eine interaktive Alternative darstellt.
Falls Sie einen zentralen Überblick statt einer Sammlung bevorzugen, bietet MDNs Lernbereich ein einheitliches Curriculum zu HTML, CSS, JavaScript sowie Grundlagen von Browsern. Weitere Optionen sind web.dev, The Odin Project und w3schools.
Bleiben Sie realistisch: Eine persönliche Website ist in der Regel ein Hobbyprojekt. Unkonventionelle Lösungen und Fehler gehören zum Prozess dazu, und jede fertiggestellte kleine Website verleiht Ihnen neue Fähigkeiten, die Sie in die nächste einbringen können.
Das Vokabular, von dem die static-site-Dokumentation ausgeht
Generator-Dokumentationen verwenden oft Dutzende von Begriffen, als hätten alle diese bereits bei der Geburt gelernt. In diesem Abschnitt werden sie in einfachen Worten definiert und jeder Begriff wird anhand eines kleinen, konkreten Dateis aus einem Eleventy (11ty)-Projekt gezeigt.
Markup, Stil und Verhalten: HTML, CSS und JavaScript
HTML (HyperText Markup Language) beschreibt die Struktur und Bedeutung eines Dokuments: Überschriften, Absätze, Links, Bilder, Listen. Es handelt sich dabei nicht um eine Programmiersprache. HTML kann keine Entscheidungen treffen oder etwas eigenständig wiederholen; es deklariert lediglich, was auf der Seite enthalten ist. Die kleinste nutzbare Seite verfügt über einen Doctype, ein <head> mit Zeichensatz und Titel sowie ein <body> mit Inhalt. Beachten Sie, dass hier nichts Farben oder Schriftarten steuert, weshalb der Browser auf seine Standardstile zurückgreift.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>My First Page</title>
</head>
<body>
<h1>Hello, world!</h1>
<p>This page has a <a href="https://brennan.day">link</a> and a list:</p>
<ul>
<li>HTML gives a page its structure.</li>
<li>There's no CSS yet, so this is all default styling.</li>
</ul>
</body>
</html>Copy
Wenn Sie diesen Inhalt als index.html speichern und in jedem Browser öffnen, erhalten Sie eine funktionierende Webseite – ohne Server erforderlich. Der nach dem Schließtag stehende Copy ist ein Überrest eines Kopieren-Buttons und gehört nicht zum Markup.
CSS (Cascading Style Sheets) bestimmt, wie diese Struktur dargestellt wird: Farben, Abstände, Schriftarten sowie die Anpassung des Layouts an unterschiedliche Bildschirmgrößen. Die untenstehenden Regeln legen eine Serifenschrift fest, begrenzen die Textbreite, damit die Zeilen lesbar bleiben, zentrieren die Spalte mit automatischen Rändern und verleihen der Seite eine warme Hintergrundfarbe sowie dunkle Textfarben. Der Überschrift wird eine eigene Farbregel zugewiesen.
body {
font-family: Georgia, serif;
max-width: 35rem;
margin: 2rem auto;
padding: 0 1rem;
background: #fff2ce;
color: #02005d;
}
h1 {
color: rebeccapurple;
}Copy
Das Einfügen dieser Regeln in ein <style>-Element im <head> der vorherigen Seite verändert ihr Erscheinungsbild, ohne ein einziges Wort im HTML zu ändern. Diese Trennung von Inhalt und Präsentation ist ein Prinzip, das in allen statischen Site-Generatoren gilt.
JavaScript ist die Programmiersprache, mit der Browser arbeiten. Sie ermöglicht bestimmte Funktionen wie Reaktion auf Klicks, Änderung von Inhalten sowie Abruf von Daten. Gleichzeitig ist sie die einfachste Methode, eine einfache Seite unhandlich und langsam zu machen; daher ist es für eine persönliche Website am besten, sie nur dort einzusetzen, wo sie wirklich notwendig ist. Der folgende Codeausschnitt sucht ein Element mit der ID surprise, hört auf Klicks darauf und ersetzt den Text des ersten <h1>-Elements, wenn ein Klick erfolgt.
const button = document.querySelector("#surprise");
button.addEventListener("click", () => {
document.querySelector("h1").textContent = "JavaScript did this!";
});Copy
Damit dies funktioniert, benötigt die Seite ein entsprechendes <button id="surprise">. Ohne dieses gibt querySelector null zurück, und der Aufruf von addEventListener löst einen Fehler aus – das ist ein häufiger erster Fehler.
JavaScript kommt auch auf der Seite des Generators zum Einsatz, nicht nur im Browser. Viele SSGs sind selbst in JavaScript geschrieben und nutzen es zur Ausführung des Builds oder zur Auswertung von Templates. Eleventy ermöglicht sogar, dass ein ganzes Template eine JavaScript-Datei ist: Der Inhalt der Seite wird durch den String bestimmt, den die exportierte Funktion zurückgibt.
// hello.11ty.js
module.exports = function () {
return "<h1>Hello from JavaScript!</h1>";
};Copy
In diesem Beispiel wird CommonJS module.exports verwendet. Neuere Eleventy-Versionen unterstützen außerdem die ES-Module-Syntax (export default); prüfen Sie daher, welchen Stil die Dokumentation für Ihre installierte Version verwendet.
Was „static“, „build“ und „output“ tatsächlich bedeuten
- Statisch beschreibt die Art der Bereitstellung: Der Server übermittelt eine Datei genau so, wie sie gespeichert ist, anstatt für jeden Besucher eine neue Antwort zusammenzustellen. Eine statische Seite kann weiterhin JavaScript enthalten und wird ebenfalls bearbeitet sowie neu bereitgestellt. Damit ist noch nicht gesagt, dass die Seite langweilig oder für immer eingefroren ist.
- Dynamisch bedeutet, dass etwas zur Zeit der Anfrage die Antwort berechnet. Ein klassisches Content-Management-System fragt eine Datenbank ab und erstellt bei jedem Besuch eine neue Seite. Ein Online-Shop ist ein typisches Beispiel, da Bestände und Warenkörbe ständig ändern.
- Ein Statischer Site-Generator ist ein Programm, das Quellmaterial (Markdown-Inhalte, Vorlagen, Konfigurationen, Bilder und andere Ressourcen) liest und eine fertige Sammlung aus HTML-, CSS-, JavaScript- sowie Bilddateien erzeugt, die von jedem statischen Host bereitgestellt werden kann.
_site/, public/ oder dist/. Diese bearbeiten Sie in der Regel nicht manuell, da sie bei der nächsten Build-Ausführung überschrieben werden.localhost:8000 zur Verfügung und baut sie oft automatisch neu auf, sobald Sie eine Quelldatei speichern.Konfigurationsdateien und Site-Daten
- Eine Konfigurationsdatei enthält gesamtsiteweite Einstellungen wie den Site-Name, die Basis-URL, Menüs, das Ausgabeverzeichnis oder Feed-Einstellungen. Namen und Formate unterscheiden sich je nach Tool:
config.yml,hugo.toml,eleventy.config.jsund andere. - YAML ist ein für Menschen leicht verständliches Datenformat, das häufig in Konfigurationen und Front Matter verwendet wird. Es dient zur Darstellung von Zeichenketten, Zahlen, Listen sowie Schlüssel-Wert-Verbindungen. Die Einrückung hat Bedeutung, wodurch bereits ein falsch platziertes Leerzeichen die Kompilierung stören kann.
- Ein Schlüssel-Wert-Paar ist eine Einstellung mit einem Namen und einem Wert, wie zum Beispiel
title: Mein Beitrag. In YAML wird eine Gruppe solcher Paare als Mapping bezeichnet. - Ein Parameter oder Option ist eine Einstellung, die man an ein Kommando übergeben oder in einer Datei speichern kann. Die später vorkommende
--serve-Flagge ist ein Beispiel dafür.
In Eleventy werden die Dateien im Ordner _data zu globalen Daten, die für jedes Template verfügbar sind. Die Datei src/_data/site.json enthält die Informationen, die Besucher sehen: den Namen der Website, eine kurze Beschreibung, den Autor, die öffentliche URL sowie die Sprache.
{
"name": "My Cool Blog",
"description": "Where I write about whatever interests me.",
"author": "Your Name",
"url": "https://example.com",
"language": "en"
}
Jeder Schlüssel wird zu einer Template-Variable. Ein Layout, das {{ site.name }} enthält, gibt den Wert „My Cool Blog“ aus; daher bedeutet das Umbenennen der Website lediglich die Bearbeitung einer Zeile hier, anstatt in jeder Seite nachzusehen. Jekyll speichert ähnliche Informationen in config.yml und Hugo in hugo.toml; die Idee ist identisch, nur die Datei wechselt. Beachten Sie, dass JSON streng ist: Ein Komma am Ende der letzten Eintragung ist ein Syntaxfehler – ein Detail, das später in diesem Leitfaden wichtig wird.
Layouts, Teile und Template-Verarbeitung
- Ein Template ist eine wiederverwendbare Datei, die die Struktur einer Seite definiert und Platzhalter für die sich ändernden Teile enthält.
- Ein Layout ist ein Template für eine ganze Seite: die Sprachdeklaration, der
<head>, der Header, der Hauptinhaltsbereich und der Footer. - Ein Partial ist ein kleiner, wiederverwendbarer Fragment wie eine Navigationsleiste, ein Footer oder ein Block mit Metadaten zu einem Beitrag. Ein Include ist die Anweisung, ein Fragment in eine andere Datei einzubinden.
- Eine Template-Sprache ist die Syntax zur Ausgabe von Variablen, zum Durchlaufen von Daten und zur Entscheidungsfindung innerhalb von Templates. Liquid, Nunjucks und Go-Templates sind gängige Beispiele.
- Eine bedingte Regel ist eine Ja-oder-Nein-Regel in einem Template, zum Beispiel „das Hero-Bild nur anzeigen, wenn der Beitrag eines definiert“.
Die untenstehende Grundstruktur, _includes/layouts/base.njk, ist in Nunjucks geschrieben. Der Titel kombiniert den eigenen Titel der Seite mit dem globalen Namen der Website, zwei include-Tags fügen die Header- und Footer-Teile ein, und der renderierte Seiteninhalt wird innerhalb von <main> ausgegeben.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>{{ title }} | {{ site.name }}</title>
</head>
<body>
{% include "partials/header.njk" %}
<main>
{{ content | safe }}
</main>
{% include "partials/footer.njk" %}
</body>
</html>
Der | safe-Filter ist wichtig. Nunjucks escapet den Ausgabeinhalt standardmäßig, wodurch der HTML-Inhalt des Beitrags in sichtbare Tags umgewandelt würde. Wenn content als sicher markiert wird, signalisiert man dem Engine, dass es sich um vertrauenswürdigen, bereits renderierten HTML-Inhalt handelt. Verwenden Sie dies nur für Inhalt, den Sie kontrollieren.
Die Partials selbst sind lediglich HTML-Fragmente, die Variablen verwenden und weitere Partials einbeziehen können. Der Header verweist mithilfe des Site-Namens auf die Startseite und lädt die Navigation ein; diese besteht aus einer einfachen Liste von Links. Der Footer gibt eine Urheberrechtsangabe zusammen mit dem Autor aus den Site-Daten aus.
<!-- partials/header.njk -->
<header>
<a href="/">{{ site.name }}</a>
{% include "partials/nav.njk" %}
</header>
<!-- partials/nav.njk -->
<nav>
<a href="/">Home</a>
<a href="/archive/">Archive</a>
<a href="/about/">About</a>
</nav>
<!-- partials/footer.njk -->
<footer>
<p>© 2026 {{ site.author }}</p>
</footer>
So verbinden sich die einzelnen Bestandteile. Wenn ein Beitrag in seinem Front Matter layout: base.njk angibt, rendernt Eleventy den Beitrag und platziert das Ergebnis an die Stelle {{ content | safe }} im Layout. Jeder include-Tag wird dabei durch sein entsprechendes Partial ersetzt. Ändert man die Navigation einmal, übernimmt jede Seite der Site diese Änderung beim nächsten Build. Die Beseitigung dieser aufwändigen Kopier- und Einfügearbeiten ist der Hauptgrund für die Existenz von SSGs. Eine kleine Einschränkung: Das Jahr im Footer ist fest codiert, sodass es sich nicht selbst aktualisiert – es sei denn, man ersetzt es durch eine Variable.
Inhaltsdateien, Markdown und Front Matter
- Eine Inhaltsdatei ist eine Quelldatei für eine Seite oder einen Beitrag. Markdown ist das gebräuchlichste Format, doch viele Generatoren akzeptieren auch HTML, reinen Text oder andere Formate.
- Markdown ist eine leichte Markup-Sprache, bei der Satzzeichen für die Struktur stehen:
#für Überschriften, Asteriske zur Hervorhebung, Bindestriche für Listen. Der Generator wandelt es in HTML um. - Front Matter ist ein Metadatenblock ganz oben in einer Inhaltsdatei, meist durch zwei Zeilen mit jeweils drei Bindestrichen abgegrenzt. Er kann einen Titel, ein Datum, Tags, den Layoutnamen oder ein Entwurfsflag enthalten.
- Metadaten sind beschreibende Informationen zu einem Inhaltsteil: Titel, Autor, Veröffentlichungsdatum, Tags, Beschreibung, kanonischer URL oder gewählter Layout.
Die Datei posts/my-first-post.md unten kombiniert all das. Das YAML-Frontmatter legt einen Titel, ein Datum, zwei Tags, eine Layout-Struktur sowie ein Entwurfsflagg setzt. Der Inhalt mischt gewöhnliches Markdown mit Template-Syntax im Nunjucks-Stil, die den Titel ausgibt und bedingungsweise einen Satz anzeigt.
---
title: My First Post
date: 2026-09-22
tags:
- posts
- cats
layout: post.njk
draft: false
---
Welcome to my blog! This paragraph is **Markdown**.
This post is called "{{ title }}".
{% if draft %}
This sentence only appears while the post is a draft.
{% endif %}
Eleventy liest das Front Matter vor dem Rendern von Inhalten. Der Schlüssel layout wählt das Umrahmungstemplate aus, der Tag posts fügt die Datei einer Sammlung namens posts hinzu (über die eine Archivseite iterieren kann), und date bestimmt die Sortierreihenfolge unter Berücksichtigung des Blogs. Alles nach den schließenden Bindestrichen ist der Hauptinhalt. Da draft hier false ist, erscheint der bedingte Satz nicht in der Ausgabe. Beachten Sie, dass der Schlüssel draft in Eleventy keine eingebaute Bedeutung hat; das Ausschließen von Entwürfen aus einer Produktionsversion muss man selbst konfigurieren.
Hosting, Backend-Systeme und Deployment-Begriffe
- Hosting ist der Service oder die Maschine, die Ihre Ausgabedateien speichert und sie im Internet zugänglich macht. Es handelt sich dabei um eine separate Aufgabe im Vergleich zum Schreiben der Website und zur Versionsverwaltung.
Versionskontrolle auf einer Seite
- Versionskontrolle dokumentiert im Laufe der Zeit Änderungen an Dateien, sodass Sie die Historie durchsehen, Versionen vergleichen, zurücksetzen und zusammenarbeiten können.
- Git ist ein bestimmtes Programm zur Versionskontrolle. Es läuft vollständig auf Ihrem Computer und benötigt keinen Online-Service, um die Historie zu verfolgen.
- Ein Repository (Repo) ist ein Projektverzeichnis, dessen Historie Git verwalten wird.
- Ein Commit ist ein gespeichertes Abbild von Änderungen, meist zusammen mit einer Beschreibung dieser Änderungen.
- Ein Remote ist eine weitere Kopie des Repositories, die oft auf Codeberg, GitHub, GitLab oder Ihrem eigenen Server gehostet wird.
- Push sendet Ihre lokalen Commit-Änderungen an einen Remote-Server; Pull holt Commit-Änderungen von einem Remote-Server und fügt sie Ihrer lokalen Kopie hinzu.
- Git-Hosting-Dienste speichern Repositorien und bieten oft Funktionen wie Issue-Tracking, Code-Review sowie automatisierte Builds. Sie sind praktisch, aber sie stellen nicht Git selbst dar – Git funktioniert auch ohne sie einwandfrei.
Durch das Veröffentlichen eines neuen Beitrags mit Git über die Terminalzeile sind vier Befehle erforderlich. Der erste wird pro Projekt nur einmal ausgeführt; die anderen drei bilden den täglichen Ablauf, bei dem ein Datei in einen Staging-Zustand gebracht, ein Snapshot erstellt und an den Remote-Server gesendet wird.
git init # turn this folder into a repository (once)
git add posts/new-post.md # stage the file for your next commit
git commit -m "Add new post" # save a snapshot with a message
git push # copy your commits to the remoteCopy
In der Praxis funktioniert git push nur nachdem ein Remote-Repository konfiguriert wurde, beispielsweise mit git remote add origin <url>, und der erste Push einer Branch erfordert in der Regel git push -u origin main oder Ähnliches. Sobald das eingerichtet ist, reicht ein einfacher git push aus.
Ursprung der statischen Site-Generatoren
Sobald das notwendige Vokabular vorhanden ist, wird die Entwicklungsgeschichte verständlicher, denn jede neue Generation von Tools fügte eines der oben genannten Konzepte hinzu.
Die Trennung von Inhaltserstellung und Markup existiert bereits lange vor dem Begriff „statischer Site-Generator“. HSC, abgekürzt für „HTML Sucks Completely“, war ein HTML-Präprozessor, der 1996 von Thomas Aglassinger veröffentlicht wurde. Er bot bereits Include-Funktionen, bedingte Anweisungen sowie Link-Validierung – etwa ein Jahrzehnt bevor diese Kategorie überhaupt einen Namen hatte.
Von Ende der 1990er bis in die 2000er Jahre wählten die meisten Menschen, die einen Blog haben wollten, gehostete, dynamische Dienste wie Blogger, LiveJournal oder Open Diary oder installierten datenbankbasierte Software wie WordPress. Movable Type, eine von Ben und Mena Trott im Jahr 2001 entwickelte Perl-Plattform, ging einen anderen Weg: Jedes Mal, wenn man über seine Web-Oberfläche etwas veröffentlichte, wurde der Blog in reine statische HTML-Dateien umgewandelt. Die Nutzer berührten nie eine Terminal, dennoch erhielten die Leser statische Seiten. Dadurch konnten auch diejenigen von den Vorteilen der statischen Ausgabe profitieren, die niemals einen Build-Befehl eingeben würden.
Nanoc wurde im Jahr 2007 von Denis Defreyne entwickelt, nachdem sich Ruby-basierte Content-Management-Systeme auf seinem 96 MB großen virtuellen Server als viel zu langsam erwiesen hatten. Es führte Layouts, Metadaten pro Seite, Markdown-Unterstützung sowie Plugins ein. Im Dezember 2008 veröffentlichte Tom Preston-Werner, Mitbegründer von GitHub, Jekyll – aus Unzufriedenheit mit leistungsintensiven Blogging-Engines. Jekyll baute auf den Ideen von Nanoc auf und brachte zwei entscheidende Merkmale mit: YAML-Frontmatter am Anfang jeder Inhaltsdatei sowie eine integrierte Blogfunktion, sodass ein Ordner mit Markdown-Dateien ohne zusätzliche Einrichtung bereits zu einem Blog wurde. GitHub Pages wurde gleichzeitig als kostenlose statische Hosting-Lösung eingeführt, und diese Kombination trug mehr als alles andere dazu bei, SSGs zum Mainstream zu machen.
Seitdem ist fast alles eine Neuinterpretation desselben Musters in anderen Sprachen. Octopress, das mittlerweile nicht mehr verfügbar ist, sowie Middleman setzten die Ruby-Reihe fort. Pelican basiert auf Python, und Hyde baut auf Laravel auf.
Im Juli 2013 folgte Steve Francia mit Hugo, einem in Go geschriebenen Programm, das als einziges kompiliertes Binärdatei verteilt wird. Im Vergleich zu Jekyll musste kein Ruby-Umfeld installiert werden, und es gab keine gem-Versionen zu koordinieren. Zudem war seine Build-Geschwindigkeit – bereits bei Websites mit Tausenden von Seiten in Sekunden gemessen – sein Alleinstellungsmerkmal.
Gegen Ende des Jahres 2017 veröffentlichte Zach Leatherman Eleventy (11ty), eine flexible Alternative zu Jekyll, die auf JavaScript läuft und über npm installiert wird. Jekyll bindet den Benutzer an Liquid; Eleventy unterstützt eine lange Liste von Template-Formaten:
- Markup und Inhalt: reines HTML (
.html), Markdown (.md) und MDX (.mdx)
.11ty.js-Dateien, TypeScript (.ts), JSX (.jsx) und WebC (.webc).njk), Handlebars (.hbs), Mustache, EJS, Haml und Pug.scss) geschrieben sindEinige dieser Formate erfordern einen Plugin oder zusätzliche Konfiguration, um ohne Anpassungen zu funktionieren; prüfen Sie daher vor der Verwendung die aktuellen Eleventy-Dokumentationen. Wenn Sie bereits eine bestimmte Programmiersprache kennen, ermöglicht das Verzeichnis der Generatoren auf Jamstack.org es Ihnen, nach Tools zu filtern, die in dieser Sprache geschrieben sind.
Viele Generatoren in diesem Verzeichnis haben seit Jahren keine neue Version mehr erhalten, was für eine private Website oft akzeptabel ist. Eine statische Website stellt den Besuchern keinen Serverseitencodex oder Datenbank zur Verfügung, wodurch die häufigsten Angriffsflächen dynamischer Blogs beseitigt werden. Falls eine neue Version Ihres Generators Funktionen beinhaltet, die Ihnen nicht gefallen, können Sie weiterhin die alte Version verwenden – sie wird weiterhin dieselbe Website erzeugen. Die Einschränkung ist jedoch, dass „keine Updates“ nicht gleichbedeutend mit „kein Risiko“ ist: Die zur Kompilierung verwendeten Abhängigkeiten, der Rechner, auf dem die Kompilierung stattfindet, sowie jegliches eingebettete Drittanbieter-JavaScript erfordern weiterhin Aufmerksamkeit. Ein ungewartetes Tool kann schließlich auf neueren Betriebssystemen oder Sprachläufen nicht mehr ordnungsgemäß installiert werden.
Git löst zwei Probleme – Sie benötigen keines davon
Anfängerleitfäden raten fast immer dazu, Git zu verwenden. Ein Grund dafür ist einfach die Gewohnheit bei Entwicklern, doch ein anderer Aspekt hat historische Wurzeln: Jekyll, das erste weithin verbreitete SSG, entstand ursprünglich als GitHub-Projekt. Die Verwaltung auf GitHub, Codeberg oder GitLab beantwortet die Frage „Wo befinden sich meine Dateien?“ mit „im Repository“. Dienste wie Neocities oder Nekoweb beantworten sie anders: Man lädt die Dateien über die Website hoch.
Auf git-basierten Hosting-Diensten wie Codeberg Pages oder GitLab Pages werden selbst Änderungen, die über die Web-Oberfläche vorgenommen werden, im Hintergrund zu Commits und Pushes. Man verwendet Git – unabhängig davon, ob man jemals eine Git-Kommando eintippt oder nicht.
Falls Sie die Website selbst hosten, befinden sich die Dateien auf Ihrem eigenen Rechner, typischerweise in einem Verzeichnis wie /var/www/html unter Linux. Auf einem gemeinsam genutzten Server wie einem Tildeverse-Server liegen sie im öffentlichen Ordner Ihres Kontos; ein gängiger Ablauf ist es, lokal zu bauen und rsync zur Kopie des Ergebnisses auf den gemeinsam genutzten Rechner zu verwenden, wo es automatisch bereitgestellt wird.
In solchen Konfigurationen hilft es, die beiden Aufgaben zu unterscheiden, die Git erledigt:
- die Aufrechterhaltung einer Versionshistorie, damit Sie eine fehlerhafte Bearbeitung rückgängig machen und sehen können, was und wann geändert wurde
- das Übertragen der gebauten Dateien an den Ort, von dem aus sie bereitgestellt werden
Niemand der beiden Aufgaben erfordert ausdrücklich Git. rsync, ein FTP-Client oder ein Upload-Formular im Browser reichen völlig aus, um eine Website zu veröffentlichen, und gewöhnliche Backups können bei kleinen persönlichen Projekten als Historie dienen. Git ist beliebt, weil es beide Aufgaben gleichzeitig erledigen kann, kostenlos ist und sich mit kostenloser Hosting-Lösungen verbinden lässt – wodurch es eher der einfachste Weg ist als eine Notwendigkeit.
Der Unterschied zwischen dem übersichtlichen Diagramm und der tatsächlichen Umsetzung
Auf dem Papier ist die Architektur eines Blog-Generators fast schon langweilig ordentlich:
- Die Beiträge sind Markdown-Dateien in der
posts/-Ordner - Ein Template im
layout/-Ordner rendernt sie - Dieses Template setzt HTML-Fragmente aus
partials/, wieheader.htmlundfooter.html, zusammen
config.yml (oder ein äquivalentes Dateiformat) im Projektverzeichnis enthält projektweite Parameter wie Namen oder Farben"2024-03-14-my-post-title.md" einzubettenDer Teil, den das Diagramm weglässt, sind die dahinterstehenden Mechanismen. Um diese Verzeichnisse in eine bereitgestellte Website – sagen wir im Verzeichnis _site/ – umzuwandeln, ist ein Programmiersprachen-Runtime erforderlich, der den Generator ausführt, und jeder Schritt in dieser Kette kann zum Ausfallpunkt werden.
Mainstream-Tools versuchen, dies hinter einem Befehl zu verbergen, wie zum Beispiel hugo build oder npx @11ty/eleventy --serve. Die Option --serve im Eleventy-Befehl startet einen lokalen Entwicklungsserver und rebuildet den Inhalt jedes Mal, wenn Sie eine Quelldatei speichern, anstatt nur einmal zu bauen und danach abzuschließen. Genau dieser schnelle Rückkopplungsschleifen sorgt dafür, dass das Bearbeiten einer statischen Website fast genauso sofortig wirkt wie das Bearbeiten einer Live-Seite.
Deployment-Plattformen erweitern diese Idee auf die Cloud. Netlify oder das selbsthostbare Coolify führen Ihre Kompilierung auf einem entfernten Rechner durch, erkennen heraus, welchen Generator Sie verwenden, führen den entsprechenden Befehl aus und veröffentlichen das Ausgabeverzeichnis unter einer Adresse wie yoursitename.netlify.app. Konzeptionell ist das dasselbe wie das Hochladen von manuell erstelltem HTML auf Neocities und das Erhalten von yoursitename.neocities.org, nur dass die Kompilierung auf deren Rechner stattfindet. Ähnliche Arbeitsabläufe werden von surge.sh, GitHub Pages, Vercel sowie Cloudflares Pages-Produkt angeboten; welche Option am besten passt, hängt davon ab, wie sehr Sie Bequemlichkeit gegenüber Unabhängigkeit von großen Plattformen schätzen. Wenn Sie einen vollständigen Deployment-Workflow von Anfang bis Ende sehen möchten, behandelt unser Leitfaden zu dem Hochladen einer kleinen Website auf Cloudflare einen konkreten Fall.
Warum ein einzelner Komma am Ende alles ruinieren kann
Jede dieser Bequemlichkeiten beruht auf Annahmen: Ihre Dateien sind korrekt, die Sprachlaufzeit ist sauber installiert und Sie sind mit der Terminalnutzung vertraut. Entwickler überschätzen regelmäßig, wie verbreitet diese letzte Fähigkeit tatsächlich ist – ein Blindpunkt, den dieses XKCD-Comic sehr gut darstellt.
Auch der Build ist anfällig. Ein kleiner Syntaxfehler in einer wichtigen Datei, so unbedeutend er auch sein mag wie ein zusätzliches Komma, kann die Installation oder den gesamten Build stoppen. Noch schlimmer ist, dass die Fehlermeldung in der Regel vom zugrunde liegenden Laufzeitumfeld oder Parser stammt und nicht vom Generator, weshalb sie in Begriffen der Programmiersprache statt in Bezug auf Ihre Website formuliert ist. Ein realistisches Beispiel: Eine JSON-Datendatei mit einem Komma am Ende nach der letzten Eigenschaft verursacht bei einem Netlify-Build einen Fehler mit einer Parser-Stacktrace, in der die eigentliche Datei in unerfahrenenkreisen verständlichen Begriffen nie erwähnt wird.
Angesichts einer solchen Ausgabe entscheiden sich viele Menschen zu Recht dafür, HTML von Hand zu schreiben, auf ein gehostetes CMS umzusteigen oder ganz auf die Erstellung einer Website zu verzichten. Das letzte Ergebnis ist der eigentliche Verlust. Einige Gewohnheiten verringern die Wahrscheinlichkeit, dorthin zu gelangen:
- Führen Sie vor dem Hochladen den Build lokal mit dem Entwicklungsserver aus, damit Fehler zunächst auf Ihrem eigenen Bildschirm sichtbar werden
- Ändern Sie immer nur eine Sache, damit die neueste Änderung der offensichtliche Verdächtige ist, wenn etwas nicht funktioniert
- Lesen Sie den Fehler von unten nach oben und suchen Sie nach einem Dateinamen sowie einer Zeilennummer – das ist in der Regel der eigentliche Hinweis
- Validieren Sie JSON und YAML mit einer Editor-Erweiterung oder einem Linter, da diese Formate einen großen Anteil an Fehlern bei Anfängern verursachen
- Führen Sie häufig Commit-Vorgänge von funktionsfähigen Zuständen durch, damit Sie jederzeit zur letzten funktionierenden Version zurückkehren können
Lernen durch Anpassung eines Starter-Projekts
Eine bewährte Methode, einen Generator zu erlernen, besteht darin, ein fertiges Starter- oder Theme zu verwenden, damit anzufangen und es dann Stück für Stück zu ändern, bis man jede Datei versteht. Schließlich weiß man genug, um selbst von Grund auf einen zu erstellen. Gute Starter für diesen Zweck weisen einige Eigenschaften auf: klare Dokumentation, eine geringe Anzahl an Dateien sowie einen eindeutigen Ort für Inhalte und Einstellungen. Typische Beispiele sehen so aus:
- ein Hugo-Starterset, bei dem die Beiträge in
/postabgelegt werden und die Anpassung der Seite inhugo.tomlerfolgt, optional mit IndieWeb-Funktionen wie Microformats2 sowie einer vorgefertigten h-Card - ein Eleventy-Starterset, bei dem die Beiträge in
/postsliegen und die Details der Seite in einer Datendatei wiesite.jsgespeichert sind - ein Jekyll-Starterset, bei dem die Beiträge in
/_postsabgelegt werden und die Einstellungen in_config.ymlzu finden sind
Absichtlich schlichte Starter sind ein Vorteil beim Lernen. Wenn die Gestaltung minimal ist, fällt die Struktur leicht auf, und alle Designarbeiten müssen von Ihnen selbst erledigt werden.
Kleine Generatoren mit fast keinen beweglichen Teilen
Hugo, Eleventy und Jekyll sind die beliebten Optionen, doch es gibt eine ganze Familie sehr kleiner Generatoren für Menschen, die das gesamte Tool an einem Nachmittag verstehen möchten.
- barf, abgekürzt für „ Blogs sind wirklich lustig“, ist ein etwa 170 Zeilen langes Shell-Skript von btxx, das von Karl Bartels blog.sh abgeleitet wurde. Es verfügt weder über Vorlagen noch über ein Template-System. Man erstellt Markdown-Dateien, führt
make buildaus und lädt den entstehendenbuild/-Ordner mit rsync hoch. RSS-Feeds werden automatisch generiert, das Skript funktioniert nativ unter OpenBSD, macOS und Linux, und seine Stylesheet umfasst nur vier Zeilen. Die README-Datei sowie eine Live-Demo zeigen, wie das Endergebnis aussieht.
bb.sh, mit etwa 1.000 Zeilen, das keine Abhängigkeiten außerhalb von Standard-Unix-Utilities wie date, grep, sed und head benötigt. Carlos Fenollosa schrieb die erste Version im Jahr 2011 und erklärte damals in einem Blogbeitrag den Ansatz; es wurde auch zum Zeitpunkt der Niederschrift weiterhin gepflegt. Sobald bb.sh im öffentlichen Verzeichnis Ihres Servers liegt, eröffnet ./bb.sh post einen neuen Eintrag. Entwürfe, Tags, Markdown und RSS funktionieren ohne jegliche Installationsschritte. Eine Community-Fork-Version namens bashblog-ng fügt weitere Funktionen hinzu.Noch ein paar Punkte, die man wissen sollte:
- ssg ist ein POSIX-konformes Shell-Skript von Roman Zolotarev, das mehrere Tools in dieser Liste inspiriert hat; pyssg ist eine in Python umgeschriebene Version davon.
- sw, geschrieben in C, ist ein bewusst minimalistisches Web-Framework, und seine Fork simple-static reduziert es noch weiter auf das, was in der README als der einfachste statische Site-Generator beschrieben wird, den sein Betreuer sich vorstellen kann.
- makesite.py ist das Python-Äquivalent zu barf und bashblog, besteht aus weniger als 130 Zeilen und wurde von Sunaina Pai unter dem Prinzip entwickelt, dass der Code selbst die Dokumentation darstellt. Es gibt keine Konfigurationsschicht; man liest den Script und editiert es direkt.
Niemand von diesen nähert sich dem Funktionsumfang von Hugo oder Eleventy an – und genau das ist der Sinn. Was sie in Form von Plugins und Template-Formaten opfern, ersetzen sie durch Transparenz: Wenn etwas nicht funktioniert, passt das gesamte Programm auf Ihren Bildschirm.
Falls Sie bereit sind, völlig aus dem Web herauszutreten, ist das Veröffentlichen über das Gemini-Protokoll eine weitere Option. Gemini-Seiten verwenden ein einfaches Textformat, das unverändert bereitgestellt wird, sodass oft überhaupt nichts generiert werden muss.
Kernpunkte
- Lernen Sie zunächst, eine Seite von Hand zu schreiben; ein Generator automatisiert nur Wiederholungen, die Sie bereits erkennen sollten.
- Die größte Verwirrung bei SSG rührt meist vom Vokabular her. Sobald Quelle, Ausgabe, Erstellung, Layout, Partials und Front Matter klar sind, liest sich die Dokumentation jeder Tool ähnlich.
- Layouts, Partials und globale Datendateien dienen dazu, dass eine einmal vorgenommene Änderung bei der nächsten Erstellung überall sichtbar wird.
- Git bietet eine Historie sowie einen Veröffentlichungsweg, doch rsync, FTP oder ein Upload über den Browser sind ebenfalls legitime Alternativen für eine persönliche Website.