Zurück in die Zukunft (mit Hugo)

Wie alles begann

Als ich 1998 mit dem Bloggen begann, war das Wort ›Weblog‹ in Deutschland noch nicht gebräuchlich. Man half sich mit Begriffen wie ›Internet-Tagebuch‹ oder ›Digital Diary‹, um ein literarisches Phänomen zu beschreiben, das noch völlig neu war. Und natürlich gab es damals auch noch keine Content-Management-Systeme, mit denen man seine Artikel im Netz veröffentlichte. Viele strickten ihre Webseiten damals mit der Hand. Sie schrieben komplette Webseiten mit einem Texteditor oder einem dieser grauenvollen WYSIWYG-Editoren, die nicht einmal im Ansatz valides HTML produzieren konnten. Ich benutzte immerhin schon einen Website-Generator, der die HTML-Generierung automatisierte. Das Programm hieß WML Website Meta Language. Es verwandelte Textdateien, in denen sich einfache Auszeichnungselemente befanden, in HTML-Seiten, die alle notwendigen Navigationselemente enthielten und zusammen eine komplette Website bildeten. Die Seiten lud ich anschließend per FTP auf einen Webserver hoch.

Der Vorteil dieser Generatoren lag auf der Hand. Man musste sich nicht darum kümmern, die Navigationselemente jedes Mal manuell zu aktualisieren, wenn ein Text hinzukam. Kurz vor der Jahrtausendwende entdeckte ich den Applikationsserver Zope, der in Python programmiert war. Mit Zope konnte man nahezu ohne Programmierkenntnisse Webanwendungen erstellen. Für Zope gab es ein CMS-Framework, das die Programmierung von Content-Management-Systemen erleichterte. Und aus diesem System ging schließlich 2001 das Open-Source CMS Plone hervor, das ich seitdem für alle meine Websites benutzte. Man musste das CMS Plone damals auf einem eigenen Server hosten, was den Kreis der Nutzer auf diejenigen einschränkte, die ein Serversystem administrieren konnten. Die Blogosphäre entstand etwa zur gleichen Zeit, als große Anbieter damit begannen, Weblogs als Software-as-a-Service kostenlos anzubieten. Nun konnte plötzlich jeder einen Weblog betreiben. Der Rest ist Geschichte. Heute bloggen Millionen allein in Deutschland.

Je mehr Software, desto mehr Aufwand

Content-Management-Systeme und Weblog-Publishing-Systeme haben vieles gemeinsam. Um Inhalte zu veröffentlichen, sind keine HTML-Kenntnisse nötig. Der Autor schreibt seine Artikel mit Hilfe eines Online-Editors, der ähnlich bedient wird wie eine Textverarbeitung. Das ist sehr bequem und erklärt den Erfolg von Blogs und Content-Management-Systemen. Die einzelne Seite wird von den Systemen dynamisch generiert, sobald ein Nutzer mit seinem Webbrowser auf die Seite zugreift.

Diese Generierung von Webseiten ist aber rechenintensiv, sodass dynamische Websites sehr langsam sein können. Bei beliebten Websites, die viele Besucher haben, werden die HTML-Seiten deshalb in einem eigens dafür installierten Cache zwischengespeichert, sodass nicht bei jedem Aufruf der HTML-Code neu generiert werden muss. Die Kette der Werkzeuge, die für einen einfachen Weblog notwendig ist, kann so recht schnell ziemlich lang werden, was den Aufwand für den Systemadministrator in die Höhe treibt. Je mehr Software auf einem Server im Internet läuft, um so mehr Angriffspunkte bietet man auch potenziellen Angreifern. Deshalb muss der Systemadministrator regelmäßig Sicherheitslücken auf seinem Webservern schließen. Bei einem relativ sicheren System wie Plone bleiben Risiko und Aufwand überschaubar. Für die weit verbreitete Blog-Software Wordpress listet die National Vulnerability Database aber über 1100 Sicherheitslücken auf.

Wer seinen Blog nicht selbst hostet, sondern eine der kostenlosen Blog-Plattformen nutzt, kann diese Arbeit den Systemadministratoren des Anbieters überlassen. Wer aber selbst hosten will, weil er mehr Kontrolle über seine persönlichen Daten – oder die seiner Kunden – haben möchte, der wird sich vielleicht einmal nach einer Alternative zu den dynamischen Systemen umsehen und auf Hugo stoßen.

Renaissance der Website-Generatoren

