Betrachtungen eines Hugo Neulings

Dieser Blog ist mit Hugo, einem Generator für statische Seiten gebaut. Als jemand, der Erfahrung in der Webentwicklung, aber bisher noch nie mit Go oder Hugo gearbeitet hat, möchte ich meine Gründe teilen, warum ich mich für Hugo entschieden habe, meine Erfahrung was den Aufbau meines eigenen Hugo Themes von Grund auf angeht und meine Gedanken zu diesem Werkzeug. Was sind die Vorteile und Nachteile von Hugo? Für wen ist es das passende Werkzeug? Ist Hugo Boss (tut mir leid, das musste einfach sein)? Lasst es und herausfinden.

1. Der anfängliche Konkurrent: Astro

Und ich muss sagen: Astro ist vom ersten Moment an beeindruckend! Das Team hinter dem Framework begrüßt uns mit einer großartig aussehenden Seite , die die Stärken von Astro wirklich fantastisch präsentiert und uns schon auf der Startseite richtig aufhypt. Aber was wichtiger ist: die Astro Entwickler stellen uns außerdem eine gründliche, klar strukturierte und herausragend hervorragende Dokumentation bereit, sogar mit - ja ist es denn die Möglichkeit - einem fantastischen Tutorial wie man einen vollständig funktionsfähigen Blog mit Astro erstellt!

Ernsthaft, das Tutorial macht genuin Spaß und ich kann jedem, der die Grundlagen von HTML, CSS und JavaScript beherrscht (die im Tutorial beschriebenen Grundvoraussetzungen), nur wärmstens ans Herz legen, es einmal auszuprobieren. Am Ende des Tutorials hat man gelernt wie man Blog Beiträge mit Markdown Textdateien erstellt und hat einen voll funktionsfähigen Blog mit einem System für Schlagwörter, einem Archiv, einem RSS Feed und einem Hell- und Dunkelmodus. Wer jetzt noch das Styling etwas anpasst - oder einfach eines der vielen freien Themes installiert -, der kann tatsächlich direkt mit seinem Blog live gehen. Das Tutorial erklärt sogar, wie man seinen Blog kostenlos mit Netlify hosten kann!

Kein Vorwissen in React oder einem ähnlichen JS framework ist nötig, um Astro zu nutzen, aber diejenigen, die solches Vorwissen haben, werden sich direkt zuhause fühlen: Astro Projekte gliedern sich um wiederverwendbare, im besten Fall einfache und kleine Komponenten, die leistungsstarkes JSX nutzen, eine JavaScript-basierte Syntax, die wie HTML aussieht (und auch zu HTML gerendert werden wird), während JavaScript Variablen, Ausdrücke/Expressions, Methoden und selbstdefinierte JSX Elemente voll unterstützt werden.

Das ist nicht ansatzweise so komplizert, wie es sich vielleicht anhört. Solange man gundlegendes HTML und JavaScript beherrscht, ist JSX sogar ziemlich intuitiv und Astros Dokumentation macht einen guten Job bei der Einführung in JSX. Astro biete auch sofort einsatzbereite TypeScript Unterstützung, das Gleiche gilt für Sass/SCSS wenn man das Styling lieber damit als mit Vanilla CSS schreiben möchte. Und natürlich kann man auch Tailwind installieren, da Astro mit Node.js läuft, was heißt, dass man vollen Zugang zum reichen npm Ökosystem hat.

Mehr noch, Astro bietet außerdem die Möglichkeit, andere Frameworks wie React, Vue und Svelte zu integrieren! Richtig gehört, Astro kann als Framework für Frameworks genutzt werden (was lachhaft und großartig zugleich ist), so dass man, wenn man altbewährte Komponenten aus einem anderen Framework hat, diese ganz einfach in sein neues Astro Projekt kopieren&einfügen kann, falls man dynamische Elemente benötigt (die Astro “Inseln/Islands” nennt). Was wiederum die Integration von Framework-spezifischen Bibliotheken wie React Hook Form oder zod ermöglicht.

Als jemand, der aus der React-Entwicklung kommt, war die Einarbeitung in Astro für mich ein Spaziergang. Und nachdem ich mich beruflich mit den “Freuden” von Next.js herumschlagen durfte, fühlte sich Astro wie ein wohltuender frischer Wind an. Astro fühlte sich vertraut und intiutiv an, es behält die guten Aspekte der React-Entwicklung bei und erreicht viel von dem, was Next.js ausmacht, auf eine viel effizientere, einfachere und vernünftigere Weise.

