Websites sind Dateien

Der zehnte und letzte Teil des Boring Stack. Die ersten neun handelten von Apps. Dieser handelt vom einfacheren Fall: Websites wie einem Blog, einer Kampagnenseite oder einer Infoseite für einen Verein.

Sie brauchen kein Backend. Also bekommen sie keines.

Einmal erzeugt, als Dateien ausgeliefert

Hugo ist ein Static Site Generator. Er nimmt Markdown-Dateien, Templates und eine Konfigurationsdatei und erzeugt einen Ordner mit einfachem HTML, CSS und Bildern. Dieser Ordner ist die Website. Jeder Webserver kann ihn ausliefern, und auf meinem Server tut das Caddy.

Was fehlt, ist der Punkt:

• Keine Laufzeit. Nichts wird ausgeführt, wenn jemand die Seite besucht. Kein PHP, kein Node-Prozess, kein Applikationsserver.
• Keine Datenbank. Der Inhalt liegt in Markdown-Dateien in Git, mit der ganzen Geschichte.
• Nichts zu patchen. Eine WordPress-Seite braucht für immer Updates für den Kern, das Theme und jedes Plugin. Ein Ordner mit HTML-Dateien hat keine Sicherheitsupdates.
• Nichts, was unter Last bricht. Dateien ausliefern ist das, was jeder Webserver extrem gut kann.

Warum gerade Hugo

• Es ist ein einzelnes Binary, geschrieben in Go. Installieren, und das ist die ganze Toolchain. Kein node_modules.
• Es ist schnell. Eine Seite mit ein paar Dutzend Unterseiten baut in deutlich unter einer Sekunde.
• Es kann mehrsprachige Seiten richtig. Übersetzungen sind Dateiendungen: post.md und post.de.md.
• Es verarbeitet CSS und Bilder selbst, also brauche ich keine eigene Build-Pipeline.

Schreib dein eigenes Theme

Diese Seite ist das warnende Beispiel. Seit einem Jahr ist sie ein poliertes Portfolio-Template in einem anderen Framework, und ich habe mehr Zeit damit verbracht, das Template anzupassen, als zu schreiben. Ich ziehe sie zurück zu Hugo, mit einer Handvoll Templates und einem Stylesheet, nur für diese Seite geschrieben.

Ein Theme bringt die Entscheidungen und den Update-Rhythmus von jemand anderem mit. Für eine Seite, die vor allem aus Text besteht, sind die Templates klein genug, um sie selbst zu besitzen.

Für Seiten, die ich von WordPress migriere, ist ein gut gepflegtes Theme wie PaperMod mit ein paar Anpassungen in Ordnung. Die Regel ist so oder so dieselbe: Das Theme nur über eigene Overrides ändern, nie direkt, damit es sich weiter aktualisieren lässt.

Deployen ist Kopieren

Eine statische Seite zu deployen heisst, die geänderten Dateien auf den Server zu kopieren. rsync vergleicht die Inhalte und lädt nur hoch, was sich geändert hat. Es entfernt auch Dateien, die es nicht mehr gibt. Deshalb hat jede Seite ihren eigenen Ordner auf dem Server, und dieser Ordner muss vor dem ersten Deploy existieren.

Was es kostet

• Keine dynamischen Funktionen ohne Hilfe. Kommentare, Suche, Formulare und Newsletter brauchen einen externen Dienst oder ein kleines Backend. Die meisten Seiten brauchen davon weniger, als sie denken.
• Bearbeiten heisst Git und Markdown. Für mich ist das ein Vorteil. Für eine Redaktion ohne technischen Hintergrund ist es eine Hürde, und ein gehostetes CMS passt vielleicht besser.
• Die Templates nutzen Gos Template-Sprache, an die man sich gewöhnen muss.

Der ganze Stack

Das ist der Boring Stack: Go, der Standard-Router, HTML vom Server, SQLite, handgeschriebenes SQL, Migrationen im Binary, Tests ohne Mocks, Docker für die Entwicklung, ein Server und statische Dateien für Websites.

Keine dieser Entscheidungen ist aufregend. Jede entfernt etwas, das ich sonst betreiben, aktualisieren oder debuggen müsste. Zusammen erlauben sie einer einzelnen Person, mehrere Apps in ihrer Freizeit zu bauen und zu betreiben. Genau das will ich von einem Stack.