Gatsby after-action review, moved to Hugo
2020 was not a great year, for my blog, as for many other things. Part of the reason that I’ve got so little written the last few years is my 2018 choice to reimplement the blog with Gatsby.js, so here’s a little review.
Maintenance burdens
My motivation to write is always a bit fickle, and 2020 was an exceedingly stressful year, but a different hurdle. In December 2018, I moved the blog to Gatsby, and while that is a very powerful tool for building web sites, it is a bit heavy for an occational blog. To illustrate, here’s a dependency count
npm ls | sed '/deduped$/d' | wc -l
2531
That is not atypical for a big fancy JavaScript application, the npm ecosystem being very lively and fond of having many dependencies. But for a small side project like this blog, it quickly turned into a huge maintenance burden.
Every time I’d want to update the blog, there would be updates for a whole bunch of these npm packages, and I’d have to spend time figuring out what the updates meant for my site, if I’d have to change my glue-code to work with the new library versions, and then manually test if everything still worked.
Since Gatsby is split into many different packages, many written by separate developer teams, there’s generally no guarantee that the package combination any particular Gatsby site is using has been tested to work together, so the upgrade process was always a bit paranoia-inducing.
And since the HTML/JS/CSS output of the static generators in Gatsby includes many of these npm packages, you kinda have to keep current with the security updates.
So long story short, running a Gatsby site involves a good deal of maintenance work. This is the kind of work I do for a living, so while not beyond my abilities, it is not exactly what I want to be doing in my spare time.
Hugo, in comparison, ships as a single (go-lang powered) binary, that I’ve installed through Homebrew, so I get the latest version automatically alongside the Homebrew updates I install regularly.
Hugo does have its own dependencies, but because it is shipped as a pre-packaged application, I do not have to manage them myself. I just have to read the Hugo release notes to see if there’s anything I need to worry about, which there usually isn’t, since my usage of Hugo is very close to the standard Hugo blog setup. And since the site Hugo generates for me contains no JavaScript, the need to keep it up-to-date is much smaller.
Real static HTML
Whereas Gatsby generates a static site, the output is very JavaScript heavy, using React.js and many other libraries on the page.
Hugo, on the other hand, has no on-page JavaScript, making the generated site much simpler. Not a huge deal, but a nice benefit.
I’ve moved away from React.js
When I switched to Gatsby in 2018, I was still using React.js for Ablis, and it looked like we were going to use React heavily at work.
Since then, Ablis has been rewritten in Elixir, using Phoenix LiveView and is thus no longer using React.js, and at work we ended up using Vue.js instead, so this blog was my only remaining React.js project, so keeping current with React.js was not the best use of my time, so it was nice to remove that need.
Unlike Gatsby, where you need to use React heavily to build stuff, in Hugo you do not have to learn much Go to customise things.
Conclusions
While I have outlined my reasons for moving away from Gatsby above, I do not mean to say that Gatsby is bad, per se. If I was building an ambitious, content-driven web site wit a multi-person staff, it would be high on my list of possible tools to use.
But for a small blog, that’s only updated a few times a year, it’s just too much to maintain. Hugo, on the other hand, is almost made for this task. It is easy to learn, simple to operate and fast. Let this count as a recommendation.