Und trotzdem… irgendwie fühlte sich das alles immer noch nach “zu viel” an, um eine einfache Webseite und einen Blog aufzubauen. Im Grunde genommen muss ein Blog ja nur aus statischen HTML-Seiten bestehen, die Textelemente, Hyperlinks und Bilder beinhalten, gestylt mit etwa CSS und vielleicht noch ein bisschen JavaScript dazu, z.B. für eine Suchfunktion. Gibt es denn keine noch einfachere Möglichkeit, so etwas zu generieren? Wofür brauche ich denn da das npm Ökosystem, auf das sich Astro stützt, was ist denn die Notwendigkeit für alle diese Node Module und für die technischen Schulden, die damit einhergehen?

Wer nicht weiß, was damit gemeint ist und was das bedeutet: es bedeutet, sich auf Werkzeuge von dritten Personen zu verlassen, auf externe Abhängigkeiten (und npm sagt mir, dass Astro 63 von solchen Abhängigkeiten hat - von denen wiederum selbst die meisten ihre eigenen Abhängigkeiten haben), die von Zeit zu Zeit ein Update benötigen. Und weil sie alle einzeln verwaltet und aktualisiert werden, aber alle zusammenhängend funktionieren müssen wenn sie als die Abhängigkeiten eines Projekts miteinander verflochten sind, bedeutet das, dass manche Dinge von Zeit zu Zeit gerne mal kaputt gehen. Kurzgesagt: es bedeutet, dass man mit einem Faktor potentieller Instabilität beim Erstellen seiner Webseite umgehen muss.

(Tatsächlich ist gerade als ich das hier schreibe ein massiver Hackerangriff auf npm erfolgt , der zwar nur die npm Pakete von einem einzigen Entwickler zum Ziel hatte, allerdings, ich zitiere frei übersetzt: “Chalk und Debug werden in zahllosen anderen Frameworks und Bibliotheken genutzt, womit auf indirektem Weg auch Projekte betroffen sind, die diese Pakete gar nicht bewusst installiert haben.” - die Hacker hätten ja nicht gleich so übertreiben müssen, nur um mein Argument zu belegen!)

Das gleiche Problem besteht auch bei 11ty, einem anderen JavaScript Generator für statische Seiten, der sogar noch schlanker und performanter als Astro sein soll, allerdings ebenfalls auf Node.js und dem npm Ökosystem aufgebaut ist.

Um es ganz klar zu sagen: ich will weder Astro noch 11ty schlechtreden. Im Gegenteil, ich denke, es ist deutlich geworden, dass ich von Astro sehr beeindruckt bin und 11ty sieht ebenfalls vielversprechend aus. Ich bin mir sicher, dass es abhängig von der Art von Seite die gebaut werden soll, Szenarien gibt, wo beide Werkzeuge die perfekte Wahl wären. Ich werde beide für die Zukunft definitiv im Hinterkopf behalten. Fairerweise muss man auch betonen, dass Astro nicht dafür bekannt ist, ständig wegen npm Paktetkonflikten abzuschmieren. Und selbstverständlich gibt es einen Grund, warum das npm Ökosystem existiert, das uns einfachen Zugang zu und Integration von vielen leistungsstarken Bibliotheken und Werkzeugen in unsere Projekte ermöglicht. Es gibt klare Anwendungsfälle für Node.js und npm Pakete, wo sie sehr viel an Wert beisteuern. Allerdings, in meinem speziellen Fall sind sie bestenfalls zu viel des Guten, schlimmstenfalls potentielle Problemquellen und so oder so einfach nicht nötig.

Deswegen beschloss ich, das vertraute JavaScript Ökosystem zu verlassen und mich anderswo umzuschauen, auf meiner Suche nach einem Seitengenerator, der Einfachheit und Minimalismus bietet. Und ich fand: Hugo.

2. Hugo: Features, Einrichtung und erste Eindrücke

Mir war Hugo schon seit einiger Zeit ein Begriff und ich hatte Gutes über dieses Werkzeug gehört. Namentlich dass es in der Tat auch große, komplexe Seiten unwahrscheinlich schnell und effizient generiert und zugleich flexibel ist und Anpassungen leicht macht. Die statischen Seiten, die von Hugo generiert werden, laden schnell, haben keinen unnötigen Code Overhead und dazu kommt noch, dass Hugo einige sehr nützliche eingebaute Funktionalitäten bietet, wie optimierte Bildverarbeitung und Unterstützung für mehrsprachige Seiten - perfekt für meine Bedürfnisse, da ich zusätzlich zu meiner deutschen Muttersprache auch Beiträge auf Englisch schreiben wollte!

