A lot has been written about the latest redesign of this site, but only about the visual changes. In the previous redesign, the visual changes have been a byproduct of the URL reorganisation behind the scenes. Sure enough, this time around, there too something has happened that no blog post has covered. Until now.
Before my latest redesign, I’ve used a static site generator (SSG) called Metalsmith to render the pages of this website. Which I was going to replace with Eleventy. For lots of good reasons, it coming from the brain of Zach Leatherman being one of them. But also because this is what all the cool kids are using these days.
I was right on track. I read up on the documentation. I renamed almost all of my files to make trailing slashes in my URLs happen. I incrementally refactored my content to make the upcoming transition easier. Oddly, I implemented one-time-use plug-ins for Metalsmith to rewrite the content. And while I made those changes in a way so I could still feed the output back into the to-be-replaced SSG, I was getting closer to the big switch.
Change of plan
Fast forward to the launch of my Version 4, Metalsmith was gone. But Eleventy didn’t replace it. Instead, I went full circle. Like in its early days, this site is once again rendered by a new lightweight SSG I created. So I’ve successfully worked against everything I wrote about in my essay »On Using Static Site Generators« in 2017. Given the conclusions I drew back then, one can only say: How stupid.
I agree. But I was on a different kind of mission.
“I wanted to add a five-minute thing to a project I haven’t touched in a while, and ended up doing two hours of upgrading npm packages instead.” Sounds familiar? I’ve been there before, and I didn’t like it. Especially when I had to rewrite entire build scripts, because “using X has run out of fashion, we now use the much better supported Y instead”.
Tired of this, many months ago I started removing all dependencies from all my projects, one pet project at a time. Considering I have a few more than the ones you’ll find on GitHub, it has been quite a journey. Not all those projects result in a website, so I came up with different approaches along the way. In one project, I changed the whole thing to run in the browser, not requiring a build step anymore. In two instances, I replaced entire build scripts with *nix-only shell scripts. And so on. But the bottom line always has been: The project’s package.json should no longer contain any dependencies.
I got to the point where only one project remained. This very website. It was the most complex one, so I thought I’ll make an exception here.
Except, I didn’t. Eventually I abandoned the idea of migrating to Eleventy, and instead ended up with my own creation based on node.js (which technically is also a dependency, but not one that counts in package.json terms). It is a brittle and awkward solution, but it does the job.
It came with lots of sacrifices. For starters, I didn’t want to write my own Markdown parser, so I no longer write my blog posts in Markdown, but HTML instead. What my SSG does, is—among other things—converting HTML input to enriched HTML output.
Neither did I want to write any minifiers, so there is no more HTML/CSS/JS minification, which sounds like a
terrible idea, and it is. But it has been the inspiration for this whole endeavour, as you will find out once I’ve finished writing my essay »View Source«.
Sacrifices aside, my SSG can serve the files during development, and it has a build process. That build step is optional. While it does turn the content into a proper website, if some day everything goes wrong and node.js stops working, I could host the raw content instead.
But the best part is, I no longer get fancy/scary messages from
Can you make a great product by doing everything yourself? No.
Do you have to use all the frameworks to end up with something meaningful? Also no.