If you’re reading this, you’re probably viewing a version of my blog generated by Hugo (unless you’re reading this on gemini). If you’re not familiar with Hugo, I can assure you he’s not my smarter twin, who decided to rebuild my personal site for me.

Hugo is a static site generator developed in Go. I personally think it’s great because it’s easy, simple and fast.

Hugo has many other features that make it a solid, static site generator. I won’t cover them here as I wanted to elaborate more on the ones that weighed the heaviest in my decision to migrate away from my Jekyll personal blog.

Easy

Borrowing from its Go heritage, Hugo offers a streamlined, “batteries included” developer experience, with a useful range of tools included in the same binary out-of-the-box. You would expect to find many of these functions on any modern static content generator worth their salt, but Hugo adds a couple of nice touches which I like.

My favourite feature is the hugo deploy command. The site deployment functionality built into Hugo does what it says on the tin basically; it allows you to publish your Hugo site to most of the major blob storage providers rather easily: Google Cloud Storage, Azure Storage and crucially for me, Amazon S3.

The hugo deploy built-in won me over as I was not awfully impressed by my pre-existing publishing process. Previously, uploading new content to sgfault.com involved installing a tool in my system-wide Ruby package registry that I then I point at my Jekyll site to upload my content to a public S3 bucket. The tool is half-written in Java so it requires the JRE as well as the whole Ruby shebang to run. Furthermore, the tool is no longer maintained. It still works and I don’t really mind apps slowing down development if they’re deemed feature-complete, especially if they’re open source, but it’s just not that great on the whole.

Simple

Hugo is readily distributed as a package or as a standalone binary you can install yourself. That’s it, no dependencies required.

On the other hand, Jekyll websites are ultimately Ruby applications so you have to install quite a few things to get going with a somewhat functional website:

• all the Ruby gems (Ruby packages) you need to launch a Jekyll app, including Jekyll itself
• a gem manager like bundler to install and maintain your dependencies
• a Ruby interpreter
• RVM to manage all the different versions of said interpreter you’ll be upgrading through over the years so that you can keep up with the newer versions of your gems you’ll have to install to keep your site secure, if nothing else (because you’d never just deploy it one day and forget about the whole thing for years, would you?)

That’s a fair amount of moving parts just to build a simple static blog, and you haven’t even deployed the site yet! You’ll want to throw in some nice CI/CD pipeline for the smooth, publish-on-push services like Heroku or Netlify have gotten us all used to, right? Handwriting a bunch of HTML files yourself and gluing them together with some chewing gum and Bash scripts doesn’t sound too bad now, does it?

Fast

Hugo built this blog in about 240 ms on my 6 year-old, i7 laptop processor (less than 200ms on a builds.sr.ht Alpine build), whereas it takes Jekyll an average of 440 ms to achieve the same result. In the grand scheme of things, the difference is negligible, but Hugo is almost twice as fast nonetheless!

Lower build times also contribute to an even more immediate feel to the local editing experience than what I’m used to while live reloading is enabled on the Hugo dev server.

Conclusion

This is the third time I switch content generators for my website. It started with RefineryCMS, which provided too many features for my rather simple needs, at the expense of having more things lodged between me and the content I wanted to write. For my first migration, I decided to stick with the Ruby ecosystem and move over to Jekyll, which was a big improvement in many ways. However, leaner solutions have emerged over time, better suited around my needs. Now feels the right time to migrate again.

Overall, I’m really happy with Hugo. I was able to replatform, restyle and deploy this blog in a couple of days and build a CI/CD pipeline around it, which is something my old website lacked. This has reduced friction in my writing workflow and will encourage me to write more often. I may write a blog in the future explaining how I performed this last migration as it was quite a bit of fun to put it all together.