Im Vergleich zu Astros Webpräsenz, fühlt sich Hugos Webseite ein wenig, na ja, unterwältigend an. Andererseits geht es hier ja nicht um eine Preisverleihung für die beste Präsentation und ich kann außerdem schlecht Einfachheit fordern und mich dann beschweren, wenn ich sie bekomme. Also weiter mit den relevanten Punkten: das Team hinter Hugo stellt uns auch eine Schnellstart-Anleitung zur Verfügung, die uns erklärt, dass wir Go (eine Programmiersprache), Git (ein System zur Versionskontrolle), Dart Sass (ein Superset für die Styling-Sprache CSS) und natürlich Hugo selbst auf unserer Maschine installieren müssen und wie wir das auf Windows, Mac, Linux und sogar BSD bewerkstelligen können. Komplett mit der Option, Hugo aus dem Quellcode zu kompilieren.

Diese Werkzeuge sind notwendig, um unsere Seite zu bauen. Aber das schlussendliche Resultat ist in sich geschlossen und benötigt keines dieser Werkzeuge mehr, genau wie auch bei Astro. Und obwohl Hugo selbst theoretisch wegen einem fehlerhaften Update kaputtgehen könnte, oder Go rein hypothetisch eines Tages implodieren könnte, sind solche Szenarien a) sehr unwahrscheinlich und b) immer noch ein wesentlich geringeres Risiko, als sich auf mehrere dutzend (oder sogar hundert) npm Pakete zu verlassen.

Hugo funktioniert, wie auch Astro, indem man seine Beiträge in Markdown Textdateien schreibt und nutzt dann ein “Theme”, eine Sammlung zugrundeliegender Vanilla HTML und CSS Dateien, die als Mustervorlagen für das Generieren der Seite aus dem Markdown Text dienen. Diese Vorlagen kann man bearbeiten und natürlich auch JavaScript Code hinzufügen, wenn man möchte. JSX wird nicht unterstützt, aber da Hugo ein Generator ist, muss man natürlich auch nicht alles selbst manuell in HTML schreiben und hartkodieren. Stattdessen nutzt Hugo die Text & HTML Template Pakete von Go, um statische HTML Seiten aus unseren Inhalten zu generieren. Das bedeutet, dass man mit Go Variablen und Methoden arbeitet, allerdings nur, wenn man beschließt, die Templates zu bearbeiten, die dem installierten Theme und damit der Seite zugrundeliegen. Dazu gleich mehr.

Das alles ist für den Anfang aber nicht notwendig, die Schnellstart-Anleitung bringt uns stattdessen die grundlegenden Konsolenbefehle bei (man wird extra “gewarnt”, dass man mit der Konsole vertraut sein muss, aber ehrlich gesagt muss man einfach nur einige Befehle kopieren&einfügen, die von der Anleitung bereitgestellt werden), die man benötigt, um Inhalte zu erstellen, den eingebauten Entwicklungsserver zu starten und seine Seite für die Veröffentlichung generieren zu lassen.

Wir lernen, wie man Beiträge aus Markdown Textdateien generiert, wie man ein Theme installiert, wie man einige notwendige Einstellungen in der primären Konfigurationsdatei für Hugo Webseiten vornimmt (standardmäßig: hugo.toml) und das war’s dann auch schon. Ansonsten wird nichts benötigt. Man wird auch mit mehreren Anleitungen versorgt, wie man seine Seite veröffentlichen/hosten kann. Und in der Tat, wenn man einfach eines der vielen und oft sehr schönen kostenlosen Themes auswählt, die von der Hugo Community bereitgestellt werden und man dieses Theme genau so liebt, wie es ist, dann muss man nur noch ein paar Theme-spezifische Regeln in seine Konfigurationsdatei einfügen und schon ist man startklar, um seine neue Webseite zu veröffentlichen! Wohlgemerkt, für all das muss man keine einzige HTML oder CSS Datei anfassen oder auch nur das Mindeste über JavaScript oder Go wissen.

Sagen wir allerdings, dass wir unser gewähltes Theme gerne ein bisschen personalisieren würden: hier wird die Sache dann, nun ja… interessant.

3. Ein Hugo Theme von Grund auf erstellen

Mir haben die Themes Paper und PaperMod recht gut gefallen, anfänglich habe ich mich für das zweitgenannte entschieden. Allerdings verspürte ich das Bedürfnis, beide etwas anzupassen, nur ein bisschen: ein paar Farben und die Art, wie die Karten-Elemente aussehen verändern, den Header umstrukturieren und für meinen zweisprachigen Aufbau wollte ich nicht, dass die Länderflaggen bei jedem Beitrag angezeigt werden und dort die jeweilige Übersetzung verlinken, stattdessen wollte ich, dass die “zentrale Flagge” im Header einen dynamischen Link beinhaltet, je nachdem auf welcher Seite man sich befindet.

