Jekyll or Hugo — Help me decide
Generally speaking, Hugo builds sites much faster than Jekyll. In this benchmark, Jekyll took 187.15s to build a 10,000 page site that Hugo built in 2.95s. Hugo is written in Go and one of its chief goals is to stay extremely fast. Jekyll is written in Ruby, and while its plugin system makes it very extensible, it can’t keep up with generators like Hugo.
Comparing Jekyll and Hugo build times (forestry.io)
Should build speed matter that much to you? It depends. If you’re building a small site with a few dozen pages that you’ll only edit from time to time, probably not. But if you’re creating an active site whose content will grow and grow over time, choosing a static site generator (SSG) with a faster build speed will make both your development environment and your build pipeline more pleasant to work with.
Jekyll is extensible via plugins written in Ruby and boasts a large ecosystem of them—see awesome-jekyll-plugins. These do anything from creating XML sitemaps and RSS feeds to adding analytics and comments. Hugo does not have plugins but does have built in features to handle those things plus shortcodes to perform common tasks like embedding Youtube videos. You can create your own shortcodes too. These are not, however, nearly as flexible as Jekyll plugins.
If your source content fits into Hugo’s (very flexible) content model, you can probably get by with a combination of Hugo’s shortcodes and partials. But if your source content looks nothing like what the end result will be, you might hit a wall with Hugo. Some very advanced Jekyll sites transform source content several times before it gets rendered to HTML, content that may not even live in the filesystem but is fetched on the fly by a plugin. If that sounds more like your project, definitely verify that whatever SSG you consider lets you achieve that level of customization, especially with Hugo. That said, there is a way to fetch external content from REST APIs with Hugo.
Jekyll is blog-aware, meaning that it has built-in features that help you make a full-featured blog faster, such as drafts, permalinks, categories and posts. Put another way, Jekyll wants you to have a blog (one blog, really). As you read the docs, you’ll see a lot of references to that—blog post-like content must live in a _posts folder, for example. In Jekyll-land, there are pages and posts, the difference being that pages don’t have dates. This is a bit more like a traditional CMS like WordPress. The upside of this is a lower learning curve, as it’s pretty clear where things go, and if you are writing a blog you have less decisions to make. The downside is that you might feel constrained down the road if you want to add brand new sections to your site.
. ├── _config.yml ├── _data | └── members.yml ├── _drafts | ├── begin-with-the-crazy-ideas.md | └── on-simplicity-in-technology.md ├── _includes | ├── footer.html | └── header.html ├── _layouts | ├── default.html | └── post.html ├── _posts | ├── 2007-10-29-why-every-programmer-should-play-nethack.md | └── 2009-04-26-barcamp-boston-4-roundup.md ├── _sass | ├── _base.scss | └── _layout.scss ├── _site ├── .jekyll-metadata └── index.html # can also be an 'index.md' with valid YAML Frontmatter
Common Jekyll directory structure (jekyllrb.com)
Hugo is another story. Hugo lets you decide where your content goes, all of it. What’s a page? What’s a post? You decide! Grab a cup of coffee and read the Content Organization page in the Hugo docs to get the full scoop, and don’t feel bad if you don’t get it the first time around. This makes Hugo extremely powerful—you can have completely separate blogs and other list-like content sections with entirely different layouts and configurations running on the same site. You can output content in formats other than HTML, even JSON. The only thing to watch out for is the learning curve. If it’s your first time with Hugo, you might want to build a few throwaway Hugo sites first before you start drawing up the grand plans for your real project.
. ├── archetypes ├── config.toml ├── content ├── data ├── layouts ├── static └── themes
Directory structure for a new Hugo site (gohugo.io)
Hyde is a popular theme for Jekyll
Hucore is a minimal theme for Hugo based on Hemingway2
Here are some other topics worth exploring as you make your decisions:
Assets: Jekyll has some built-in support for asset pipelines as well as quite a few plugins for it; Hugo leaves this up to you (though it may have support in the future)
Contributed by Josh Dzielak
Hugo vs Jekyll: What are the differences?
Developers describe Hugo as "A Fast and Flexible Static Site Generator built with love by spf13 in GoLang". Hugo is a static site generator written in Go. It is optimized for speed, easy use and configurability. Hugo takes a directory with content and templates and renders them into a full html website. Hugo makes use of markdown files with front matter for meta data. On the other hand, Jekyll is detailed as "Blog-aware, static site generator in Ruby". Think of Jekyll as a file-based CMS, without all the complexity. Jekyll takes your content, renders Markdown and Liquid templates, and spits out a complete, static website ready to be served by Apache, Nginx or another web server. Jekyll is the engine behind GitHub Pages, which you can use to host sites right from your GitHub repositories.
Hugo and Jekyll belong to "Static Site Generators" category of the tech stack.
Some of the features offered by Hugo are:
- Run Anywhere - Hugo is quite possibly the easiest to install software you've ever used, simply download and run. Hugo doesn't depend on administrative privileges, databases, runtimes, interpreters or external libraries. Sites built with Hugo can be deployed on S3, Github Pages, Dropbox or any web host.
- Fast & Powerful - Hugo is written for speed and performance. Great care has been taken to ensure that Hugo build time is as short as possible. We're talking milliseconds to build your entire site for most setups.
- Flexible - Hugo is designed to work how you do. Organize your content however you want with any URL structure. Declare your own content types. Define your own meta data in YAML, TOML or JSON.
On the other hand, Jekyll provides the following key features:
- Simple - No more databases, comment moderation, or pesky updates to install—just your content.
- Static - Markdown (or Textile), Liquid, HTML & CSS go in. Static sites come out ready for deployment.
- Blog-aware - Permalinks, categories, pages, posts, and custom layouts are all first-class citizens here.
"Lightning fast" is the top reason why over 35 developers like Hugo, while over 65 developers mention "Github pages integration" as the leading cause for choosing Jekyll.
Hugo and Jekyll are both open source tools. It seems that Jekyll with 38K GitHub stars and 8.28K forks on GitHub has more adoption than Hugo with 36K GitHub stars and 4.05K GitHub forks.
According to the StackShare community, Jekyll has a broader approval, being mentioned in 110 company stacks & 123 developers stacks; compared to Hugo, which is listed in 36 company stacks and 60 developer stacks.
Fastest and quickest way to do static HTML site which is extremely fast? Do you consider above tools or is there anything more quicker or better? This is just a one time one pager site for now, no backend required. I might have such projects in future, having something to get familiar with which can immediately come into action to develop would be great advise!
As a Frontend Developer I wanted something simple to generate static websites with technology I am familiar with. GatsbyJS was in the stack I am familiar with, does not need any other languages / package managers and allows quick content deployment in pure
Markdown (what you prefer for a project). It also does not require you to understand a theming engine if you need a custom design.
Sign up to add or upvote prosMake informed product decisions
Sign up to add or upvote consMake informed product decisions
What is Hugo?
What is Jekyll?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions