Moving to Hugo
Have you ever had that feeling that perhaps (just perhaps) you were expending way too much time on something when you were almost certain there was a more efficient method? Did your familiarity or comfort with a tool cloud your judgement? Was your olfactory senses filled with pungent sunk cost fallacy?
Yes your honour, I plead guilty.
It all began about a month or so ago when I was wanting to fire up ye olde blog again, which was running on Drupal. Drupal, bless it’s massive heart, is a great system with much bell and whistle but when it comes to updating it can be a chore. This might consist of updating:
- PHP itself
- PHP libraries
- Drupal core
- Drupal plugins
- DB conflicts (rare)
- Infrastructure tooling
And that’s just locally on my machine. Depending on what updates were made, the hosting too might need updating. Best case, which is just running
composer update, could be looking at a few minutes. Worst case, a day or so and given my setup and how far behind everything was, it was going to be the latter.
So given that, I started to look around. It had been a while since I had peered over the blogging platform fence and specifically the dynamic vs static site generator divider and last time I hadn’t been that impressed. But it had been a quite while (years) since I had looked and what I found now looked… good – very good.
For those out of the loop, a dynamic site is one that generates everything on demand – it pulls the content probably out of a database, runs it through a bunch of code transforming it on the way and then shoves it into one or more templates for display. This happens every single time a visitor wants to view a page. Sure, you can put a cache in there, but the number of layers in the stack is the same. The most popular dynamic platforms such as Wordpress, Joomla and Drupal all run on PHP and with a database and can become very complex as they support all sorts of plugins that add extra functionality – and yes, that often opens up more attack vectors to be hacked aswell as more things to be maintained (as mentioned above).
In my case, what I needed included:
- categorisation using tags and series
- syntax highlighting of code snippets
- listings of pages and tags, pages that are in series
- publishing on a certain date
- posts and normal page content types
Sure I couldn’t log in to my site to do remote updates or just turn on a commenting system or even enable site search but neither did I really care about or need those things and there are SSG ways to do some of those that are “good enough”.
Last but not least, a website that is only bare HTML and CSS is fast. Optimisation is more or less a matter of paring down file sizes.
Given all that, an SSG ticked a lot of boxes - if you want to know more I suggest reading about the Jamstack .
When I started evaluating SSGs, I saw a couple of main types.
In the end I ultimately went with Hugo primarily because:
- maturity and well maintained
- it’s just a single binary
- very fast to rebuild the whole site – mere milliseconds
- great markdown with frontmatter support
- extensive documentation
- Go templating is well structured, powerful
From a high-level, once I made the decision to go with Hugo I did the following:
- clean up all existing content, export some missing items into markdown files
- make a new Hugo theme, roughly:
- start with a base template, get something showing
- scss setup and generating into css
- break the base template into post and single page templates
- create partial template for menus, headers and footers
- style everything out to match my previous Drupal theme including syntax highlighting
- mess around adding new features cos, you know, shiny things!
- figure out how to get it all on the web
- clean up and tweak everything
Overall I found the whole experience to be a blast. Here are my impressions/feels so far:
- Hugo requires a reasonable level of technical competency. You can probably get away with installing it and an off-the-github-shelf theme and start writing your posts in Markdown. However, if you want to do anything more than that you are going to have to learn some Go templating. Again, relatively straight forward if you are familiar with such things.
- Hugo has a built-in web server for local preview with live reload – I love it. You can have your text editor open in half the screen, your web browser on your local site on the other, hit save and see the changes right away.
- Did I mention that Hugo rebuilds the whole site in milliseconds – I’ll mention it again!
- Although the documentation is relatively complete, it can sometimes be hard to find exactly how something is done – I think an index of recipes and more how-tos beyond the Getting Started section would sort that out. Following on from that, some kind of “best practices” section would be fantastic.
- Hugo is a command line tool, again might be a non-starter for many
In the next post I’ll go through some tips and tricks and how to do certain things in Hugo that weren’t obvious to me at first glance.