Das hört sich ja jetzt nicht so schwer an, nicht wahr? Also öffnete ich die HTML Dateien für das Theme, sah mir den Code an - und verstand gar nichts. Na gut, “gar nichts” ist ein bisschen überdramatisch und rückblickend muss ich sagen, dass der Code für PaperMod gut geschrieben und ziemlich klar ist, außerdem bietet das Theme eine recht gründliche und einfach zu folgenden Dokumentation auf GitHub an. Aber am Anfang, als völliger Hugo und Go Noob, war ich wirklich verwirrt. Ganz besonders was das mehrsprachige Übersetzungsfeature angeht.

Das hat einen Nerv bei mir getroffen. Wie kann ich denn meine eigene Webseite auf einem Theme und Code aufbauen, die ich nicht verstehe, wo jeder kleine Änderungswunsch zur Herausforderung wird? Das fühlte sich (und fühlt sich) für mich inakzeptabel an. Ganz klar, es gibt keinen Grund, ständig das Rad neu zu erfinden. Zum Beispiel muss ich gestehen, dass ich mich nicht aufgemacht habe, meinen eigenen Generator für statische Seiten von Grund auf zu programmieren, obwohl es immer noch einige Dinge an Hugo gibt, die sich mir entziehen und sich wie Zauberei anfühlen (aber hey, wenn ich mal zu viel Freizeit habe, könnte ich ja jederzeit den Quellcode von Hugo lesen). Aber was das Theme meiner Seite angeht, war das Rad neu erfinden genau das, wofür ich mich entschied: ich wollte mein eigenes Theme von Grund auf selbst schreiben, um die Grundlagen von Go und Hugo zu lernen und um zu verstehen, was hinter den Kulissen meiner eigenen Seite vorgeht.

3.1 Das Leid mit der Dokumentation

Also sagte ich Lebewohl zu PaperMod und führte stattdessen den Befehl hugo new theme aus, der ein Grundgerüst für ein neues Theme erstellt. Ich werde ab hier ein paar Code-Schnipsel teilen, um einige meiner Beschwerden für diejenigen zu verdeutlichen, die Code lesen können. Wer nichts mit Programmieren am Hut hat, kann diese Auszüge selbstverständlich überspringen. Also fangen wir an, das hier ist der Code für das Navigationsmenü, das vom Befehl hugo new theme erstellt wird:

{{- define "_partials/inline/menu/walk.html" }}
  {{- $page := .page }}
  {{- range .menuEntries }}
    {{- $attrs := dict "href" .URL }}
    {{- if $page.IsMenuCurrent .Menu . }}
      {{- $attrs = merge $attrs (dict "class" "active" "aria-current" "page") }}
    {{- else if $page.HasMenuCurrent .Menu .}}
      {{- $attrs = merge $attrs (dict "class" "ancestor" "aria-current" "true") }}
    {{- end }}
    {{- $name := .Name }}
    {{- with .Identifier }}
      {{- with T . }}
        {{- $name = . }}
      {{- end }}
    {{- end }}
    <li>
      <a
        {{- range $k, $v := $attrs }}
          {{- with $v }}
            {{- printf " %s=%q" $k $v | safeHTMLAttr }}
          {{- end }}
        {{- end -}}
      >{{ $name }}</a>
      {{- with .Children }}
        <ul>
          {{- partial "inline/menu/walk.html" (dict "page" $page "menuEntries" .) }}
        </ul>
      {{- end }}
    </li>
  {{- end }}
{{- end }}

Entschuldigung, wie bitte? Das soll ein grundlegender Aufbau sein, der intuitiv zu verstehen und einfach zu bearbeiten ist?

Offenkundig war eine ernsthafte Lektüre der Dokumentation angebracht. Was mich zu einem anderen Problem führt: während die Dokumentation für Hugo zwar recht gründlich ist, könnte man ihren Aufbau und ihre Präsentation allerdings deutlich verbessern. Vielleicht liegt das nur an mir, aber wenn ich auf der Jagd nach einer eingebetteten Referenz bin, fühlt sich das Karten Grid-Layout, das die Dokumentation hat und das man durchqueren muss, auf keinen Fall nach einer Verbesserung an, im Vergleich zum standardmäßigen, altbewährten ausklappbaren Inhaltsverzeichnis, wie es z.B. die Astro Dokumentation enthält.

1. die Doku wurde noch nicht aktualisiert und enthält veraltete Anweisungen
2. die Doku wurde aktualisiert und beschreibt etwas, das in Gegensatz zu dem steht, was sämtliche ältere Anleitungen und Themes befolgen

