Einfach erklärt: Webseiten mit Hugo erstellen

Hugo zählt neben Jekyll zu den beliebtesten Statischen Website-Generatoren und kann ganz ohne weitere Hilfsmittel genutzt werden.

Website-Generatoren wie Jekyll, Hugo oder auch Gatsby werden seit Jahren derart gehyped, dass ich sie absichtlich links liegen gelassen habe. Hinzu kommt, dass die Zielgruppe für mich uninteressant ist. Denn Static Site-Generatoren richten sich weniger an normale Autoren, sondern eher an Web-Designer, Web-Entwickler und Code-Einsteiger.

Webseiten mit Hugo Static Site Generator

Für einen Überblicks-Artikel über Static Website-Generatoren habe ich dann aber doch eines dieser Geräte angefasst und mich ziemlich schnell für Hugo entschieden. Um es vorweg zu nehmen: Ich werde nicht auf statische Website-Generatoren umsteigen, aber die Entwicklung sollte man im Auge behalten. Denn wenn noch ein paar Bausteine hinzukommen (wie zum Beispiel zuletzt mit der Gatsby-Cloud), dann könnte die Welle in den Mainstream überschwappen ...

Wofür man Hugo verwenden kann

Hugo oder generell einen Static Site Generator kann man für jede Art von Webseite nutzen. Einen guten Eindruck von der Bandbreite vermitteln die vielen Themes, die es für Hugo gibt. Allerdings haben die Generatoren auch einige Nachteile:

Wenn eine Autorenoberfläche gewünscht ist oder wenn dynamischen Elemente nötig sind, dann bieten sich als Alternative die sogenannten Flat File Systeme an. Dabei handelt es sich um klassische dynamische CMS, die jedoch ohne Datenbank auskommen. Mit ihrer Leichtgewichtigkeit und einer vergleichsweise hohen Performance verbinden sie die Vorteile aus beiden Welten. Bei Trendschau Digital setzen wir Flat File Systeme beispielsweise für redaktionell pflegbare Dokumentationen, Schulungsunterlagen, Bedienungsanleitungen oder auch Mitarbeiterhandbücher ein.

In manchen Fällen ist eine Autorenoberfläche jedoch nicht zwingend nötig, oder man hat die nötigen Kenntnisse und Nerven, sich über verschiedene Systeme einen Publishing-Workflow zusammenzustellen und dabei externe Interfaces zu integrieren. In beiden Fällen sind Static Site Generatoren eine gute Wahl, und tatsächlich gibt es inzwischen auch einige Unternehmen, die einen Static Site Generator in ihre Systemlandschaft integrieren.

Während Gatsby mit seinen vielen Services inzwischen der Marktführer sein dürfte, bietet sich Hugo vor allem für den Einstieg in die Welt der Static Site Generatoren an, denn Hugo ist vergleichsweise unkompliziert in Sachen Installation und Bedienung.

Hugo installieren

Was bei vielen Static Site Generatoren etwas nervt sind die technischen Nebelkerzen, mit denen man Laien abschreckt und Einsteigern das Leben erschwert. Auch in der Dokumentation von Hugo bekommt man seitenlange Anleitungen präsentiert, wie man Git installiert, welche fancy Package-Manager man für welche Systeme nutzt, wie man den Dependency-Manager klar macht und, ganz wichtig, wie man die Konsole permanent mit schlauen Befehlen füttert. Das kann man alles machen. Man kann aber bei Hugo auch einfach eine simple Zip-Datei für sein System herunterladen, sie anschließend in einen beliebigen Ordner entpacken und fertig.

Erstaunlicherweise findet man in dem entpackten Ordner unter "bin" nur eine kleine Exe-Datei (bei Windows). Und mehr braucht man für Hugo auch nicht. Das heißt, man muss keine Entwicklungs-Umgebung wie XAMPP einrichten, man braucht auch keinen Node-Server, man kann sogar auf Git verzichten. Denn in der vergleichsweise kleinen Hugo-Datei ist alles drin, inklusive Server.

Mit Hugo arbeiten

Nach dem Download von Hugo kommt man um die Konsole nicht mehr herum. Aber keine Angst, das bleibt bei Hugo ziemlich simpel. Um die Konsole zu öffnen, gibt man bei Windows einfach das Wort "cmd" oder "cmd.exe" in das Suchfeld ein und schon springt der schwarze Kasten auf. Wenn man den Hugo-Ordner direkt unter C: erstellt hat, wechselt man mit einem simplen Befehl in eben diesen Ordner: 

cd \hugo

Und als Navigationshilfe für die Konsole die wichtigsten Befehle:

Um zu testen, ob Hugo auch funktioniert, kann man vom Hugo-Ordner aus mit dem folgenden Befehl die Version von Hugo aufrufen: 

