From melabit to melabit: why Jekyll?

– Source: Jametlene Reskp on Unsplash.

As I mentioned in my last post, leaving the WordPress comfort zone wasn’t easy at all.

Going from focusing solely on writing something interesting – while a team of system administrators and web programming experts handled everything else – to having to do it all by myself was a massive leap.

It took quite some time to set up the new system, add missing features, and resolve the (many) unexpected technical issues. And let’s not forget that, in the meantime, I was still managing my regular work and trying to write a post now and then.

Thus, the primary need was to base this new blog on a stable and reliable platform, a platform that wouldn’t change every week or, worse, suddenly vanish because its developer got tired of tinkering with the project.

Having abundant, well-written documentation was also essential: clear guides for configuring the system and finding quick solutions to problems (which are inevitable) are a tremendous help, saving countless hours of frustration.

With these criteria, the choice was inevitable, and it was the same as many years ago: Jekyll.

Because Jekyll may have its flaws, such as the slow site generation and the bulkiness of the generated code, but it’s been around for 16 years. It continues to be regularly developed without dramatic overhauls (the latest release was in September 2024), and you can find guides online for virtually anything you might encounter when building a site with this platform.

After all, it’s no coincidence that GitHub chose Jekyll as the platform for generating sites directly from its repositories.

Back then, I was so convinced about Jekyll that I wrote all 482 posts of the blog on wordpress.com in Markdown, with a YAML front matter like the one used by Jekyll and saved images in folders named after the posts.

On WordPress, this wasn’t necessary because all I had to (and could) do was copy the text into a new post, add the images, and click publish (well, it’s a bit more complicated, but you get the idea).

However, having everything neatly prepared in the right_ format significantly simplified the transition from WordPress to a static site based on Jekyll. I just had to set up the basic structure, add the posts and images, and generate the site to have everything ready to go (again, it’s slightly more complex than that, but you get the idea).

If I hadn’t kept the original texts, I could have used a WordPress plugin to export the posts from WordPress to Jekyll. (It’s true, there’s a WordPress plugin for almost everything!) But the plugin doesn’t support comments, images are dumped into a non-standard directory and need to be moved, and all links have to be fixed… Ultimately, in my case, it would have taken more time to clean everything up than to start from scratch.

Now the foundational work is done, and all the main functions of the new site are more or less working. At this point, it’s easier to explore alternative—and hopefully more performant—solutions to Jekyll.

At the top of my list are Bridgetown, a Jekyll fork_ worth diving into, and Middleman, which intrigues me even if I’m not entirely sure why!

It will be fun.