August 18, 2020 | 18:30
Reading-Time: ca. 6 Min

Please notice: This article is more than 3 years old
Content, Source code or links may no longer be correct in the meantime.

Hugo as Web-Developing Platform

Making of

At the beginning of the (first?) Corona lockdown in March 2020, I was advised during an nightly Jitsi meeting by a befriended admin from Hamburg about giving Hugo a chance. Probably just after I dropped a rant about Rapidweaver, my previous static site generator on the Mac.

The idea needed to grow for almost half a year, till August, when I finally found a test balloon for Hugo: My personal blog and if everything succeeds, my official website, which is slowly getting rusty.

Though I wouldn’t call myself a Hugo expert (yet), here comes a first insight, a making of and some of my considerations and challenges I had during the development in the recent days.

What’s Hugo?

Hugo is a Static Site Generator. In other words, all contents of a website are created locally on a development machine and then uploaded to a web server.

This makes it fundamentally different from the numerous online-based content management systems. Generally speaking, content management systems are regarded as a more advanced development and are used today by practically every advertising agency and companies for implementing websites. I find it quite difficult to follow this narrative. In many cases there is no way to talk of further progress. Especially when content management systems are often “misused” as a business application for something they were never created for.

First let’s look at the advantages and disadvantages of static site generators in general, Hugo in specific and my personal requirements regarding a website:


  • Hugo is free software with an active developer community.
  • It is available on all platforms (Linux, Mac, Windows)
  • Hugo creates Internet sites that can be operated server and technology independently throughout the Internet. No matter whether locally in your own network or on an arbitrary web server. Even the usual shared- or mass hosting systems are quite capable.
  • Maximum security is achieved by eliminating server-side generated pages and most importantly by reducing complexity on the operational web servers.
  • This also results in higher availability and better scalability, especially for critical or massive and simultaneous requested content.
  • Content can be maintained offline. An Internet connection is only required to transfer the updates. This is interesting for those who cannot be online permanently or who intentionally do not want to be (e.g. critical company departments), travelling employees with unstable mobile phone connections, and others.
  • Flexibility with the script language Go and the possibility to modularize a website into partials, bundles, templates and themes.
  • By using tags, the content can be catalogued and queried with Go. Hugo names such catalogues Taxonomies and allows the development of comprehensive archives of knowledge and databases of unstructured data.
  • Content can be created in the form of text files (markdown) by editors without programming knowledge. Numerous markdown editors for any platform allow undisturbed editing.
  • The interoperability of content (text files) and other assets (images, downloads) is provided by Hugo. There is no need to import or export content in a time-consuming and costly manner.
  • Regarding [internationalisation]( development)) i18n language files from translation platforms such as Weblate can be easily integrated and referenced within the code.
  • Complete freedom to design a workflow or process by yourself. Editorial content can, for example, come from a repository across a network and automatically be published on a website at predefined intervals, e.g. hourly or daily.
  • In combination with git as a version management system, large and comprehensive internet websites can be managed quite transparently. This is often one of the problems with many online content management systems.


  • The freedom to realize your own business processes is also a drawback. Many companies neither are able or willing to implement such a process and are quite happy to externalize the creation of a website in parts or as a whole.
  • There is no graphical frontend or a development tool comparable to the look and feel of other generators including Rapidweaver .
  • The learning curve at the beginning is steeper and a working environment has to be established on site, which is mostly not the case if you have an online content management system.

Actually I can’t name any more disadvantages. Have I forgotten any? Please give me feedback via email.

My requirements for a blog/ website:

  • no server-side scripts (e.g. PHP).
  • no client-side scripting (e.g. Javascripts)
  • no resources from third parties.
  • a sustainable, technological foundation (free software).
  • content must be separated from the design.
  • automated build and update process.
  • and last but not least: A minimalist, elegant and timeless design.

How this website was developed

As far as the design is concerned, I have chosen a appropriate theme from the theme gallery as a basis for further customization.

From a purely visual perspective I liked “Kiss Em” by Pavel Pi from the very first moment. He developed it as fork of the “Kiss” theme, which again is based on the theme “Hemingway”. I was not aware of the implications that resulted from this forking.

The installation of Hugo is straightforward. The first website with the theme created in a few lines and the config.toml quickly adapted. The tutorial by Thomas Leistner 1 has been very helpful to get started.

I used GNOME Builder as project and markdown editor.


The disappointment occurred with the sight of the first online tests and the requirement to get into theme customization much sooner than expected. In addition to the reported issues, there were of course colour adjustments and included webfonts as well as adjusted tap spacings of the navigation controls.

This is where it seemed a bit of a mistake to have chosen a three times fork as theme for the first steps. The search for the appropriate CSS style sheets was very time-consuming, as it was necessary to find the way through the numerous unused and yet inherited styles.

Also the partials had to be tackled. When I tried to add an English version to the already completed German language version, I noticed that it was constantly jumping back to the German version. The Hugo concepts and necessary Go statements haven’t been implemented in the theme. So I spent half of a day (with the typical interruptions) working on the English branch.



These experiences should not reduce the overall impression of Hugo. I look back to a couple of wonderful and productive days. Finally I have a modern blog now.

I especially like the possibility to use Go to perform previously complicated tasks quite smoothly. Here’s an example for Pipes:

{{ $style := resources.Get "css/main.css" | resources.Minify | resources.Fingerprint }}

<link rel="stylesheet" href="{{ $style.Permalink }}">

With Rapidweaver this required manually digging through the CSS with the yui-compressor after each build and creating the fingerprints of your own from the console.

A migration tool for Rapidweaver seems not to exist, but there are a lot of tools for other content management systems2.

Hugo as a static site generator is very powerful and can accomplish a job. And yes, I will use it for my official company website soon.

However, before that happens, I want to see my deployment workflow fully automated.

Your Tomas Jakobs

© 2024 Tomas Jakobs - Imprint and Legal Notice

Support this blog - Donate a Coffee