Hugo: The Power of Static Site Generators

I’ve needed to build a couple of websites recently, and with the need to keep things cheap, static sites are my preference. It helps that I am happy hand editing Markdown and YAML. For the site I am working on right now that might be a sticking point, but we will see how that falls out.

For the kind of site I am working on, I think the default would be a WordPress site, and that’s what I am migrating them from. I am not a fan of WordPress, however. Though it hasn’t had nearly as many security issues recently as it used to, it’s a jackhammer where a screwdriver is the right tool¹.

Why Static?

A static site is just a folder of HTML, CSS and images. There’s no database, no PHP, no admin login to brute force and no plugins to keep patched. The site generator does all the work on my machine (or in CI), and what gets uploaded can’t really be hacked in any interesting way.

It’s also cheap. Static hosting is free or close to it on plenty of services², and a folder of files will happily sit behind a CDN and cope with a sudden flood of visitors without anyone having to resize a server. Mostly I run these in small nginx containers on my VPS, so each site costs me nothing more till I run out of resources³.

The trade-off is that anything dynamic, like contact forms, comments or search, has to come from somewhere else: a small third-party service, a bit of JavaScript, or something like Pagefind building a search index at build time (which is what this site does⁴).

Why a Static Site Generator?

Partials, I don’t want to copy paste my hero into every page I write over and over and SSI is so old hat.

Not Just Blogs

People tend to think that Hugo is only for blogs, but it will work for plenty of other types of sites too. Sections, taxonomies, data files and page bundles give you a lot to build with, and the blog is just one way of putting them together. This site has a portfolio, a gallery and a CV that is rendered from a YAML file, as well as the posts.

What does get to be a pain is if you have a whole bunch of blocks you want to build your pages out of (a hero banner, a row of cards, a call to action and so on). You can use shortcodes, but these get unwieldy quickly, with big chunks of content stuffed into shortcode parameters, or nested shortcodes that are hard to read and easy to break.

I tend to end up with a lot of nested Markdown files instead, each with a short front matter explaining the block in use⁵. Something like:

1content/
2  _index.md
3  blocks/
4    01-hero.md
5    02-services.md
6    03-contact.md
7    index.md

1---
2block: hero
3image: shopfront.jpg
4---
5
6Some text that goes in the hero.

The page template then loops over the block files in order and hands each one to a partial named after its block. It works, and it keeps the content as Markdown, but it’s a lot of little files, and it’s not something I’d want to explain to someone who just wants to change their opening hours.

Why Hugo?

Honestly, I use Hugo because it’s the tool I am used to. I used to use Jekyll, but after it got very slow for a medium-sized blog I was working on, I moved away. I don’t know if it’s better now⁶.

Hugo is fast, it’s a single binary with nothing else to install, and it has image processing built in, which does a lot of the heavy lifting for the galleries on this site⁷. The templating language takes some getting used to⁸, and the error messages can be cryptic, but once you know where things live it gets out of the way.

Tools I Should Try

Being comfortable with one tool is a good reason to keep using it, but it’s not a good reason to never look at anything else. Here’s my list of things I should try:

• Eleventy: a JavaScript site generator that’s very flexible about templating languages.
• Astro: component based, which might suit the “build a page from blocks” style of site much better than Hugo does.
• Zola: a single binary like Hugo, but written in Rust and with Jinja-style templates.
• Jekyll again, to see if it has got any faster.

And for the sticking point of other people having to edit the site, something that puts an editor on top of the Markdown files:

• Decap CMS (previously Netlify CMS), which commits edits straight to the Git repository.
• Pages CMS, which does something similar with a simpler setup.
• Front Matter CMS, a VS Code extension, which is more for me than for anyone else.

Final Thoughts

I will post an update if the site goes ahead, so this is a bit of a naff ending to a post, but sometimes that’s how it goes when you start writing before you have a plan.