Hugo vs. Jekyll: Comparing the leading static website generators

If you're building a new website, a static site generator may be the right platform for you.
435 readers like this.
A graduate degree could springboard you into an open source job

Opensource.com

Unless your spirit animal is Emily Dickinson, when you make a thing, you want to share it with the world. Sharing your work means that you need a website. Of course, you could simply partake in digital sharecropping and use any of the various social media sites to get your work in front of an audience. There sure are plenty to choose from... and not just "conventional" social media sites. With places like Artstation, Flickr, Soundcloud, and Wattpad, there's an outlet for you, whatever your medium.

And actually, you should use those sites. It's where the people are, after all. However, none of those places is truly yours. None is a home base that you control and that you can ensure will be there for people to find regardless of the waxing and waning trends of social media.

Control. That's the value of having your own place on the web.

But this article isn't about setting up a domain name and hosting for your website. It's for the step after that, the actual making of that site. The typical choice for a lot of people would be to use something like WordPress. It's a one-click install on most hosting providers, and there's a gigantic market of plugins and themes available to choose from, depending on the type of site you're trying to build. But not only is WordPress a bit overkill for most websites, it also gives you a dynamically generated site with a lot of moving parts. If you don't keep all of those pieces up to date, they can pose a significant security risk and your site could get hijacked.

The alternative would be to have a static website, with nothing dynamically generated on the server side. Just good old HTML and CSS (and perhaps a bit of Javascript for flair). The downside to that option has been that you've been relegated to coding the whole thing by hand yourself. It's doable, but you just want a place to share your work. You shouldn't have to know all the idiosyncrasies of low-level web design (and the monumental headache of cross-browser compatibility) to do that.

Enter static site generators. You get the speed and security of static HTML pages, but with a workflow that's closer to the convenience of a dynamic site. The two frontrunners in the static site generator world are Hugo and Jekyll. (By the way, Paolo Bonzini has a great article on getting started with Jekyll.) But which one is the right choice for you? Hopefully by the end of this article, you'll have a better idea. We're evaluating both static site generators based on how quickly you can get started, availability of themes, editing workflow, and extensibility.

Getting started

Fair warning, both of these tools will require you to work with them from the command line. Most of the commands are straightforward and easy to remember, but let's adjust our expectations accordingly. This is not a point-and-click interface.

Installation for both Jekyll and Hugo is pretty simple. Jekyll installs as a RubyGem, and Hugo offers a very handy all-in-one binary to get you started quickly. Because of the single install package, Hugo edges ahead here slightly. Although the RubyGems install method for Jekyll is easy in its own right, it does require that you already have a properly installed and configured Ruby environment on your computer. Outside of the community of designers and developers for the web, most folks don't already have that setup.

