Diese Seite ist von außen betrachtet eine ganz normale statische Webseite: HTML, ein Stylesheet, ein wenig JavaScript. Kein Server, der etwas zusammenbaut, keine Datenbank, kein Redaktionssystem. Genau so wollte ich es haben.

Was sich geändert hat, ist die Art, wie dieses HTML entsteht. Ich schreibe es nicht mehr selbst, sondern lasse es von Jekyll erzeugen. Der Grund ist einfach: Reine HTML-Seiten sind angenehm zu starten und mühsam zu pflegen.

Das Problem beginnt bei der Navigation

Solange eine Seite aus drei Dateien besteht, ist alles gut. Man kopiert den Kopfbereich, passt den Titel an, fertig.

Dann kommt die vierte Seite dazu. Und die fünfte. Irgendwann kommt ein neuer Eintrag in die Navigationsleiste, und in diesem Moment merkt man, was man sich eingehandelt hat: Die Navigation steht nicht an einer Stelle, sie steht in jeder einzelnen Datei. Ein neuer Menüpunkt bedeutet, dass man ihn zwölfmal einfügt. Zwölfmal an der richtigen Stelle, zwölfmal mit der richtigen Einrückung, zwölfmal ohne Tippfehler.

Und es bleibt nicht bei der Navigation. Der Fußbereich mit Impressum und Datenschutz steht überall. Die Metadaten im Kopf stehen überall. Die Versionsnummer steht überall. Jede dieser Kopien ist eine Stelle, die beim nächsten Mal vergessen werden kann, und genau eine vergessene Stelle fällt niemandem auf, bis sie jemandem auffällt.

Das ist keine Frage von Disziplin. Man kann sehr diszipliniert sein und trotzdem eine Datei übersehen.

Drei Dinge, die Jekyll besser macht

1. Gemeinsame Bestandteile liegen an einer Stelle

Navigationsleiste, Fußbereich und Kopfbereich sind bei mir drei Dateien in einem Ordner namens _includes. Jede Seite bindet sie ein, statt sie zu kopieren. Ein neuer Menüpunkt ist eine Änderung in einer Datei, und beim nächsten Bau steht er auf allen Seiten.

Dasselbe gilt für die Struktur ringsherum. Ein Layout legt fest, wie eine Seite aufgebaut ist, und die einzelne Seite steuert nur noch ihren Inhalt bei. Wenn ich die Grundstruktur ändere, ändere ich sie einmal.

Der Effekt ist nicht nur weniger Arbeit. Der Effekt ist, dass Abweichungen gar nicht erst entstehen können, weil es nichts mehr gibt, wovon abgewichen werden könnte.

2. Inhalt und Darstellung sind getrennt

Ein Blogbeitrag ist bei mir eine Markdown-Datei mit ein paar Zeilen Vorspann: Titel, Datum, Kategorien, Schlagwörter. Mehr nicht. Kein <article>, kein <div class="...">, keine Verlinkung in einer Übersichtsseite, die ich von Hand ergänzen müsste.

Beim Bau entsteht daraus die fertige Seite, und mit ihr eine ganze Reihe von Dingen, die ich sonst selbst pflegen müsste: die Blogübersicht, die Archive nach Kategorien und Schlagwörtern, der RSS-Feed, die Sitemap. Ein neuer Beitrag ist eine neue Datei. Nichts anderes muss angefasst werden.

Beim Schreiben denke ich damit über Text nach und nicht über Auszeichnung. Das klingt nach einer Kleinigkeit, aber es ist der Unterschied zwischen “ich schreibe kurz etwas auf” und “ich mache mich an die Webseite”.

3. Was einmal festgelegt ist, gilt überall

Die Versionsnummer im Fußbereich steht in genau einer Zeile in der Konfigurationsdatei. Der Fußbereich holt sie sich von dort. Bei einem Release ändere ich eine Zahl, nicht dreißig.

Nach demselben Muster funktionieren auch die Daten der kleinen Web-Apps: Name, Farbe, Symbol, Beschreibung liegen in einer strukturierten Datei, und die Seiten bedienen sich daraus. Eine neue App bedeutet einen neuen Eintrag, keine neue Kopie.

Und das Ergebnis bleibt trotzdem, was es vorher war: fertiges HTML in einem Ordner, das ich auf den Webserver lege. Der Aufwand steckt im Bau, nicht im Betrieb. Der Besucher bekommt eine statische Seite, schnell und ohne bewegliche Teile, und ich bekomme eine Quelle, in der ich Änderungen an einer Stelle mache.

Was es nicht besser macht

Ehrlicherweise: Jekyll ist nicht umsonst zu haben. Es kommt eine Werkzeugkette dazu, die installiert und gelegentlich aktualisiert werden will. Man kann eine Datei nicht mehr einfach im Browser öffnen, sondern braucht einen lokalen Server für die Vorschau. Und man muss ein paar Konzepte lernen, bevor man sie nutzen kann.

Für eine Seite mit drei Unterseiten lohnt sich das nicht. Für eine Seite mit einem Blog, mehreren Werkzeugen und dem Anspruch, dass Kopf und Fuß überall gleich aussehen, hat sich der Einstieg nach dem ersten Umbau bezahlt gemacht.

Der Punkt ist nicht, dass Jekyll etwas kann, was HTML nicht kann. Am Ende steht in beiden Fällen dasselbe HTML. Der Punkt ist, dass ich es nicht mehr dreißigmal pflegen muss.