Blogging with Hugo

2020-05-13

Going static

This blog is statically generated from Markdown and AsciiDoc files. Compared to a full-fledged blogging platform, content stored as files is easily re-usable and transferable. Markdown flavors are natural to a software developer. And as it only requires cheap static hosting, performance is always great and maintenance is reduced to a minimum.

Blogging with Hugo

I rely on AWS S3 with CloudFront and LambdaEdge, a very cost-effective and infinitely elastic solution.

Going static is a sound advise for many websites.

After an early period with Dotclear, I switched to JBake. I appreciate the software, but it has become slow, and I have to fiddle with Java versions to make it run correctly. It is still a decent choice, but I decided to give Hugo a go (pun intended).

And yes, it is every bit as fast as advertised. Easy to install too. The engine is comprehensive, overwhelming even. Fortunately the documentation is good. There was a bit of a learning curve. By design, you are supposed to use git for installing a theme, which can be either convenient or a huge pain, depending on your background.

Go Hugo

On OSX, installation is trivial:

$ brew install hugo

Starting this post was as easy as:

$ hugo new content/posts/blogging-with-hugo.adoc
content/posts/blogging-with-hugo.adoc created

Let’s build the blog and serve it to localhost:1313:

$ hugo server -D

With fast hot reload of course. When the blog post is ready, I (re)generate the blog:

$ hugo

The output is located under the public folder, that you can deploy according to your hosting. In my case:

$ aws s3 sync ./public s3://blog.sugoi.be --acl public-read --delete \
--storage-class REDUCED_REDUNDANCY --profile youri --exclude .DS_Store
$ aws cloudfront create-invalidation --distribution-id ****** \
--paths '/*' --profile youri

Themes

Many themes are available. It took me three attempts to find one that suited me. The first one I tried had issues with the menu bar once I left the front page. The second one was not working out of the box, requiring me to download and install icons to some unspecified location, and even then, it was not working. The third one as you see it is ramium.

Hugo allows you to override fragments of the template, for instance head.html or navbar.html. In theory, this makes the theming process flexible, allowing you to update your local version with changes coming upstream from the author, while retaining your customization. But it does not work in practice. I ended up making many minor modifications in many files, so now my each of my local copies of a fragment overrides the original entierely. For instance, the theme uses a lot of | title to capitalize words, a feature I don’t care for. So I had to copy several files only to ditch capatalization. Instead, the author should have offered a property to capitalize or not (making the templating more complicated in exchange). Or maybe Hugo allows you to override a global function ; I haven’t been that far yet.

Similar remark with the CSS stylesheets. Theme authors should always provide an empty custom.css on top of their awesome_theme.css to make override easier. Here, I had to change awesome_theme.css, further loosing flexibility.

After a few tweks here and there, I am happy with the result: sobre, simple, altough my journey is not complete yet.