Um fair zu sein muss ich sagen, dass sich die Hugo Entwickler, nach allem was ich gesehen habe, darum bemühen, Rückwärtskompabilität zu gewährleisten, was bedeutet, dass die veralteten Informationen immer noch funktionieren werden. Trotzdem, das ist nicht hilfreich wenn man versucht zu lernen und zu verstehen, wie Hugo und Themes funktionieren. Zum Beispiel, um Szenario 2 zu illustrieren: wenn man den Befehl hugo new theme ausführt, wird man überrascht feststellen, dass die Dateien, die der Befehl auswirft, deutlich anders strukturiert und benannt sind, als die Ordner und Dateien in so ziemlich jedem anderen Theme, das es gibt. Unter Docs > Templates > New template system erhält der verwirrte Novize in der Theme-Erstellung die Erklärung für diese Diskrepanz: anfang diesen Jahres “haben wir eine vollständige Neu-Implementierung ausgeführt, wie Go Templates in Hugo gehandhabt werden”, informieren uns die Hugo Entwickler und fahren fort: “Wir arbeiten an einer vollständigen Überholung der Dokumentation zu diesem Thema.”

Soweit ich erkennen kann, ist diese vollständige Überholung der Doku bisher nicht erfolgt. Der Umbau bringt einiges an Verwirrung mit sich, was die Benennung zentraler Ordner und Dateien angeht, die umbenant, umstrukturiert oder vollständig entfernt wurden und was die Nichtübereinstimmung mit der Art erklärt, wie alle anderen Autoren bisher ihre Hugo Themes strukturiert haben.

Das ist kein Einzelfall, scheinbar sind Umbenennung und Benennung allgemein eine wiederkehrende Quelle der Verwirrung in der Doku, zumindest für Anfänger. Ich lade jeden dazu ein, sich selbst ein Bild zu machen, indem man die verschachtelten Karten durchläuft und versucht herauszufinden, was der Unteschied zwischen Docs > Functions > time > time.Format und Docs > Methods > Time > Format ist und warum der erste Eintrag uns sagt, dass wir die Operation .Date | time.Format ausführen müssen, während die zweite Quelle uns ein Beispiel gibt, wie man direkt .Date.Format ausführt. Oder was genau damit gemeint sein könnte, wenn Docs > Functions > global > site erläutert “use the site function to return the Site object” und zwar so: site.Params. Aber für den Fall, dass das Site object in einem Kontext ist, könnten wir auch die Site property des momentanen Kontexts folgendermaßen nutzen: .Site.Params. Für einen Template Kontext wiederum so: $.Site.Params. Noch irgendwelche Fragen?

Ein persönlicher Favorit von mir und Anwärter auf einen Award für obskure Benennung ist die lang.Translate Funktion, die man auch mit dem Alias i18n ausführen kann (was immerhin noch eine gebräuchliche Abkürzung für “internationalization” in der Softwareentwicklung ist), oder - für maximal kryptischen Code - einfach auch als T. Man wird über alle Benennungen in verschiedenen Themes stolpern. Tatsächlich war “T” bereits in dem Code-Schnipsel zu sehen, den ich oben geteilt habe. Viel Erfolg beim Durchsuchen der Doku nach “T”, wenn man als Noob dieser Funktion zum ersten Mal begegnet!

3.2 Ringen mit der Go Syntax

Ein paar Worte zu Go. Insgesamt bin ich positiv angetan von dieser Sprache, sie wirkt interessant und so, als ob sie Spaß macht. Außerdem kann man nicht abstreiten, dass sie schnell, effizient und leistungsstark ist. Jedoch muss ich sagen, dass die Go Syntax die spezifisch in den Text & HTML Paketen verwendet wird, eindeutig Lesbarkeit für Kürze austauscht.

Der mit Abstand schlimmste Übeltäter ist der “Punkt”, der die momentane Kontext-Variable anzeigt - was bedeutet, dass sich seine Bedeutung natürlich je nach Kontext verändern kann. Man kann sich den Punkt als “element” aus einer Map-Methode von JavaScript denken, oder vielleicht sogar noch passender als das “this” Schlüsselwort einer Java Klasse. Standardmäßig bezieht sich der Punkt auf die momentane Seite, so dass .Title selbsterklärend ist. Wenn wir allerdings die Funktion with .GetTerms "tags" ausführen (dieser Code gibt uns eine Liste aller Schlagwörter der Seite zurück und prüft gleichzeitig, ob überhaupt welche gesetzt sind), bezieht sich der Punkt ab jetzt in diesem Kontext auf die Liste der Schlagwörter. Deswegen können wir jetzt diese Liste durchlaufen, indem wir einfach range . ausführen und innerhalb dieser Schleife bezieht sich der Punkt auf das Schlagwort der momentanen Iteration und wir können seinen Namen aufrufen, indem wir .Title nutzen.

So weit, so gut, das ist ja noch nicht allzu schlimm, wenn man den Bogen einmal raus hat. Aber sobald man komplizierteren, verschachtelten Code schreiben und sich auf den Punkt verlassen muss, wird der Code schwer zu lesen und unnötig verwirrend. Früher oder später wird man unweigerlich den Überblick verlieren, auf welchen Kontext sich der Punkt momentan bezieht.