Die statischen Website-Generatoren sind zu Beginn des 21. Jahrhunderts nicht ausgestorben, aber sie fristeten lange Zeit ein Nischendasein. So wurde beispielsweise die Dokumentation von Software ab und zu mit Hilfe eines statischen Website-Generators publiziert, weil dies den Vorteil hat, die Dokumentation zusammen mit dem Code in einem Repository zu verwalten. Beides, Quellcode und Dokumentation, liegen dabei in Form von einfachen Textdateien vor, die gemeinsam versioniert werden. Sphinx ist ein Beispiel für ein solches Dokumentationssystem.¹ Sphinx ist der De-facto-Standard zur Dokumentation von Software, die in der Programmiersprache Python geschrieben wurde. Die große Code-Hosting-Plattform GitHub bietet mit GitHub-Pages einen Service für Programmierer an, die zu ihrer Software eine passende Website einrichten wollen. Da GitHub statische HTML-Seiten ausliefert, holte dieser Dienst statische Website-Generatoren aus ihrem Nischendasein und machte sie wieder populär. In den letzten Jahren sind zahlreiche neue Generatoren hinzugekommen. Die Website www.staticgen.com listet eine große Anzahl solcher Systeme auf. Hugo ist ein relativ neuer Website-Generator. Er wurde in Go programmiert, einer Sprache, die von Google entwickelt und 2012 veröffentlicht wurde.

Abschweifung: Go

Ich nutze mittlerweile einige sehr interessante Programme, die in Go programmiert wurden. Die Grundzüge einer Programmiersprache hat meines Erachtens einen Einfluss auf die Struktur der Software, die mit der Sprache programmiert werden. Als Python-Evangelist habe ich darauf schon ab und an hingewiesen. Python hat die Art und Weise, wie man programmiert, verändert. Die Sprache hat aber vor allem die Grenzen zwischen Anwendern und Entwicklern verwischt. So benutzen viele Wissenschaftler, Ingenieure, Finanzexperten und andere Personen ohne große Programmiererfahrung Python, um komplexe fachspezifische Problemstellungen zu lösen.

Die Go-Programme, die ich nutze, sind Syncthing, Gogs und Hugo. Alle drei zeichnen sich durch Schlankheit und Schnelligkeit aus. Die Code-Hosting-Plattform Gogs läuft bei mir beispielsweise auf einem Raspberry Pi 2. Vermutlich gibt es einen Zusammenhang zwischen der Schlankheit der Programme und Go. Wäre ich Programmierer würde ich mir Go genauer anschauen.

Die Vorteile von statischen Website-Generatoren

Aus dem bisher Gesagten werden einige Vorteile von statischen Website-Generatoren bereits deutlich. Fassen wir sie noch einmal zusammen:

Preiswert

Statische Webseiten können auf jeden x-beliebigen Webspace hochgeladen werden. Es ist weder ein kostspieliger Server, noch ein besonderes Programm erforderlich, da jeder Webseiten-Hoster einen Webserver wie Apache bereitstellt, der statische Webseiten ausliefert. Ein Konto bei einem preiswerten Massenhoster ist daher für die eigene Website völlig ausreichend.

Schnell

Statische Webseiten werden in aller Regel schneller ausgeliefert als dynamische. Selbst dann, wenn man – wie bei einem Massenhoster oder einer kleinen VM – keine große Rechenkapazität zur Verfügung hat, bauen sich statische Webseiten schnell und flüssig auf. Da der Ressourcenverbrauch bei statischen Websites so gering ist, können viele Websites parallel auf einem Server betrieben werden. Bei CMS-Systemen stößt man da recht schnell an Grenzen.

Sicher

Für den Betrieb einer statischen Website ist lediglich ein Webserver-Programm wie Apache erforderlich. Content-Management-Systeme, die auch einen schreibenden Zugriff auf den Server haben – und damit ein Sicherheitsrisiko darstellen –, müssen nicht installiert und gewartet werden. Dadurch verringert man die Anzahl potenzieller Angriffspunkte ganz erheblich.

Professionell (Bequem)

Zunächst wollte ich ›Bequemlichkeit‹ als letzten Vorteil aufführen, da aber jeder Mensch etwas anderes darunter versteht, entschied ich mich für die Professionalität. 16 Jahre lang nutze ich nun schon ein CMS, um meine Websites zu verwalten, und ich möchte die Leistungsfähigkeit eines solchen Systems auch nicht missen, aber eine Sache hat mich dabei immer gestört: die Speicherung meiner Texte in einer Datenbank. Ich habe es lieber, wenn meine Texte in Form einfacher Textdateien vorliegen, sodass ich sie

1. mit einem Texteditor wie Vim, Emacs, Atom oder Sublime Text bearbeiten,

2. mit einer Version Control Software (VCS) wie Git oder Mercurial versionieren und

3. schnell und ohne großen Aufwand in ein anderes Ausgabeformat konvertieren kann, um sie beispielsweise als Buch oder E-Book zu veröffentlichen.²

Dieser professionelle Umgang mit Texten ist bei einem CMS nur mit erheblichem Aufwand zu erreichen. Bei statischen Website-Generatoren wird alles, Texte, Templates, Bilder, Stylesheets und Javascript-Dateien, in Form von Dateien auf dem Rechner gespeichert, sodass die gesamte Website in ein Repository eingecheckt werden kann. Veränderungen an der Website können schnell rückgängig gemacht werden, wenn sie zu Fehlern führen.