bin\hugo version

Das Muster bei den Konsole-Befehlen ist immer dasselbe: Man gibt von seinem Standort aus den Pfad zur Hugo-Exe ein. In diesem Fall befinden wir uns im Hugo Stammverzeichnis und der Pfad zur Exe lautet bin\. Danach folgt die Angabe hugo mit einem Befehl wie version und häufig noch weiteren Parametern.

Um ein neues Projekt zu erstellen, nutzt man den Befehl "new site" und hängt als zusätzlichen Parameter einen beliebigen Ordnernamen für das Web-Projekt an. Beispiel: 

bin\hugo new site meinProjekt

Mit dem Befehl legt Hugo einen Ordner mit dem Namen "meinProjekt" an und erstellt darin ein paar Dateien und Standard-Verzeichnisse für die Webseite. Und eines dieser Verzeichnisse hört auf den Namen "Themes"...

Ein Theme installieren

Ein Theme ist bei Hugo schnell installiert: Einfach runterladen und in den Theme-Ordner entpacken. Eine Auswahl an Themes findet man auf der Hugo-Seite. Heruntergeladen werden die Themes bei GitHub. Wer kein Git nutzt, kann bei GitHub einfach den grünen Button drücken (rechts oben) und eine konventionelle ZIP-Datei herunterladen.

Ich habe das Hugo-Universal-Theme heruntergeladen und nach dem Entpacken den Ordner in "hugo-univeral-theme" umbenannt, also das "master" im Ordner-Namen gelöscht. Damit das Theme von Hugo erkannt wird, muss man es noch in die Konfigurations-Datei config.toml eintragen. Die config.toml findet man direkt unter dem Projekt-Ordner (in diesem Fall also "meinProjekt"). Öffnen und bearbeiten kann man die toml-Datei mit einem beliebigen Code-Editor wie z.B. Notepad++, Atom oder SublimeText. Wer sowas überhaupt nicht installiert hat, kann auch den einfachen Windows Editor nutzen (bei Mac analog).

Die Theme-Angabe fügt man in der config.toml einfach als letzte Zeile hinzu: 

theme = "hugo-universal-theme"

Anschließend kann man die Seite bereits besuchen. Dazu wechselt man in der Konsole in den Projektordner und startet von dort aus den Server. Den liefert Hugo wie gesagt in der Exe-Datei bereits mit: 

cd meinProjekt
..\bin\hugo server

Jetzt läuft der Server und man kann die Webseite mit dem Browser unter folgender Adresse besuchen:

localhost:1313

Sonderlich hübsch ist die Seite noch nicht, da nur etwas zerschossenes Layout sichtbar ist und sämtliche Inhalte fehlen. Bevor wir uns allerdings um die Inhalte kümmern, sollten wir den Server mit der Tasten-Kombination Strg+C wieder stoppen, denn solange der Server läuft, ist die Konsole für Eingaben gesperrt. Außerdem kann man sich optional auch noch das Konsolen-Leben etwas einfacher machen, in dem man eine Umgebungsvariable für Hugo einrichtet.

Hugo als Umgebungsvariable einrichten

Auf die Dauer ist es etwas umständlich, in der Konsole für die Hugo-Befehle immer das Verzeichnis mit der Hugo-Exe anzugeben. Das führt zu hässlichen Angaben wie ..\bin\hugo server, wenn man den Server aus einem Projektordner heraus starten will. Eine Eingabe wie hugo server wäre natürlich viel einfacher. Und genau das geht bei Windows mit den sogenannten Umgebungsvariablen.

Mit einer Umgebungsvariable speichert man bei Windows einfach einen Pfad zu einer ausführbaren Datei als Variable ab. Gibt man anschließend hugo ein, steht diese Variable stellvertretend für die komplette Pfadangabe. Solche Variablen erstellt man in der Regel für alle Tools, die man häufig über die Konsole verwendet (Git, Composer etc.).

Um die Variable einzurichten öffnet man über die Windows-Suche einfach die "erweiterten Systemeinstellungen". Dort sucht man den Button "Umgebungsvariablen". Im neuen Fenster findet man oben die Variable mit dem Namen "Path". Klickt man dort zweimal drauf, kann man im Feld "Wert der Variable" eine Pfad-Angaben ergänzen. Dazu hängt man den Pfad einfach nach einem Semikolon hinten dran, also ;C:\hugo\bin.

Bevor die Umgebungsvariable wirksam wird, muss man die Konsole einmal schließen und wieder öffnen. Jetzt kann man in den Projekt-Ordner wechseln und den Server einfach mit hugo server starten: 

cd \hugo\meinProjekt
hugo server

Soweit ist alles schick und man kann sich um die Inhalte der Webseite kümmern.

Inhalte für Hugo erstellen