Das beste Beispiel dafür ist meine Funktionalität für den Sprachenwechsel, die dynamisch auf die übersetzte Version von derjenigen Seite verlinkt, auf der der Nutzer sich gerade befindet. In meinem Theme habe ich extra einige Hilfsvariablen gesetzt, um den Code für dieses Element lesbarer zu machen, aber um des Beispiels willen habe ich diesen Code so umgeschrieben, dass er wieder in seiner “ursprünglichen Natur” ist, ohne Hilfsvariablen. Dann sieht er so aus:

{{- if gt (len site.Languages) 1 }}
  <div>
    <ul>
    {{- range site.Languages }}
      {{- if ne .Lang $.Lang }}
        {{- $targetPage := index (where site.Home.Translations "Lang" .Lang) 0 }}
        {{- with index (where $.Translations "Lang" .Lang) 0 }}{{- $targetPage = . }}{{- end }}
        <li>
          <a href="{{ $targetPage.RelPermalink }}">
            <img
              src="/flags/{{ $targetPage.Lang }}.svg"
              alt="{{ $targetPage.LinkTitle }} ({{ or $targetPage.Language.LanguageName $targetPage.Lang }})"
            />
          </a>
        </li>
      {{- end }}
    {{- end }}
    </ul>
  </div>
{{- end }}

Wegen all den unterschiedlichen Kontext-Blöcken, von dem globalen Seiten-Objekt hin zum verschachtelten Kontext der range Schleife, den if und with Kontexten auf die sich die verschiedenen Punkte, Punkt-Lang, Dollar-Punkt-Lang beziehen, wäre es sehr verwegen, behaupten zu wollen, dass das hier intuitiver Code ist, der sich leicht lesen und pflegen lässt.

Es handelt sich hier auch nicht um ein böswillig konstruiertes, obskures Beispiel mit absichtlich schlecht gewählter Benennung von Variablen und vorsätzlichem Ignorieren von Best Practices, das ich nur zur Verdeutlichung frei erfunden hätte. Weit gefehlt, die Tatsache, dass ich benannte Helfer-Variablen definiert habe ist die Ausnahme von der Regel, denn Code wie dieser hier ist keine Seltenheit, wenn man Hugo Themes durchstöbert. Das Paradebeispiel: die Hugo Entwickler selbst schreiben solchen Code, wie man am Code vom Grundgerüst-Theme für das Navigationsmenü erkennen kann, den ich weiter oben geteilt habe (der mit dem “T”, unter anderem). Solchen Code schreiben und lesen zu müssen, ist eine Qual und abschreckend für jeden, der versucht, sich in Hugo einzuarbeiten. Das muss man ganz klar so sagen.

3.3 Lernressourcen

Obwohl Hugos Dokumentation nicht anfängerfreundlich ist, wird man schlussendlich dennoch finden, wonach man sucht, wenn man lange genug sucht. YouTube Videos kann ich nicht als eine gute Lernressource empfehlen, weil die meisten Beginner/Tutorial/Guide Videos den einfachen Weg gehen und einfach nur zeigen, wie man ein vorgefertigtes Theme installiert und mit den eingebauten Funktionalitäten arbeitet. Die seltenen Videos, die hilfreiche Details und ausführlichere Informationen bieten, sind leider schon recht alt und damit nur bedingt nützlich.

Im Gegensatz dazu empfehle ich, sich auf dem offiziellen Hugo Forum nach Hilfe umzusehen. Die Mehrheit der Hugo Community ist Neulingen gegenüber einladend und hilfreich, soweit ich gesehen habe. Dort kann man immer um Hilfe bitten und Antworten zu fast jedem Thema finden. Tatsächlich musste ich nie selbst Fragen stellen, da die Suche nach vorhandenen Threads, wo ein Problem das ich hatte bereits beschrieben und gelöst worden war, fast immer von Erfolg gekrönt war. Allerdings besteht auf dem Forum natürlich ebenfalls das Problem, dass man über veraltete Informationen stolpert.

Die abschließende Ressource, um zu lernen, wie Hugo funktioniert, habe ich bereits erwähnt: andere Themes. Am besten wählt man ein paar, die gut aussehen und geradlinig und nicht zu kompliziert scheinen und versucht dann, deren Code zu verstehen. Man sollte nur darauf gefasst sein, verwirrende Benennungen/Alias zu finden, ebenso Ansätze die veraltet sind und nicht länger empfohlen werden oder in der Doku enthalten sind. Aber insgesamt kann es ausgesprochen hilfreich und aufschlussreich sein, zu sehen, wie jemand anderes eine Funktionalität umgesetzt hat, die man selbst einbauen möchte - oder auch nur einfach, wie ander ihre Themes strukturieren.

4. Fazit

