Regardless of which analytics provider (if any) this site has ever used, it’s always been clear that a large percentage of searches that actually get here do so because of one particular post which I first issued three years ago today.
Of course, the title soon became unintentionally ironic, as I embarked on what I’d later ruefully describe as “the dance” among SSGs: notably, between Hugo and Eleventy, although a few others have crept into the mix in the ensuing years. Now, other than the site’s brief stint on Astro a few months ago, Hugo has once again become its mainstay. While I’ve continued to experiment with other SSGs, mainly in the background, I keep coming back to Hugo for many reasons, some of which have come into play for me only fairly recently.
Earlier this week, when I noticed that the post’s three-year anniversary was nearing, I spent some time re-reading it in detail. Here are some thoughts that brought to mind, especially as I compared what I wrote and knew then with what I sorta know now.
One of the main reasons I found the experience as harrowing as I described was because it was the first time I’d used anything in the Node.js ecosystem (other than in strictly controlled tutorials, that is). I was completely new to all the stuff that comes with the
package-lock.json files, and particularly the way a Node package’s performance and stability can live and die on the quality of its constituent dependencies. In time, I would become considerably more acclimated to — or, perhaps more accurately, less rattled by — this method of building and maintaining a project.
It was also the first time that I was using a bundler, namely the then-ubiquitous webpack, which was (and is) an integral part of Gatsby. Only months later would I even have a decent grasp on what a bundler is in the first place.
Old Joke Warning . . . While walking down a street one day, a fellow noticed another fellow repeatedly hitting the top of his own head with a hammer. Curious, Man #1 walked up and asked Man #2 why he was doing this. Man #2 replied, “Because it feels so good when I stop.” In similar fashion, I now understand even more clearly why, back in 2019, it was so satisfying to return to Hugo after that nasty first run at the world of JS-based SSGs.
When I compare the Hugo of mid-July, 2019, to what’s available today, it’s amazing how far the SSG has come. Back then, I’d have been using, at best, Hugo 0.55.6, released 2019-05-18. Since then, Hugo has added:
- Hugo Modules1 in 0.56.0, 2019-07-25.
- Better and faster Markdown parsing through the goldmark library in 0.60.0, 2019-11-27.
- Support for Dart Sass in 0.80.0, 2020-12-31.
- Support for processing WebP images in 0.83.0, 2021-05-01.
- The ability to fetch remote resources in 0.90.0, 2021-12-08 (with some enhancements thereto in 0.91.0, 2021-12-17).
- Even more build speed and more efficient memory usage — as if Hugo didn’t already pack both in sufficient quantity — in 0.94.0, 2022-03-10.
- Many improvements over time, in multiple versions, to Hugo’s built-in asset pipeline, Hugo Pipes. It now features code-bundling, further enhancements to its image-processing powers, and a lot more. For those unfamiliar with Hugo Pipes, let’s just say its performance/speed combination blows away webpack and Parcel, and even (IMHO) rivals the awesome Vite.
I’ve done plenty of complaining over the years about the Go-based templating in Hugo, and I still consider it sub-optimal if one isn’t prepared to spend a lot of time getting the hang of it.
However, it’s begun to grow on me somewhat. The difference between Then and Now is that I actually have spent the time.
Compared to how much tinkering I’ve done over the years with various other SSGs — including what I described in “Why I’m staying with Hugo” — I didn’t really get under the hood much with Hugo, and what its templating allows, until just the last seven or eight months. Having now invested that effort, I’ve gained an even greater understanding, and appreciation, of Hugo’s capabilities, as noted in a few posts I’ve written in that period:
- “Fetching remote stuff with Hugo 0.90+,” 2021-12-11.
- Several posts about doing fully static embeds of social media posts — which Hugo’s built-in
getJSONfunction makes easier than in JS-based SSGs2 — the most recent of which was “Static tweets in Hugo: an update,” 2022-06-07.
- “Responsive and optimized images with Hugo,” 2022-06-29.
Not only has it been three years since “Why I’m staying with Hugo”; it’s also been four years since the summer when I did the research which resulted in my choosing what then would’ve been Hugo 0.48 to create this website. The website is still here and (despite the iterations of the occasionally ongoing “dance”) it’s running on Hugo, albeit a far more capable version than 0.48.
While my wandering eye for New Shiny is something which always will be a factor, the last few months have given me greater appreciation for Hugo — and for staying with it.
Full disclosure: my only use of Hugo Modules so far was in a test I did earlier this year while writing a post for the CloudCannon blog about CloudCannon’s open-source Bookshop project, which works with a Hugo site via Hugo Modules. However, I know there are many Hugo users who consider Hugo Modules the proverbial “greatest thing since sliced bread” — and, for some use cases, that appears to be an apt description. It’s just that this site doesn’t need them, so I haven’t really bothered. ↩︎
That is, unless you just like futzing around with packages like node-fetch and axios. I’ve used both in Eleventy and Astro, and sometimes they’ve worked okay for me but other times they’ve constituted a major pain. (Async and I aren’t exactly the best of friends.) I have yet to run into similar agonies with
getJSON, which I’ve found far more forgiving than either node-fetch or axios. ↩︎