Inhalte werden bei den meisten Static Site Generatoren mit Hilfe von Markdown-Files erstellt. Markdown ähnelt dem Wiki-Markup und ist eine einfache und relativ universelle Auszeichnungssprache für Texte. Der große Vorteil von Markdown ist, dass man keinen komplizierten Quellcode schreiben muss, aber dennoch sehr leicht aus Markdown-Files HTML erzeugen kann. D.h. man kann Inhalte, aus denen später Webseiten entstehen sollen, als einfache und gut lesbare Text-Dateien schreiben. Zur Einarbeitung könnt ihr diese Einführung in Markdown nutzen.

Das Universal-Theme liefert im Ordner "exampleSite" ein paar Beispiel-Inhalte mit. Am besten kopiert man einfach die Dateien in die entsprechenden Ordner seines Projekt-Folders, also

Anschließend ersetzt man noch die gerade bearbeitete config.toml in seinem Projekt-Ordner mit der config.toml aus dem Theme-Ordner. Schon ist die Seite fertig.

Zur Kontrolle einfach wieder den Server starten: 

hugo server

Anschließend erscheint die Webseite in voller Schönheit und mit vielen Inhalten unter localhost:1313.

Inhalte editieren

Wer die Inhalte editieren will, kann einfach mal eine Markdown-Datei aus dem Content-Folder öffnen. Markdown-Files kann man grundsätzlich mit jedem einfachen Text-Editor öffnen und bearbeiten, allerdings nicht mit Word. Also entweder den ganz normalen Windows-Editor nutzen, oder wieder einen Code-Editor wie Notepad++, Atom oder SublimeText. Wer Markdown langfristig zum Schreiben nutzt, der wird am besten mit speziellen und sehr Autoren-freundlichen Markdown-Editoren wie Typora klar kommen.

Die Inhalte der Markdown-Datei sehen etwa wie folgt aus: 

+++
title = "Linked post"
date = "2015-10-02T21:49:20+02:00"
tags = ["golang", "programming", "theme", "hugo"]
categories = ["programming"]
banner = "img/banners/banner-4.jpg"
author = "John Doe"
+++
# Überschrift
Etwas Fließtext: Lorem ipsum dolor sit amet, consectetur adipiscing elit. In mauris nulla, vestibulum vel auctor sed, posuere eu lorem. Aliquam consequat augue ut accumsan mollis. Suspendisse malesuada sodales tincidunt. 
- Ein Listenpunkt
- Noch ein Listenunkt
Weiterer Fließtext: Vivamus sed erat ac augue bibendum porta sed id ipsum. Ut mollis mauris eget ligula sagittis cursus. Aliquam id pharetra tellus. Pellentesque sed tempus risus. Proin id hendrerit ante. Vestibulum vitae urna ut mauris ultricies dignissim. Ut ante turpis, tristique vitae sagittis quis, sagittis nec diam.

Die Markdown-Dateien bestehen aus zwei Teilen: Der obere Teil zwischen den Plus-Zeichen heißt FrontMatter. Dort findet man Meta-Angaben wie den Titel, das Erstellungsdatum, den Autor, Pfadangaben zu allgemeinen Bildern und einiges mehr. FrontMatter ist ein recht universales Prinzip, mit denen eigentlich alle File-basierten System arbeiten (Static File Generator und Flat File CMS). Hinter dem FrontMatter folgt der sichtbare Inhalt der Webseite mit Markdown-Formatierungen.

Wer weitere Inhalte erstellen will, kann einfach eine Datei kopieren und die Inhalte sowie die Meta-Daten anpassen. Oder man erzeugt eine neue Markdown-Datei mit vorbereitetem FrontenMatter ganz einfach über die Konsole: 

hugo new posts/my-first-post.md

Den statischen Webauftritt generieren

Wenn man mit der Seite zufrieden ist und eine statische HTML-Seite generieren will, gibt man einfach in seinem Projekt-Ordner den Befehl ...

hugo

... ein. Hugo legt die fertige Webseite mit den HTML-Dateien und mit allen Assets im Ordner "\public" ab. Die Inhalte des Ordners kann man dann auf seinen Server schieben und schon ist derr Web-Auftritt live.

Die Vor- und Nachteile der Static Site Generatoren

Normalen Autoren bringen die Static Site Generatoren derzeit noch so gut wie nichts. Zwar könnten sich Static Site Generatoren in Zukunft auch zu vollwertigen und leicht bedienbaren CMS entwickeln. Vor allem die Kombination mit den sogenannten Headless CMS wirkt vielversprechend. In ihrer Reinform haben Static Site Generatoren für den Autor jedoch deutlich mehr Nachteile als Vorteile:

Das ganze Geschrei um Static Site Generatoren kann man eigentlich nur vor dem Hintergrund eines größeren Technik-Trends verstehen. Und dabei spielen Frontend-Entwickler und Web-Designer eine entscheidende Rolle. Denn für diese Gruppe gab es bislang nur zwei Möglichkeiten, wenn sie eine Webseite in Eigenregie umsetzen wollte:

Mit den Static-Site-Generatoren ist die Arbeit für Web-Designer und Frontend-Entwickler viel einfacher geworden: Bei der Theme-Entwicklung arbeitet man wie gehabt mit HTML, CSS und JavaScript. Hinzu kommen relativ einheitliche Template-Sprachen nach dem Muster von Twig und ebenfalls universelle Konfigurations-Dateien wie YAML oder Toml. Damit ist die Backend-Sprache des Generators ziemlich unerheblich geworden (Hugo ist beispielsweise in der Google-Sprache "Go" geschrieben). Wichtiger ist jedoch, dass der Umfang einer Webseite mit den Generatoren keine Probleme mehr verursacht. Denn durch die automatische Generierung erzeugt eine einzelne Seite den gleichen Aufwand wie ein Webauftritt mit 1000 Seiten.

Das heißt: Als Frontend-Coder ist man völlig befreit von Backend-Systemen und kann dennoch komplexe Seiten und sogar Blogs erstellen, die dann auch noch unschlagbar performant und sicher sind.

Der JAMStack-Trend

Hebt man noch weiter ab, dann passen die Static Site Generatoren auch zu dem allgemeinen Technik-Trend weg vom Server und hin zum Browser. Noch vor zehn Jahren wurden Webseiten mit Backend-Technologien komplett auf dem Server erzeugt und dann im Browser mit etwas JavaScript gegebenenfalls noch angereichert. Auch heute funktionieren die meisten System noch so, und WordPress ist dafür ein gutes Beispiel.

Inzwischen hat sich das Verhältnis jedoch umgekehrt: Das klassische "serverseitige HTML-Rendering" befindet sich vielfach auf dem Rückzug. Stattdessen soll das Backend die Funktion eines Datenlieferanten übernehmen, d.h. im Schwerpunkt nur noch Daten über sogenannte APIs (Programmier-Schnittstellen) zur Verfügung stellen. Dabei ist das Backend möglichst kein einheitlicher "monolithischer Klotz" mehr, sondern unterteilt sich in viele unabhängige und schlanke "Microservices", die sich beliebig ansprechen und kombinieren lassen.

Die eigentlichen Webseiten entstehen jedoch über die Frontend-Technologie direkt im Browser. Alles was man dazu benötigt, ist ein bisschen HTML-Markup und JavaScript. Statische Inhalte (wie selten veränderte Texte) werden auch statisch ausgeliefert. Dynamische Inhalte werden als Daten und Services mit JavaScript über APIs in die Webseite integriert. Das ganze nennt man JAMStack: JavaScript, Apis und Markup. Eingeleitet wurde der Trend durch HTML5 und CSS3. Beschleunigt wurde der Trend durch Frontend-Frameworks wie React.js, Angular und Vue.js.

Genau diese Strategie hat auch das Smashing-Magazin mit seinem spektakulären Umstieg von WordPress auf den Static Site Generator Hugo verfolgt. Die Inhalte bestehen aus MarkDown-Files, die man per Git verwaltet. Die Webseiten werden mit Hugo generiert und über ein weltweites Content Delivery Network (CDN) zur Verfügung gestellt. Daten und Services werden über APIs und Microservices im Frontend eingebunden.

Fazit: Das Pendel kennt zwei Richtungen

Schöne neue Welt. Und für ein Smashing Magazine sind solche neuen Entwicklungen natürlich auch umsetzbar. Für normale Autoren, für den einzelnen Blogger und für kleine Webseiten-Betreiber fehlen dazu jedoch noch einige Bausteine. Und während der Aufwand für das Aufsetzen eines solchen Systems derzeit noch vergleichsweise hoch ist, wirken die Vorteile in vielen Fällen recht technisch und theoretisch. Entwickler können sich sicherlich daran erfreuen. Dem Autoren dürfte es jedoch egal sein, denn ein Endnutzer kann nicht unterscheiden, wie die Webseite im Hintergrund entsteht.

Also abwarten, wohin die Reise noch führt. Zur Erinnerung: Die ersten Content-Management-Systeme erzeugten auch statische Web-Auftritte und die Systeme waren entkoppelt. Dann folgte der große Trend hin zu dynamischen Systemen aus einer Hand. Jetzt schlägt das Pendel wieder zurück. Bleibt die Frage, ob passende Lösungen entstehen, mit denen der Trend schnell genug in den Mainstream überschwappt. Denn man kann davon ausgehen, dass die Richtung des Pendels vor allem im CMS-Bereich auch schnell wieder wechselt ...