Ich habe mich mehr als einmal gefragt: wer ist die Zielgruppe für Hugo? Ich bin mir immer noch nicht ganz sicher.

Ein perfekter Kandidat fällt mir ein: für jemanden, der einfach nur so schnell wie irgend möglich mit einer Seite live gehen und Beiträge veröffentlichen will, während er keinerlei Interesse an Personalisierung seiner Seite hat, wäre Hugo definitiv eine sehr gute Option. Egal ob mit Programmierkenntnissen oder ohne, solange man nur schriftlichen Anweisungen folgen und die Befehle aus Hugos Schnellstart Anleitung kopieren&einfügen kann, ist alles innerhalb von ein paar Minuten bereit, ohne dass man je eine einzige Zeile Code anfassen oder schreiben muss.

Ich würde allerdings vermuten, dass so gut wie jeder seiner eigenen Seite zumindest eine kleine persönliche Note geben möchte, um sie, nun ja, zu seiner eigenen Seite zu machen. Hier würde ich dann zwischen drei Arten von Nutzern unterscheiden:

Keine oder sehr wenig Programmiererfahrung: für diese Gruppe kann ich Hugo nicht empfehlen. Oder vielleicht hätte man es durch einen “unbelasteten” Hintergrund und Herangehensweise einfacher, zu lernen, wie man mit Hugo arbeitet und Anpassungen vornimmt? Wer weiß. Tatsächlich habe ich einen Artikel von einer Dame ohne IT-Hintergrund gefunden, die in der Tat selbstständig und erfolgreich ihre eigene Hugo Seite erstellt hat. Diese Aufgeschlossenheit und das Ausmaß der Entschlossenheit, zu lernen, ihre Motivation und Bereitschaft, die Komfortzone zu verlassen und sich selbst anzutreiben, sind ausgesprochen bemerkenswert und ehrlich erstaunlich, großen Respekt an sie! Aber nach meiner Erfahrung, ist sie eine klare Ausnahme. Die Mehrheit der Leute ohne IT-Hintergrund - und sogar eine bedeutende Anzahl von Menschen in der Softwareentwicklung - hätten weder die Geduld noch das Verlangen, so viel Zeit und Aufwand in ein Werkzeug wie Hugo zu investieren, das von vielen als “nicht benutzerfreundlich” und “unzugänglich” wahrgenommen werden würde, im Vergleich zu dem, was sie kennen und gewohnt sind. Wer mich durch sein Beispiel eines Besseren belehren möchte, ist mir herzlich willkommen! Das fände ich sogar großartig. Wenn also ein Leser/eine Leserin Interesse an Hugo, aber keine Programmiererfahrung hat, dann bitte ich inständig darum, sich nicht von meinen Ausführungen abschrecken zu lassen, sondern Hugo auszuprobieren!

Programmiererfahrung, aber nicht in der Frontend Webentwicklung: es kommt darauf an, wie sehr man das Aussehen seiner Seite anpassen möchte. Wenn jemand sich gut mit Go auskennt, wird es ihm oder ihr natürlich leichtfallen, mit den Templates zu arbeiten. Aber man kommt nicht darum herum, auch einige Grundlagen von CSS zu lernen (und vielleicht auch von JavaScript, je nachdem, was man für Ansprüche an seine Seite hat). Wer weder Erfahrung in noch Neigung für CSS hat, wird keinen Spaß daran haben, seine Webseite zu personalisieren, da kein Weg an CSS vorbeiführt. Das gilt natürlich auch für andere Generatoren von statischen Webseiten, solange man keine vorgefertigten Themes so nutzt, wie sie von Haus aus sind. Frustmomente beim Styling sind vorprogrammiert, wenn man das Design seines gewählten Themes durch scheinbar kleine Änderungen im Stylesheet zerschießt und zur Verkörperung des Memes “Wie zentriere ich ein div” wird. Außerdem stellt sich die Frage, wenn diese Gruppe sich schon in Grundlagen der Webentwicklung einarbeiten muss, ob es dann nicht auch für sie empfehlenswerter wäre, mit den wesentlich gängigeren und verbreiteteren Werkzeugen der modernen Webentwicklung zu arbeiten, also mit modernem JavaScript und dem Ökosystem, das sich darum gebildet hat.

