Jeeeeeekyll? No, Hugo!

Sat, 24 May 2025 00:00:00 +0000

As I was writing about my transition from WordPress to Jekyll, I knew I had to prepare for another change.

From a technical point of view, Jekyll is a fantastic platform: it is easy to program, has impeccable documentation, and works perfectly during the development phase, with a limited number of pages and test posts. But, as I experienced firsthand, when Jekyll is asked to handle a real site with hundreds of posts, performance drops dramatically and response times become unbearably slow (and quite embarrassing, too).

In the late ’90s, it was normal to wait several seconds for a webpage to load.¹ But today, we’re used to pages that load instantly, so having to wait three or four seconds is unacceptable.

A high price to pay

Before I started working on the new site, I was well aware that Jekyll was slow. However, this slowness was always attributed to the site generation phase, which is performed sporadically and can be automated. And that was exactly what happened: during development, with a few dozen posts, I could regenerate the site in 10–20 seconds, quite annoying, but not dramatic; now it takes 15 minutes to regenerate the entire melabit.com.

What I didn’t know was that the generated site would also suffer from the same problem, which became evident as soon as I finished the development phase and started working with all the posts.

At that point, I was still convinced that optimizing the code and images and applying an aggressive caching would mitigate the issue. And in any case, I had gone too far to turn back. However, I soon realized that this strategy wasn’t enough, and that a radical rethink was necessary. So I started looking around.

Alternatives

Static site generators are like Linux distributions: there are too many of them, and in most cases it’s hard to understand why they even exist. At the moment, Jamstack lists 366 of them, while Static Site Generators counts nearly 500. Most have been abandoned, maybe because nobody was using them, or because the developer lost interest in continuing development. Let’s say the interesting ones are a dozen or so, maybe a few more.

Among these, I considered Bridgetown (very briefly, I admit), which is derived from Jekyll and therefore, at first glance, seemed like a natural evolution. However, I realised that few people use it, there are few plugins and even fewer themes. If Bridgetown is derived from Jekyll, how could I be sure that it didn’t suffer from the same slowness issue? Better to stay away and stick with the original.

Another candidate was Middleman, which is developed in Ruby like Jekyll. But Middleman is designed to generate plain websites, and you need a specific extension to make it support typical blog features, such as lists, taxonomies, feeds and comments. Also, the templating language is ERB (Embedded Ruby), which is a sensible choice since it’s integrated within Ruby. However, it meant having to relearn everything from scratch.

Long story short: in the end, the only serious candidate was… the good old Hugo.

Looking for speed

Many years ago, I wrote a post about Hugo, finding it interesting, but crippled by documentation that calling poor was being generous.²

However, its quality is not in question. Unsurprisingly, Hugo consistently ranks at the top of all the charts evaluating the quality of static site generators, just like Jekyll.

And Hugo has a real ace up its sleeve: it’s fast. In fact, it’s blazingly fast!

I can’t say whether Hugo is truly the world’s fastest framework for building websites, as claimed in the slogan at the top of its homepage. However, I have verified firsthand that Hugo can generate this entire site in under a minute, 15 times faster than Jekyll. Most importantly, the generated site is fast and responsive, exactly as you would expect from a modern website. That puts everything else in the background.

Hugo

So starting today, melabit.com is moving to Hugo, with a new design³ and trying to keep all the features of the Jekyll-based version. The first of these is the [Comma-based commenting system]https://melabit.com/en/2025/03/05/from-melabit-to-melabit-managing-comments-with-jekyll/), which after the transplant worked practically on the first try.

The permalinks have changed and now explicitly indicate the language of the post, which is a more rational approach. The feed has changed too. For now it’s the old RSS, but at some point I’ll check whether it’s possible to add ATOM.

Right now, the search function is based on Google, and will not work until the site is indexed again. Pagination needs to be revised, as does the logic that shows the featured post in the list of all posts. But these details can be sorted out later.

Because of how my mind works, I’d love to go into the details of how I modified Hugo and the chosen theme, but I’m afraid it would be boring, in particular after all the very detailed (but now almost useless) posts I wrote about Jekyll. I’ll think it over. In the meantime, if anyone is interested in knowing more, feel free to say so in the comments.

– Image generated by Google Gemini.

But you could at least distract yourself by watching the images appear one line at a time on the screen… 😂 ↩︎
Not much has changed since then. One of the (few) posts I can recommend without reservation is this one on managing context and variables in Hugo. It’s a very technical read, but essential for learning the basics needed to modify and extend Hugo. ↩︎
I’m not thrilled with the design, but it’s the best I’ve been able to come up with so far. ↩︎

From melabit to melabit: why Jekyll?

Tue, 21 Jan 2025 18:00:00 +0000

– 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!