Offline-fähig

Mit statischen Website-Generatoren kann man neue Texte offline schreiben und dann veröffentlichen, wenn man Internetzugang hat.

Die Vorteile von Hugo

Schnelligkeit

Die meisten statischen Website-Generatoren sind in einer Skriptsprache wie Python, Ruby, Perl oder Javascript programmiert. Das hat viele Vorteile. So ist es relativ einfach, solche Systeme zu erweitern oder individuell anzupassen. Hugo ist in Go, einer kompilierbaren Sprache, geschrieben. Bei solchen Sprachen wird das Programm mit Hilfe eines Compilers in eine Maschinensprache übersetzt, die direkter mit der Hardware des Computers kommuniziert. Dadurch sind solche Programme in der Regel schneller. Und Hugo ist ein sehr schneller Website-Generator. Wer häufig Änderungen an einer Website mit vielen Seiten vornehmen muss, wird diese Qualität zu schätzen wissen.

Plattformunabhängigkeit

Hugo läuft auf Rechnern mit den unterschiedlichsten Betriebssystemen. So kann jeder Hugo nutzen und ein etwaiger Wechsel des Betriebssystem in unproblematisch.

Markdown

Bloggen in Markdown, was will man mehr! Markdown ist eine vereinfachte Auszeichnungssprache, mit der man seine Texte strukturieren kann. Markdown ist unaufdringlich; man bemerkt kaum, dass man seine Texte auszeichnet. Die Handhabung ist sehr intuitiv. Die Benutzung ist schnell erlernt. Die Art, Texte mit Markdown auszuzeichnen, geht einem sofort in Fleisch und Blut über. Als Autor muss man keine Zeile HTML schreiben.

Die ersten Erfahrungen mit Hugo

Dieser Blog ist die dritte Website, die ich mit Hugo umgesetzt habe. Alle Site liefen vorher mit dem CMS Plone. Die beiden anderen Websites sind eben jenes Sudelbuch, das ich bis 2000 mit WML betrieben habe, und meine Autorenhomepage. Bei diesen beiden Websites habe ich ein fertiges Hugo-Theme von der Website themes.gohugo.io benutzt und für meine Zwecke angepasst. Für diese Website habe ich ein Webdesign von HTML5 UP gewählt und erstmals selbst hugofiziert. Es heißt Phantom. Ich habe zwei Tage gebraucht, um das Design zu einem Hugo-Theme umzuwandeln. Da ich keine Vergleichszahlen habe, weiß ich nicht, ob dies ein guter Wert ist oder nicht. Da es mein erstes eigenes Theme ist, geht es sicher auch schneller. Im Großen und Ganzen muss man die HTML-Templates des Designers bloß mit ein wenig Intelligenz ausstatten.

Das Hugo-Template für diese Seite sieht beispielsweise so aus:

{{ partial "header" . }}
{{ partial "logo" . }}
{{ partial "navbar" . }}
                <!-- Main -->
                <div id="main">
                    <div class="inner">
                        <h1>{{ .Title }}</h1>
                        <div class="8u">
                        <p><strong>{{ .Description }}</strong></p>
                        </div>
                        <div class="12u$">
                        {{ with .Params.images }}
                        <span class="image main"><img src="{{ index . 0 | absURL }}" alt="" /></span>
                        {{ end }}
                        </div>
                        <p>{{ .Content }}</p>
                    </div>
                </div>
{{ partial "footer" . }}

Bereiche aus dem Webdesign, die wiederverwendet werden, sind in sogenannte »partials« ausgelagert. Anweisungen, die Hugo auswertet, werden in doppelte geschweifte Klammern gesetzt. Bei mir läuft natürlich vieles nach dem Try-and-Error-Prinzip ab und das Meiste habe ich ohnehin in anderen Themes abgeguckt. Aber im Großen und Ganzen ist das alles keine Hexerei. Leider habe ich noch Schwierigkeiten das Kontext-Prinzip, das Hugo verwendet, zu verstehen. Wann heißt es .Description und wann .Params.description oder $.Params.description?

Hugo ist, wie schon erwähnt, sehr schnell. Für diese Website benötigt Hugo gerade einmal 190ms unter Linux auf einem Dell 8500. Mein Sudelbuch, das immerhin 649 Beiträge und 412 verschiedene Tags enthält, für die jeweils eine Übersichtseite erzeugt wird, generiert Hugo in 2083ms also in zwei Sekunden.

Momentan übertrage ich die generierten Webseiten mit rsync auf meinen Server im Internet. Mittelfristig möchte ich aber die Seiten mit Hilfe eines Git-Hooks auf dem Server selbst generieren.