Warum wir für diese Seite Hugo gewählt haben

Wir haben diese Seite in diesem Frühjahr neu gebaut. Die Vorgabe war kurz: Sie sollte schnell sein, sie sollte leicht zu bearbeiten sein, und sie sollte nach uns aussehen — nicht nach einem gekauften Theme. Wir haben Hugo gewählt und bereuen es nicht.

Was wir vermeiden wollten

Drei Dinge, alle aus früherer Erfahrung:

• Ein CMS, das wir am Leben halten müssen. WordPress, Strapi, Ghost — alle gut, keines davon will ein Jahr lang ignoriert werden.
• Ein JS-Framework für eine Content-Seite. Next.js kann eine Marketing-Seite problemlos rendern, aber wir würden ewig dafür zahlen.
• Themes. Ein Theme zu kaufen heißt, die Designsprache von jemand anderem auszuliefern. Wir wollten unsere aus der tatsächlichen Arbeit ableiten.

Was wir bekommen haben

Eine Handvoll HTML-Templates, ein content/-Verzeichnis mit Markdown und ein einziger hugo-Befehl, der ein statisches Verzeichnis erzeugt. Die ganze Seite baut auf einem Laptop in unter 50 ms.

$ hugo --gc --minify
                   | EN
-------------------+-----
  Pages            |  12
  Static files     |  9
Total in 18 ms

Bearbeitet wird in jedem Editor, der Markdown öffnet. Deploys sind eine Dateikopie. Es gibt keine Datenbank.

Das Designsystem

Das CSS ist in eine Foundation-Schicht (Reset, Layout, Komponenten, Barrierefreiheit) und zwei Theme-Dateien aufgeteilt, die die Token für Farbe, Typografie und Dekoration definieren — eines hell/redaktionell, eines dunkel/technisch. Das aktive Theme wird pro Sektion gewählt: Marketing-Seiten nutzen Atelier, diese Beiträge nutzen Terminal. Gleiches Markup, zwei Stimmen.

Wir waren versucht, einen einzigen Look auszuliefern. Zwei fühlten sich ehrlicher an: Wir haben zwei Zielgruppen (Lehrkräfte, die Klassenwerk nutzen, und Entwickler, die die Werkzeuge nutzen), und so zu tun, als gäbe es nur eine, hätte einen Kompromiss bei beiden bedeutet. An Sektionen gebundene Themes lösen das ohne einen JavaScript-Schalter, den die Leserin verwalten muss.