Erfahrung in der Frontend Webentwicklung: jemand aus dieser Gruppe wird wahrscheinlich, so wie ich, anfangs etwas an Go zu knabbern haben, aber ansonsten sollte es keine Probleme geben. Allerdings kann ich mir nicht vorstellen, dass Webentwickler die anvisierte Zielgruppe für Hugo sind. Meiner Erfahrung und den den Personen nach zu urteilen, die ich aus diesem Feld kenne, würde die überwältigende Mehrheit der Webentwickler ohne eine Sekunde zu zögern ein JavaScript-basiertes Framework wählen. Und dabei noch nicht einmal ein optimiertes und schlankes, wie Astro oder 11ty. Das ist einfach das, womit alle am besten vertraut sind, die Herangehensweise “nutze JavaScript überall und für alles” ist es ja, was erst zum Aufkommen von Node.js, JSX und sogar auf JavaScript basierendem Styling geführt hat. Die Möglichkeit, mehrere dutzend npm Pakete für sein Projekt zu installieren, wird von den meisten Web Dev Enthusiasten eher als Vorteil denn als Belastung gesehen und die Datengröße von Seiten sowie die Menge von JS code im Browser gering zu halten, fällt in “der Industrie” bedauerlicherweise oftmals unter ferner liefen. Wie dem auch sei, Hugo hat jedenfalls in Webentwickler-Kreisen nie den großen Durchbruch geschafft.

Der große Durchbruch ist allerdings nicht nur unter Webentwicklern ausgeblieben: als kleinen Test habe ich mal nach “migrating from Hugo to Astro” gegoogelt. Diese Suche führt zu vielen persönlichen Erfahrungsberichten als Ergebnis. Das ist bedauerlich, aber keinesfalls unerwartet und stützt meine Einschätzung, dass Hugo “zu viel verlangt” und “zu viel Aufwand” für die meisten Leute bedeutet, sowohl für solche mit Programmiererfahrung, als auch für die ohne. Die Dame ohne IT-Hintergrund, die sich erfolgreich auf dem Weg, selbstständig ihre eigene Hugo-Seite zu erstellen durchgekämpft hat, hat Hugo inzwischen übrigens auch für den Webseiten Erstellungsservice Webflow verlassen.

Damit bleibt mir also nur diese Antwort auf die Frage “Wer ist das Zielpublikum für Hugo”: abgesehen von Entwicklern mit Erfahrung in Go, ist wahrscheinlich für diejenigen eine gute Wahl, die effizienter, minimalistischer und robuster Software und Seiten große Bedeutung zumessen, die volle Kontrolle über ihre Seite haben und jeden Aspekt davon selbst anpassen wollen und die bereit sind, die Zeit und den Aufwand ins Lernen zu investieren. Für wen sich das gut anhört, dem kann ich nur empfehlen, Hugo einmal auszuprobieren. Diese Anforderungen erfüllt es nämlich und ist außerdem ein leistungsstarkes und vielseitiges Wekrzeug, wenn man es gemeistert hat.

Für alle anderen kann ich Hugo nicht guten Gewissens empfehlen, so leid es mir tut. Aller Wahrscheinlichkeit nach werden die meistens es nicht nur wesentlich einfacher, sondern auch mehr Spaß mit einem Werkzeug wie Astro haben, mit dem sie fast gleichwertige Resultate mit weniger Umständen und Kopfzerbrechen erreichen können. Dazu würde man auf diese Weise auch noch Einblicke in die Standards der modernen Webentwicklung gewinnen und moderne JavaScript Syntax kennenlernen, sowie die Werkzeuge wie Node.js und npm, die sich darum herum gebildet haben und die die Industrie dominieren.

Was mein persönliches Fazit angeht: meine Webseite mit Hugo zu erstellen, hat mich wesentlich mehr Zeit gekostet, als ich ursprünglich erwartet hatte. Die Reise verlief nicht immer glatt und war mit frustrierenden Momenten gewürzt. Dennoch bin ich froh, dass ich meinen Entscheidung durchgezogen habe, da ich Zeit, die man dafür investiert, etwas Neues zu lernen, immer für gut investierte Zeit halte. Das Gelernte lässt sich fast immer vom Spezifischen auf allgemeine Probleme übertragen. Und die Beschäftigung mit Hugo (und Go) war für mich eine Gelegenheit, etwas Neues auszuprobieren und ein interessanter Blick über den Tellerand des Gewohnten und Altbekannten, was die Webentwicklung angeht.

Mit dem Endresultat, meinem Theme Argo, bin ich sehr zufrieden: mir gefällt (offenkundig) wie mein Theme aussieht und ich habe damit eine schnelle, effiziente und saubere Seite, mit allen Funktionalitäten, die ich wollte. Die dynamischen Links zu den übersetzten Versionen der jeweiligen Seite miteingeschlossen, allen Syntax-Wirrnissen zum Trotz. Einfach mal auf die Flagge klicken und schon kann man diesen Artikel auf Englisch lesen! Und wenn ich jetzt irgendetwas an meiner Seite ändern möchte, neue Features einbauen oder etwas umbauen möchte, weiß ich genau, wo ich ansetzen muss und was ich tun muss. Die Seite gehört wirklich ganz mir, jeder Teil von ihr. Und das ist mir sehr viel wert.