Moving to Hugo
I have so far avoided the typical “here’s my blogging tech stack” post that is then followed by the silence of not writing another post for several months.
But you know what? Here it is anyways.
Leaving Wordpress
I have been a Wordpress user since 2006 or 2007. And I‘ve always been a fan. Still am, in a way.
The fact that the Wordpress instance I installed circa 2010 still self-updates 15 years later without any hiccups is impressive. I also think the Gutenberg block editor for posts and pages is excellent.
Still, at the beginning of this year, I had an itch for something new, something more developer-friendly with a plainer approach.
More than a blog
I also wanted to broaden the content: Don’t limit myself to a linear blog, but instead start moving towards a digital garden, a more personal space with different non-blog sections.
Choosing Hugo
I ended up choosing Hugo: A fast static site builder written in Go, a language that I am partial to since I’ve started working with it last year.
You do, in fact, not write any Go to create a website with Hugo, but at least the templating syntax was familiar.
So here’s the gist:
A minimalist Hugo setup
I‘ve pretty much created the entire theme and site from scratch. No frameworks, no preprocessing pipeline. Just plain CSS and a tiny pinch of JavaScript.
Site features I’ve built
Blog posts and content is written in Markdown. My creativity doesn’t flourish in code editors, so I write it in a different environment first. This post was written in the notes app of my iPhone while in bed at 6 am. Markdown came later.
The blog section shows posts grouped by year. Not the prettiest templating code to achieve this. Don’t tell anyone.
Auto-generation of share images for posts and pages (specifically as an og:image). If you’ve seen the link to this post in a messenger or social network, you will have seen the generated image. Thanks to Aarol, whose solution I used as a starting point.
A section to share my photos, currently grouped in albums with a bit of meta data. The photo slideshow is the only place on the website that uses JavaScript.
I built different photo album layouts to choose from (single column and multi-column).
A reading section, auto-generated based on my Lesetagebuch profile data.
An about page, styled as a kind of CV. This isn’t a single huge html file. Instead it’s based on local json data of my previous positions, my publications and projects. I have migrated this page from WordPress where it was built using the block editor. Creating these one-off page layouts in the WordPress editor has a convenience that’s hard to match in a code-only setup, I have to say.
Publishing workflow
The website code lives inside a Github repository. Every push to the main branch triggers a Github action that compiles the entire site and uploads it via FTP to my webspace.
When I work on a new blog post or website feature, I create a pull request. This causes the same Github action to trigger, but it now publishes the site to a staging environment, i.e. to a different subdomain.
The site is also rebuilt each night. This is required for the reading page which consumes an external API to render. New books appear the day after I’ve logged them.
These build triggers may sound excessive, but they’re not.
Because Hugo is so fast, each build of the entire website takes around two seconds, the Github action runs for roughly 30 seconds.
All combined, I’m not using more than 30 to 60 minutes of Github action minutes in a full month. This is well inside Github’s free quota.
I moved to Hugo and I liked it
So here we are. I moved from WordPress to Hugo and I liked it.
Let’s see if this technical summary indeed remains the most recent post on the blog for an embarrassingly long time. Ideally, I’ll embrace the idea I had for this website in the first place: be more casual about the writing experience and not wait for a big topic till I consider publishing.
Maybe even writing about my blogging tech stack is fine for a change.