Should you really build your own SSG?

It was a rainy Saturday afternoon when I was at a cafe with my wife scrolling through Hacker News when I came across Arne’s blog on why you should write your own static site generator (SSG). I had recently gone down that road myself, at least partially, so seeing someone’s views on the same topic intrigued me. I’ve been meaning to gather my thoughts around the subject, and what better time than now as somewhat of a response to Arne’s blog?

If you haven’t already read Arne’s blog I suggest you start there, they mentioned the turning point was after Vercel announced their release of Next.js 14 and the pressure some might feel to upgrade and not be left behind. Personally, I’ve used a number of SSGs, including Jekyll, 11ty, Next.js, and currently for this blog Hugo. While not static, for a brief period of time, I even used WordPress. I do feel I’m in a somewhat unique position as I use my own, custom-built, SSG for my main site and Hugo for this blog.

Why I’ve built my own SSG

There are several benefits to building your own SSG, and I agree with a lot of what Arne has written. If you want to change the way something works out-of-the-box, at times it can lead to a lot of reading to understand the decisions made by the framework you’ve married your blog to. Sometimes those architectural decisions can define your writing workflow, or require non-trivial adjustments to your SSG framework to adapt to you. With my own SSG, I can write my content in whatever form I like I use an SQLite database for the Rail page to list out links to my videos and use Markdown to render the Bookmarks page. Lastly, if you’re anything like me, it’s just really fun.

When deciding to build your own SSG the only thing you really need to build is the mechanism to convert your content to HTML. If you want to go a step further you can look into generating optimised images, an RSS feed, and compiling your CSS. For my main site, I use Jinja as the template engine for my HTML files, and a Python script that uses the Markdown library to convert the Markdown to HTML. I also use the Python sqlite3 library to read from the SQLite database and use sqlite-diffable to dump and load the database into JSON format so it’s diffable in git, although this step is not necessary.¹

Why I also use Hugo

I did mention I use Hugo for this blog, but not on my main site, and there’s a reason for that. The thing about existing static site generators is that they just make things a whole lot easier. Remember I mentioned all those decisions made by others that require you to read the documentation to tweak? The thing is, they’re there to make, you, the writer’s life easier. Not to mention having a documented generator to work with usually means a pre-existing ecosystem of plugins and themes at your disposal. After using Hugo for almost 2 years on this blog, I still find existing features that I didn’t know existed to better my blog, like the ability to optimize remotely hosted images. The only reason I was able to switch SSGs so much was because of the amount of existing documentation and the dependence on a somewhat standard Markdown implementation.

To comment on the build tools and push to keep up with the latest version, I faced a bit of a challenge when I used Jekyll in setting up my environment and keeping my gem versions happy. It seemed every time I was ready to publish, something was out of date or no longer compatible with something else. This I will have to admit, is partially my own fault, I never took the time to properly understand how Gems, Jekyll, and even Ruby worked. That is why I like Hugo so much, it’s just a binary that you download, build your site and you’re set. To think about it, in the end, your generated files are static regardless of which version your build toolkit is or which SSG you use.

Lastly, part of the reason I kept switching SSGs was because I didn’t find a particular generator or theme that did exactly what I wanted it to. However, with Hugo, I decided to build my own theme. This suddenly opened a whole world of possibilities and not to mention I understand the architectural decisions of Hugo and its capabilities much better now. Not to mention it’s also just as fun as developing my own SSG.

Fin

To wrap up my blathering at the cafe and head home, should you build your own SSG or just find one that best fits you? It depends. As much as I enjoy the freedom of developing my own, piecing together libraries, learning how RSS and sitemaps work, and all the joys of making my own decisions, if I just want to focus on writing I’d rather stick with something that’s already out there.