27.10.2021 |

Hugo - der bessere Generator für statische Webseiten?

Hugo ist ein Werkzeug zum Bauen von statischen Webseiten, welches auf der Programmiersprache Go beruht.

Solche static site generators eignen sich besonders für Inhalte im Netz, welche sich nicht innerhalb kurzer Zeit ändern oder auf Benutzerinteraktionen angewiesen sind. Typische Anwendungsbeispiele sind Weblogs oder klassische Webseiten, z.B. sogenannte "landing pages". Anders als bei dynamischen Seiten wie Twitter oder Facebook will der Benutzer hier dokumentenartigen Inhalt konsumieren, muss aber nicht durch "likes" oder ähnliche Mechanismen mit der Webseite interagieren.

Der Vorteil von statischen Webseiten ist die Auslieferung und die Performance. Der Benutzer braucht in der Hauptsache nur klassisches HTML für die Seitenstruktur und CSS für den Look der Seite. Eine Anreicherung durch JavaScript für dynamische Inhalte ist möglich, ist aber nicht der Hauptanwendungszweck.
Solche statische Webseiten brauchen nur eine geringe Datenmenge und kommen daher schnell beim Benutzer an.
Auch kann man solche Seiten über ein content delivery network über verteilte Datenzentren in der Welt kostengünstig in Produktion bringen.

Erfahrungen mit Hugo

Beim Umbau meines persönlichen Weblogs konnte ich Eindrücke von Hugo sammeln.

In meiner Anfangszeit als Bloggerin habe ich das Framework Gatsby benutzt, welches auf JavaScript bzw. dem Frontend-framework React.js fußt. Gatsby bietet viele Vorteile, insbesondere ein reichhaltiges Plugin-Ökosystem. Mit GraphQL im Serverbereich lassen sich externe Daten laden, welche ich dann in meine Seite einbauen kann.
Leider ist Gatsby auch schwergewichtig und langsam. Zudem ist JavaScript notorisch schnelllebig, sodass es häufig zu notwendigen Update-Arbeiten und Problemanalysen bei kaputten Abhängigkeiten kommt.

Ich bin daher in 2019 auf Hugo umgestiegen. Da Hugo hinter den Kulissen Go benutzt, ist es extrem schnell. In meinem Fall konnte ich die Bauzeit meiner Seite von über 7 Minuten mit Gatsby auf 26 Sekunden mit Hugo reduzieren.

Go ist zudem eine sehr stabile Programmiersprache, für welche Abwärtskompatibilität ein erklärtes Ziel ist. Der Wartungsaufwand eines Hugo-Projektes ist somit sehr gering. Nun kann ich mich auf das Schreiben meines Blogs konzentrieren, anstatt mich mit der Pflege des Frameworks zu beschäftigen.

Da Hugo seit 2013 existiert und sich ein zuverlässiger Kern von Projektverantwortlichen und Beitragenden gebildet hat, sehe ich auch die Zukunft der Software nicht in Gefahr. Hugo ist Open-Source unter der Apache License 2.0 und damit frei verfügbar.

Ein weiterer Vorteil sind die eingebauten Features. Hugo kommt von Haus aus mit breit gefächerten Bordmitteln. So ist es auf einfache Art und Weise möglich, Seiten zu nummerieren, ähnliche Inhalte anzubieten, Daten von Fremdquellen einzubauen, Twitter Cards oder OpenGraph Bilder zu erstellen usw.

Gerade das Anbieten von ähnlichen Inhalten ist in vergleichbaren Frameworks wie z.B. Eleventy durchaus aufwendiger und erfordert es, dass ich selbst Logik schreiben muss. Bei Hugo bekomme ich diese Funktionalität kostenlos. Über Einstellungsmöglichkeiten kann ich angeben, wie Inhalte gruppiert werden sollen. Das bedeutet, dass ich festlegen kann, dass Blogartikel mit der gleichen Kategorie mit hoher Priorität angezeigt werden sollen, während Artikel mit ähnlichem Datum mit geringer Wichtigkeit gewertet werden.

Natürlich gibt es nicht nur positive Aspekte.

Go als Grundlage bedeutet auch, dass man die Hu(go) Templating Sprache benutzen muss, um seine Seite zu bauen.