Once installed, though, both Hugo and Jekyll are pretty evenly matched. They both have great documentation and quick-start guides. You start a new site with a single command (in Jekyll, it's jekyll new <your_site> and in Hugo, hugo new site <your_site>). This sets up a general directory structure and scaffolding for your site. Directory structures and basic configuration are pretty similar. Jekyll uses a _config.yml file and Hugo uses config.toml (although you can use YAML or even JSON syntax with Hugo's config if you're more comfortable with either of those). The front matter metadata at the top of each content file uses the same syntax as the config. After that, all page content is written in Markdown.

I will say that in terms of getting you started with your very first statically generated site, Jekyll has a slight advantage over Hugo because it starts with some basic content and a default theme. You can use these as example templates as you start building your site. Hugo has no example content or even a default theme. That said, example content and default themes are usually the first things I delete when I'm making a new site with any tool, so Hugo actually saves me a step.

Themes

As I mentioned, Hugo doesn't ship with a default theme at all, so that's probably one of the first things you're going to want to set up. Jekyll has a decent default theme, though it's pretty bare bones. You'll probably want to go theme hunting with your Jekyll site, too.

Both Hugo and Jekyll have a pretty diverse assortment of themes for all manners of website types from single-page ID themes to full-blown multipage sites with blog posts and comments. Despite that, it's not exactly easy to find a theme that suits your needs. In either case, the place to go for themes—themes.gohugo.io for Hugo and jekyllthemes.org for Jekyll—is basically a single large page full of theme screenshots. Once you click on a theme, you can get some pretty detailed information about it, but that initial search is pretty rough. Hugo's theme page has some basic tagging built into it, but in general, theme searching and presentation is something I feel both projects really need to work on.

Theme management is also an interesting topic. In both cases, nearly every theme is a Git repository (often hosted on GitHub) that you clone into your website scaffolding. In Jekyll, there's an additional step of using RubyGems' bundle to ensure that the theme is managed with the site. Most themes already come with a Gemfile, making this step relatively painless. If the theme doesn't already have a Gemfile, it's fairly easy to add. In Hugo there's no bundling step. Just point to the theme from your config.toml, and you're good to go.

I've found that I'm partial to the way that Hugo handles themes. You clone (or create) themes into their own space in a themes subdirectory. Not only does it make it relatively easy to switch between themes when you're first starting out, but it also gives you the ability to override any component file of a theme with your own file. This means you can customize a theme to your tastes without messing too much with the source of the original theme, allowing it to stay generic enough for other people to use. Of course, if you have a change that you feel other users of the theme may find worthwhile, you can still edit that source and submit a pull request to the theme maintainer.

Workflow

The workflows for building your site in Jekyll and Hugo are pretty similar once you have your initial configuration set up. Both have a live serve command that runs a small, lightweight web server on your computer so you can test your site locally without needing to upload it anywhere. The really nice thing is that whether you're running jekyll serve or hugo serve, both are configured by default to watch for any changes you make to your site as you work on it. When you look at the locally served version of your site in a browser, it automatically updates with any change you make, regardless of whether that change is to content, configuration, theme, or just an image. It's really quite handy and a great time-saver.

You write the content for your site in both systems using Markdown syntax. If you don't happen to be familiar with Markdown, it's a very simplified means of writing in plain text while still allowing for some nice formatting marks. It's very easy to work in and human-readable. And because it's in plain text, your content (and therefore your site) is easily version controlled. It's pretty much the main way I write almost everything these days.

New content can be added to your site scaffolding by manually creating files in the right place. It just needs to be a Markdown file with the appropriate "front matter" metadata at the top of the file. As with the configuration file, Jekyll uses YAML syntax for front matter, while Hugo will accept TOML, YAML, or JSON (default is TOML). That new page file needs to be placed in the correct directory within your site's scaffolding. In Jekyll, you have separate _drafts and _posts directories for storing your work in progress and your completed content pages, respectively. In Hugo, there's only a single content directory. You specify whether a post is a draft or not within that content file's front matter.

Now, although it's possible to do all of this manually, Hugo does offer some convenience functions to ensure that your new file is created in the correct spot in the scaffolding and that files are pre-populated with appropriate front matter. It's simply a matter of going to your site's directory in a terminal and typing hugo new content/<page.md> where <page.md> is the new page you want to create. You can even set up templates called archetypes that hold customized front matter for pages of different types (like if you have both a blog and a podcast on your website).

When your site is ready to ship, you can shut down your preview server and issue a command to build the actual pages of the site. In Jekyll, that would be jekyll build. In Hugo, it's just hugo. Jekyll puts the completed site in the _site subdirectory, while Hugo puts them in a subdirectory named public. In either case, once you do that, you have a completed static website that you can upload and have hosted nearly anywhere.

Extensibility

Both Hugo and Jekyll give you the ability to customize your site down to the smallest thing. However, in terms of extensibility, Jekyll currently leads in a big way because of its plugin API. Because of this plugin architecture, it's relatively easy to add functionality to your Jekyll-generated site with reasonably short snippets of code available through the Jekyll community or that you write yourself.

Hugo does not currently have a plugin API at all, so adding that kind of functionality is a bit tougher. There's hope that the ability to write and include plugins will be added in the future, but it doesn't appear that anyone is working on that yet.

Conclusion

By and large, Hugo and Jekyll are pretty similar. It really comes down to determining how you're most comfortable working and what your site needs. If you already have a RubyGems environment set up and you need the extensibility of plugins, then Jekyll is the way to go. However, if you value a simple workflow and a straightforward means of customizing your site, then Hugo would be your top pick.

I find that I'm more drawn to Hugo's approach, and in building a small handful of sites, I haven't yet had a need for any plugins. Of course, everyone's needs are a little bit different. Which static site generator would you choose for your site?

User profile image.
Jason van Gumster mostly makes stuff up. He writes, animates, and occasionally teaches, all using open source tools. He's run a small, independent animation studio, wrote Blender For Dummies and GIMP Bible, and continues to blurt out his experiences during a [sometimes] weekly podcast, the Open Source Creative Podcast. Adventures (and lies) at @monsterjavaguns.

9 Comments

Hugo is my first choice after working long time with Jekyll. You're right: Both are similar. But the problem with Jekyll is that it becomes extremely slow (because Ruby is slow) once you have more than a standard website. I have one with only 80 Posts and with tags and categories it gets even worse. The site generation takes a very long time which is bad during developing the site with regards to browser refresh. The same site with Hugo takes about 700ms to render. And I have a lot of Loops, Taxonomies and Tags. So you can imagine what it means if you work with Jekyll on a site with 800 Posts. Simply not possible for me. I have seen tests with Hugo where people generated more than 100,000 Posts and the render time was still minutes. With Jekyll that would probably take days.

Tnx for the great article.

I use Pelican https://blog.getpelican.com/ as static website generator.
Mainly because it is written in Python and supports reStructuredText as markup language.

I have been doing extended research on this topic and in the end chose to use Jekyll. I have done a huge project: https://docs.mendix.com, where we have made the complete website Open Source on Github.

Fun project where I ended up moving quite some stuff from Jekyll to Node. For example generating Sitemaps tended to be faster when doing it in Node instead of Jekyll.

Bit... Here's the downside. Our documentation is about 2700 pages (I'll have to lookup the real number). Generating the whole site takes about 90 seconds. That's kind of annoying when you're iterating over small changes. I did a basic test in Hugo, it does it in about 500ms.

