Hugo vs. Jekyll

Hugo is a static site generator (SSG) that makes your life easier.

After playing with React, Gatsby, and Jekyll, I decided to use this funky generator for my blog in 2021.

Let’s see why.

Permalink to heading Writing content Writing content

I use markdown. Jekyll and Hugo handle that beautiful format elegantly.

Permalink to heading Writing with Jekyll Writing with Jekyll

Both Jekyll and Hugo use text files for contents instead of querying a database. Jekyll supports markdown and HTML for writing content.

It requires a frontmatter at the beginning of each content file.

Jekyll only supports the YAML style:

layout: post 
title: Blogging Like a Hacker 

Source: documentation Jekyll

You can use the built-in Jekyll collection _posts for chronological contents and _pages or any custom collection for non-chronological contents.

You can also leverage the benefits of the _data folder to source from YAML, JSON, and CSV files and directly use them with {{ }}.

Permalink to heading With Hugo With Hugo

Hugo has quite the same features as Jekyll, but it supports more file types for content files and more styles. You can either use TOML, YAML, and JSON for the frontmatter.

All content files go in the content folder at the root of the project.

You also find a data folder where you can source from CSV and JSON files, for example.

Permalink to heading The i18n challenge The i18n challenge

There are many other magic frameworks, but only a few of them are multilingual-ready. Most of the time, it’s a huge pain to handle your translations correctly.

With Jekyll, you can do whatever you want because of its super high flexibility. It’s barebones on purpose and ready for almost everything without plugins.

In my post Handle Hugo translations, I told you about the fantastic translationKey parameter you can use in your markdown files to relate translations without any restriction.

With Jekyll, I would recommend using custom collections for almost everything, including i18n. With Hugo, it’s even simpler. You can use built-in tags and categories and make them multilingual with a custom URL scheme.

Hugo’s documentation is excellent on top of that. I appreciate how they handle plurals and variables.

Permalink to heading The language used The language used

Jekyll uses Ruby, so it wins this part, as I’m writing the post 🀣🀣🀣. Don’t worry. I’ll try to be less biased in the next sections.

Permalink to heading Simplicity and learning curve Simplicity and learning curve

Both Jekyll and Hugo are on top of the World when it’s about simplicity and fast learning curve.

You don’t need a Ph.D. to start using it, and you’ll find high-quality themes if you don’t have time to code your own.

Both are straightforward, and the setup is easy. Hugo is probably even more comfortable as it’s like using a binary.

Permalink to heading Build time is money Build time is money

Static generators are powerful, but the build time can be a massive pain if you have more than 200 pages, which is not that much for a blog.

Ten minutes of build every time you need to publish or update something might seem extravagant, but I’ve already seen it.

Whether you use Jekyll or Hugo, you won’t experience that, but Hugo is ridiculously faster than Jekyll. As a result, if you have a large website, the difference is significant.

Permalink to heading Assets and pipes Assets and pipes

Even if Jekyll supports sass, Hugo wins this part by far:

The pipe chain is only invoked the first time it is encountered in a site build, and results are otherwise loaded from cache. As such, Hugo Pipes can be used in templates which are executed thousands or millions of times without negatively impacting the build performance.

There’s a built-in cache for the whole pipe chain!

Hugo does not even need Gulp or WebPack to handle preprocessing and postprocessing your css files:

{{ $styles := resources.Get "css/main.css" | postCSS (dict "config" "./assets/css/postcss.config.js") }}
{{ $styles := $styles | minify | fingerprint | resources.PostProcess }}
<link rel="stylesheet" href="{{ $styles.Permalink }}">

Source: Hugo pipes documentation

Permalink to heading Hugo’s internals Hugo’s internals

Hugo has built-in templates you can use to speed up your dev.

If you need Google Analytics, Open Graph, Twitter cards, and paginations, it’s built-in, just call the template tag:

{{ if .Site.GoogleAnalytics }}
{{ template "_internal/google_analytics_async.html" . }}
{{ end }}

RSS feeds and sitemaps are also built-in, and you don’t have to call anything. It’s just ready.

Jekyll is barebones on purpose:

The core should be kept to features used by at least 90% of users–everything else should be provided as a plugin.

However, I think Hugo’s internals make more sense, as most websites and blogs need those features.

Permalink to heading Trailing slashes Trailing slashes

Hugo does not allow Url schemes without trailing slashes. As Hugo creates folders with index.html files, everything is a directory, and it’s a good practice to add a trailing slash on URLs that represent a directory.

It’s a significant point you have to take into account if you plan any migration.

In some cases, it’s a no-go. In any case, you should be careful with your URL scheme. Choose one and stick with it.

Permalink to heading Hosting Hosting

You can host Jekyll pretty much everywhere. You can even use GitHub pages to get a completely free website or blog.

It’s quite the same as Hugo.

Source: Hugo on GitHub

Permalink to heading Wrap up Wrap up

IMHO, Hugo beats Jekyll. I get the same level of freedom and more. The multilingual part is seamless.

The build time is like a finger-snapping.

I do my best to update all my contents, but keep it mind that "Hugo vs. Jekyll" has been published many months ago.