Written by Nick F
Published on 2026-06-02
Back to blog

 

I'm personally a big fan of Static Site Generators. They are a great way to reduce the complexity of building a small site while letting you opt-in to more features where needed. When the jekyll project hit the scene it really popularized the idea. With Jekyll built in to GitHub hosting it made it super easy for a lot of developers to get started. Since Jekyll, there have been some Static Site Generators (SSG) that take their own approach to how they conceive of a site and the power they let the user express on it. Here is a little survey of what is available and what makes them different.

Jekyll

Jekyll is in maintenance mode today, but it's very feature rich and set the standard for many to follow. Jekyll works on finding Markdown files with front matter and transforming those into HTML files. Jekyll made three things pretty easy:

  1. Pages
  2. Collections (blog posts by default)
  3. Data Files

Pages is the straight-forward transforming of a MD to HTML file.

Collections let you group pages together. Out of the box, the _blog folder was a collection that let you group together blog posts. This made it easy to have an index page that lists your blog posts by date.

Data files was a very easy way to read a json, csv, or yaml file and have that content available in templates. It could be used to organize navigation links, or a simple place to link off-site pages like a blog roll.

Similar systems: Pelican, Zola, Hugo

Lektor

Since 2025 I've been using Lektor more. Compared to Jekyll, it really focused on Pages, but does support collections and data files. However, it's got two unique things going for it:

  1. Defined structure for pages as "Models"
  2. A GUI for editing your content in the browser, locally

Lektor has a great system where you define the Model of a page, and their GUI system lets you edit that. This does get away from the simplicity of editing a markdown file in a text editor, but it brings some great features. One is that you have consistent metadata for pages that have the same model. Two is you get a visual way to preview your editing and see how everything will work live.

Here is an example model for a blog post I use:

[model]
name = Blog Post
label = {{ this.title }}
hidden = yes
_slug = {{ this.pub_date }} / {{ this.id }}

[fields.title]
label = Title
type = string
size = large

[fields.pub_date]
label = Publication date
type = date
width = 1/4

[fields.body]
label = Body
type = markdown
size = large

With that in place, every time I want to edit or create a blog page, I get UI for all the fields:

built-in lektor GUI

This gives a different flow to a Lektor site. Instead of editing a new blog page in Vim or another editor, you do it in the browser, and get the nice "preview" button right there. Also, you can browse around your page in preview mode and launch the editor with the pencil button on the top right of any page. It makes my little site feel like it has the power of a CMS while still being a flexible and simple as a SSG system. While the GUI is nice, the page data is still in plain text, I could edit it with vim or another editor if I wanted to.

Lektor powers this with their own .lr file format. Also, they have a system where each piece of content should be in it's own folder. This lets you easily put related content like images, pdfs, etc into that folder and keep it close to the content.

Given the above, Lektor has quite a few divergences from the normal Jekyll-inspired SSGs, but I think it really brings some original thought and features to the space. I'm a happy user of it, but I do wish it would expand to even more power. The GUI would be great to expose viewing or editing of Models and Data files. Hopefully soon!

Similar systems: None that I've found with a GUI or focus on structured content.

Metalsmith

Metalsmith is a Typescript SSG and it's interesting twist is letting the user dig deep into how their blog is built. All the SSGs that I have seen have a config file. For Metalsmith, it's configured by being very explicit on how the site is built by expressing a pipeline in Typescript code. This lets you opt-in to various features and target them to specific pages or templates. The power it lets you express is very high, but the complexity rises as well.

Similar systems: Luasmith, Nanoc

Gatsby

Gatsby brings two approaches that are different from what I've listed so far.

  1. Javascript files as top level building component
  2. GraphQL to fetch content instead of local files.

Gatsby is a system that embraced the ReactJS ecosystem for building a static site. A page can be a Javascript file the defines a React Component.

I think their focus on GraphQL to fetch content is more interesting. I think local files are a great way to get started, but more SSGs should have a clear path to bring in content from a CMS, and GraphQL is a flexible way to make that happen. I think it really unlocks having a static site that is easy for non-developers to contribute content to.

With a focus on ReactJS, I think Gatsby has an interesting niche on Web Applications instead of Web Sites. The difference between the two is generally about being dynamic in presentation, even with a static output of the system.

Similar systems: None that I've explored, but I don't really look for these style.

General Takeaways

I'd say there are two general approaches that I've seen in SSGs: Template based, and Build based.

A Template based SSG follows the path that Jekyll set out. Templates are the main system of deciding how your overall site is built. A content file declares a template and in there is the important logic for a page. Overall templates can share data and methods so that a site-wide structure is imposed. The power is expressed in a way that a Web Designer would feel most comfortable.

Build based systems try to expose a structure outside of the templates. The templates are still powerful and useful, but your first port-of-call for updating the structure of your site is the Build system. In Metalsmith it's the pipeline, in Nanoc is the Rules file, and others have their own way of expressing it. This gives a lot of power and keeps it in the area that a Software Engineer would feel comfortable.

It's great that the SSG ecosystem is so diverse! There are many approaches to building a static site. It's best to take the time to understand your goals and pick a solution that will deliver what you want.