So if I am able to transfer the work that's done by plugins to Hugo/Node, I am going to refactor this to Hugo, because of the speed.

I might end up writing a similar blog about this project, it's long overdue.

Hugo is implemented in Go. Could be obvious from the name, but wasn't to me.

The only missing thing in Hugo is the incremental build.
Hugo rebuilds the entire site everytime.
Hope we have this enhancement soon.

Please take a look at Nikola https://getnikola.com/. Written in Python.

Good overview, but I disagree that static site generators solve the problem of WordPress and "good old HTML and CSS" being too complicated for people who don't know "all the idiosyncrasies of low-level web design."

If folks find HTML/CSS too complicated, how likely are they to grok YAML/TOML, Go templating, Ruby Gems, the command line or even Markdown?

I think the use case for Jekyll or Hugo is a site where you want the dynamically-driven features of a blog (date-sorted posts, automated snippets and indexes, categories, tags) without the installation and security issues of a dynamic backend. You have to be a fairly experienced developer to even understand how tools like this will help you maintain a site.

You can create a site using a SSG without ever touching a template, in the same cases where you can create a site using Wordpress without ever touching a template: by using a 3rd-party theme.

And, well, at least in the case of one SSG you could use freaking libreoffice to create the pages if markdown doesn't tickle your fancy :-)

https://plugins.getnikola.com/v7/odt/

In reply to by Joel Davies (not verified)

I personally find markdown much easier than HTML/CSS. I am not a web developer, and I get by by quickly finding documentation on what I need. Just learning HTML alone is useless for me as anything exciting I see in a website is always more involved, like using javascript, and many *.js tools out there. It took me just 30 minutes of watching a video to switch all my technical trainings stuff from Word to MARKDOWN. However, I am not looking for an easy way to get a "Copy" button Automagically with Hugo hosting my markdown content. E.g. any code highligted with a backtick should automatically have a "Copy" button to copy the code. I don't even know what this feature is called to begin searching for it.

In reply to by Joel Davies (not verified)

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.