Moving to Hugo

What I was using

This site was completely manually maintained, just editing raw HTML in a text editor. Whilst initially this was manageable, it quickly became annoying to make changes. Making a change that affected the entire site was especially tiresome as I would have to go through every file and make modifications. This is obviously not sustainable and before long I stopped updating the website altogether. My last update is probably a few years old now.

The thought experiment

In the last few months, I was thinking about my website again. I was wondering how hard would it be to create a Python script that given a bunch of “Page” objects would spit out all of the html content. This would give me the ability to introduce components that could be reused across the site and allow making modifications to a shared component much easier.

It turns out that I’m just very slow. The idea I had dreamt up was basically a static site generator, and as it turns out, there are many of these available. This led me down the path of static vs dynamic sites, and after looking at the differences, it became clear to me that this website can function completely statically. Thus using a static site generator would completely suit my needs.

Why Hugo

Hugo is one such static site generator and is the one I decided to use. It boasts fast build times measured in milliseconds and customisable shortcodes that neatly lined up with my idea of having customisable components. There are other static site generators that I could have used; I just happen to pick Hugo first and I have enjoyed using and customising it.

I’m really happy with Hugo, but I’m sure if I had picked Jekyll or any other popular static site generator, I would have been just as happy. Any of these solutions are better than manually maintaining the files.

Hugo has a number of built in features that make management pleasant. Using markdown makes creating content much easier than writing raw HTML. Built in image processing means I no longer need to resize images manually. Native support for categorising and pagination makes including such features in a site trivial. And then there are the shortcodes.


Shortcodes are a shorthand for components that I can include in the content markdown, and I can pass parameters into it from the markdown. This is especially useful for complex pieces of html that I want to keep standardised across the site, but I have no means of doing it in normal markdown.

Hugo provides quite a few shortcodes out of the box. But Hugo also provides quite a lot of flexibility when it comes to creating custom shortcodes, and I’ve had a blast tinkering with custom shortcodes to get them to behave as I want.


Hugo also has got an amazing set of documentation, and includes a very easy to follow guide to deploying with Netlify. I was able to set up a private repository on GitHub and with only a few steps, Netlify was deploying on the master branch. Moreover it had setup webhooks so that whenever I push into master, it will automatically start a new deploy. The end result was easy to setup and easy to maintain.

Moving forward

My experience with Hugo and Netlify has been excellent. I hope now that creating new content is much more about the content and not managing other pages that I will be able to post new stuff more frequently.