Leider ist die Hu(go) Templating Sprache nicht intuitiv. Leute ohne Go-Erfahrung stolpern da schnell über Fallstricke. Insbesondere der Kontext, in welchem Go Funktionen in Templates ausgeführt werden, kann bei komplexen Fallgestaltungen mit partiellen Templates zu Fehlern führen.
Die zur Verfügung stehenden Variablen, mit denen man bei Hugo arbeiten kann, sind für einen Anfänger erschlagend und erfordern ein gründliches Studium der Dokumentation.

Im Gegensatz zu Gatsby oder Eleventy ist die Einstiegshürde daher gerade für Frontendentwickler höher.

Hugo setzt mit dem Ansatz der Templates auf eine Herangehensweise, die Backend-Entwicklern vertrauter sein sollte. Anders als bei Gatsby oder Astro arbeitet man nicht mit Komponenten. Das kann es teilweise schwierig machen, wiederverwendbare Dateien zu entwerfen, ohne verschachtelte Templating-Logik zu schreiben.

Des Weiteren ist die Dokumentation zwar ausführlich, jedoch verwirrend. Hugo benutzt viele Begriffe, die gleich oder ähnlich klingen, jedoch Unterschiedliches darstellen.

Ein Beispiel:
Wenn man statische Resourcen benutzen will, so benutzt man die Funktion resources.Get "scss/main.scss" um Dateien aus dem "assets"-Ordner zu laden. Es gibt allerdings neben den globalen Assets auch Page Resources (Resourcen spezifisch zu der einzelnen Seite). Diese befinden sich nicht im globalen assets Ordner, sondern in dem Ordner, in welchem sich die Datei befindet, welche die Seite (Page) darstellt. Solche Resourcen kann man mit .Resources.GetMatch auslesen.
Solche Ähnlichkeiten machen es einem Neueinsteiger sehr schwer.

Beispielscode

So sieht ein Beispiel eines partiellen Templates für den HTML head aus, bei welchem wir Hugo pipes benutzen, um die Sass Dateien in CSS umzuwandeln und zu optimieren.
Wir benutzen ebenfalls interne Hugo templates für Extras wie Twitter Cards.

{{- $critical := resources.Get "scss/critical.scss" | resources.ToCSS }}
{{- $fonts := resources.Get "scss/fonts.scss" | resources.ToCSS | resources.Minify | resources.Fingerprint }}
{{- if hugo.IsProduction }}
{{- $critical = resources.Get "scss/critical.scss" | resources.ToCSS |  resources.PostProcess | resources.Minify | resources.Fingerprint }}
{{- end }}
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <meta http-equiv="X-UA-Compatible" content="ie=edge" />
  <link rel="stylesheet" href="{{ $critical.RelPermalink }}" />
  <link rel="stylesheet" media="print" href="{{ $fonts.RelPermalink }}" onload="this.media='all'" />
  <title>
    {{ if not .IsHome }}{{ with .Title }}{{ . }} | {{ end }}{{ end }}{{
    .Site.Title }}
  </title>
  <meta
    name="description"
    content="{{ with .Description }}{{ . }}{{ else }}{{ with .Summary }}{{ . }}{{ else }}{{ .Site.Params.description }}{{end }}{{ end }} "
  />
  {{ template "_internal/opengraph.html" . }}
  {{ template "_internal/twitter_cards.html" . }}
  {{ template "_internal/schema.html" . }}
</head>

Zusammenfassung

Hier also einige Vorteile zusammengefasst:

  • Schnelligkeit beim Kompilieren
  • Stabile Plattform
  • Open-source
  • reichhaltige Funktionalität
  • ausführliche Dokumentation und dediziertes Forum für Troubleshooting
  • viele frei erhältliche Themes aus der Community

Nachteile von Hugo:

  • hohe Einstiegshürde
  • hässliche Templating-Sprache, die unintuitiv ist
  • verwirrende Begrifflichkeiten
  • Modularisierung ist schwieriger als bei komponentenbasierten Frameworks

Hugo ist sicherlich nicht der bessere Generator, aber ein anderer. Hier muss man sicherlich überlegen, welche Kriterien einem wichtig sind und welcher Use Case beim Bau der Seite vorliegt.

Zur Übersicht
Sophia Brandt

Mehr vom Devsquad...

Hendrik Janßen

CHECK Constraints in Postgres

Jörg Herbst

State handling mit ngxs in Angular

Hallo, ich bin Jörg Herbst!

Ich bin der CEO von newcubator und freue mich über jede Nachricht!

* Pflichtfeld