From static site generator to static site processor

My website was in a state of rotting for a year, but I'm finally happy to report it's fixed now! The various changes made will allow me to write, update and publish way more easily than before.

It took some time as I felt kinda stuck in the clumsiness of the project. It had become a mix of JavaScript for the data processing and page generation ; and of bash scripts for tasks related to assets and development. The whole thing was failing very often, to the point I was not feeling any joy using it. If you've not been following for a long time, building this website has been one of the joyous experiences of my career on the past 3 years, so I felt terrible to have this playground kinda broken.

I needed a change of mindset. I already had several JavaScript modules for parsing my text files, my markup language, processing data from them. I wanted to continue to use those modules, as I think they are the real value of my project. They reflect how I work and think, they are representative of my journey.

Then, I thought about what constitutes a personal static site generator, and came to the conclusion it's not what spits the HTML and CSS, but the data processing happening before the generation that delivers an array of items that will be turned into a website. Maybe I should not do a full static site generator, but a static site processor that delivers data that can be transformed into a website.

This way, I could continue having fun by plugging new ideas into my brain machine, and disregard the actual generation of files, the optimization of assets. But as a web developer specialized in coding interfaces, I cannot not care, I have standards. I want a fast, cohesive, fun and accessible experience. And for this I need tools to process the parts that I don't want to manage myself anymore.

Finding a good HTML printer

So I decided to look again at existing static site generators for Node. To please me, it had to satisfy those needs:

And of course, I found nothing. Eleventy is probably the closest to my needs, but it still hasn't migrated to ES modules ; its documentation is complete but somehow, I find it confusing and messy and can hardly find what I'm looking for ; and you still have to configure a lot of stuff for the assets processing, thus are stuck in the fabulous world of the JavaScript ecosystem.

I was disappointed for a few weeks, until I saw Baldur talk about its experience with Deno. Deno is a JavaScript runtime equivalent to Node, but with several differences that instantly satisfied my laziness:

And it turned out that Óscar Otero, who really enjoys Eleventy, made its own version of it for Deno, called Lume. It follows Deno principles of being near zero configuration, non-opinionated about the source of data, and comes with a set of official, easy to use plugins, and a clear, concise documentation.

I grabbed my modules, made them even more modular and oriented towards data processing, and connected them to Lume through the config file, and it... worked. There isn't a lot to say, I just imported the modules I needed, configured the process and copy for the assets ; created a for loop into a template file ; split my template into layout partials for more clarity ; and the website was generated.

Simplifying the project

Seeing this tooling part was done, I could then go back to what I wanted: fixing stuff in my static site processor, ease the writing and modifying of the website.

Here's a list of changes for the data processing:

For the design and tooling:

I'm probably forgetting a lot of stuff, and I still have many things left to do.

I'm happy to be in a place where it's now possible to just open my code editor, write or code, save and publish without stressing about something breaking.

Again, many thanks to all the people who created the tools I'm now using, especially to Óscar Otero who created lume.

Initially published: March 5th, 2023
Generated: March 6th, 2023