Ben's blog

rambling through cyberspace

So, I've moved my entire blog over to a custom SSG. While it's generally frowned upon as a sort of procrastination, I don't think this advice still holds with tools like Cursor greatly speeding up the grunt work.

Why Build a Custom SSG?

You may be asking why I've suddenly decided to move everything over to a custom SSG after using Zola for a bit. This came about while experimenting with structured data using JSON-LD and giving up in frustration due to the terrible templating system used by Zola.

The Problem with Templating Languages

This is actually a long-held belief of mine that has been solidified due to at least 5 instances where a templating system just wasn't powerful enough, requiring me to use some sort of workaround/escape hatch.

Generally, I'm convinced that all templating languages like Tera (used by Zola), Twig (popular with the PHP crowd) or Fluid (used by Typo3) are a terrible idea and should never be used. They're mainly advertised as being safe against code injection, but whom are they saving us from? It may just be because I've mainly worked with smaller companies, but in 15 years of consulting as a WebDev, I've NEVER had the need for someone needing to alter a template who shouldn't be allowed to alter source code. In general, it's never happened that a non-dev wanted to work on a template, though there were times when there was an employee that knew a little HTML/JS who wanted to do some changes - this only happened once.

So, now that code injection is apparently not much of an issue, what remains? You can either choose a battle-tested language like Scheme/Lisp/Lua/JS for templating or some non-standardized mess cosplaying as a programming language.

Building the Custom SSG

Since I don't like to give up on ideas, I just opened up Cursor and coded my own custom SSG in a couple of hours. Pretty sure it took me less time to rewrite everything with a custom SSG than my experiments with Zola/Tera took yesterday...

It's a terrible codebase, but it's a foundation to build upon, since only the content really matters. So now that everything works, I can just clean up the SSG with every article. Also, just as a reference: the ENTIRE SSG, including a dev server, is currently 621 LoC... that is almost nothing, especially since I haven't really slimmed down/optimized any of it by hand.

The Future of SSGs

I think it doesn't really make much sense anymore to use most SSGs anymore, since there are a ton of libraries out there doing the (somewhat) complicated bits (like parsing Markdown / YAML) and gluing things together has become much simpler with AI Editors like Windsurf/Cursor. Even before it wasn't much of an issue to use a custom SSG, I did so multiple times, once even in Nujel, which was quite the distraction. But since so far TypeScript has proven to be one of the better supported languages in LLMs, I'm sticking to it for now.


Adios, べン