In my opinion, 2020 was the year that Jamstack went mainstream.

As more developers look to get started with the Jamstack, what tools do they need to get started? For better or worse, the Jamstack offers a multitude of options and isn't prescriptive about what you should choose. This leaves developers looking for some guidance.

It is no more true than for static site generators, which are a key ingredient in developing Jamstack applications. According to staticsitegenerators.net, which maintains the most comprehensive list, there are currently 460 options available. In this post, we'll look at a number of the most popular options. My goal isn't to tell you which tool you should use - that can depend on a number of options, including personal preference. However, I hope to give you the information you need to begin evaluating these options and the things to think about when making your choice.

What is a Static Site Generator (SSG)?

The basic concept behind an SSG is pretty simple.ake markup - using things like Markdown or HTML - and data - using JSON, YAML, or TOML - then combine this with templates - using tools like Handlebars, Liquid, or Nunjucks - to generate the pages of a website. This is similar to what happens with any dynamic web programming language like PHP, for example, but the key difference is that this is done at build time rather than on the server in response to each page request. This is why we call them static site generators since the assets they create (i.e., the ones we will deploy) are all static.

Static site generators can be built in just about any language. In fact, there probably is one that already exists built in any language that you can think of. The ones we'll discuss here are built in languages like Ruby, Go, and JavaScript. However, the importance of the underlying language of an SSG can be overstated. For example, Jekyll is written in Ruby, but it is unlikely you'll ever write any Ruby when using it (unless you have very specific needs that require a new plugin). So, as we'll discuss later, while the language a tool uses is something worth considering, it should rarely be the primary consideration.

There are two broad types of modern static site generators. Traditional static site generators are not prescriptive on how the frontend of your site is built. Their job is simply to generate the HTML, CSS, and JavaScript assets, not to dictate how they are built. The other type of static site generator is built using a JavaScript framework like React, Vue, or Angular. In these cases, the SSG still generates static assets, but those use the prescribed frontend framework and may generate content at build time or load it client-side at runtime as in a typical single page application (SPA). We'll cover both types.

Why you should use one

As I mentioned in the intro, a static site generator is a key ingredient in developing Jamstack applications. Many of the key benefits of the Jamstack come from using them.

Speed

By default, static assets are faster than server-rendered assets simply because there is no application server involved in generating pages and no database either. Add to that the fact that static assets can be served on the edge via a CDN rather than a traditional web server, and you have all the ingredients for an incredibly fast site.

Let's be clear, as the recent Web Almanac showed, static assets alone don't make your site inevitably fast. Developers can still do things like overuse client-side JavaScript or use poorly optimized images and end up with a poorly performing Jamstack site. Still, a well-built site that uses static assets from a static site generator running on the edge via a CDN has everything going in its favor to be blazing fast.

Security and reliability

No site is perfectly secure, but static assets offer very few attack vectors. There is no database to hack and no application server to compromise. By running at the edge on a CDN, there isn't even a single web server one could gain access to. It's true that most Jamstack applications rely upon third-party services for some degree of build-time or run-time data, and these represent their own risk.

For many of the same reasons, Jamstack sites don't go down like traditional server-side applications. There's no database connection to fail, no server to go down, no runtime error on the server to cause a failure. Even if a new build fails for some kind of build error, the site remains up with the prior generated assets. And if your site has the luck to see a sudden rush of traffic, static assets scale by default.

Not just static!

You may be thinking, this is great, but depending on static assets means my site is inherently limited - my site is dynamic, and there's no way I could use a static site generator to build it. Don't let the use of a static confuse you. Jamstack sites can be incredibly dynamic by leveraging APIs and services both at build time and on the client-side to accomplish nearly anything a server-side application can.

By default, static site generators are all about dynamic content. This is literally what they were created for, just at build time rather than run time. This content can come from file-based data in JSON, YAML, or Markdown, but it can also come from an API. For instance, it's become common for a Jamstack site to generate static assets based upon a third-party headless content management system. The content is typically pulled from the API at build time to generate static assets via the SSG.

For those dynamic aspects of a site that cannot be handled at build time, there's client-side JavaScript. Just because the assets an SSG generates are static doesn't mean they can't be incredibly dynamic on the client. In many cases, the static site generator produces a full single-page application (SPA) that is just as dynamic as any other modern web application.

Here’s a bunch of services available for various dynamic features:

• AWS Lambda & Azure functions for backend functions
• Netlify for identity, forms, and backend functions
• Auth0 for identity
• Algolia for search
• Snipcart for e-commerce
• Staticman for user-generated content

These are just a few examples of what's out there.

The best static site generators options in 2021

What's become clear in the world of static site generators is that JavaScript has taken over. Four of the six options we'll cover here are JavaScript-based. In most cases, these leverage a JavaScript framework. But, it's important to emphasize, there are plenty of options for anyone who doesn't want to:

1. Use a JavaScript framework (or doesn't want the SSG to be prescriptive of it)
2. Use JavaScript to develop their Jamstack site (at least on the build side)

Next.js

Calling Next.js a static site generator is a bit misleading. Next.js is a React-based web framework that can be used for building web applications that are completely server-side rendered (SSR), statically pre-rendered (i.e., SSG), or even hybrid SSG/SSR applications. Next.js offers a variety of built-in tools for routing, state, code-splitting, and more that make it easier to build a React SPA.

Next.js brings a ton of momentum into 2021, which is why it is first on this list. Over the course of 2020, the features in Next.js around both the SSG and hybrid SSG/SSR expanded considerably. This began with a number of 9.x releases that culminated in the release of Next.js 10 in October to coincide with the first-ever Next.js Conf that had over 30k attendees. There was the release of new methods for pages to define static data and routes via getStaticProps() and getStaticPaths()to incremental static build support that speeds up build times dramatically.

These recent emphases in Next.js around hybrid SSG/SSR applications are also driving a debate in the Jamstack community over what defines Jamstack, even as Vercel, the company behind Next.js, has decidedly moved away from the Jamstack term. Even Vercel competitor Netlify now offers the ability to run hybrid SSG/SSR apps via their next-on-netlify plugin.

Learning Next:

Eleventy

Eleventy garnered a ton of attention over the past year by arguably positioning itself as the antithesis of the framework-based SSGs and by focusing heavily on performance. What makes Eleventy unique is that, while it is JavaScript-based, it follows the more traditional SSG model of being focused on providing tools for generating static assets from data and templates while not being prescriptive in any way about the use (or not) of a frontend framework. Even Mozilla recently adopted Eleventy for sites like the Firefox extension documentation and the new version MDN.

Eleventy's approach combines the simplicity of other traditional SSGs like Jekyll or Hugo with the popularity of JavaScrip, while also bringing in the ease of working with data from external APIs that are a highlight of the framework-based SSGs. For example, Eleventy makes it easy to consume external content via an API at build time, something some other traditional SSGs do not yet do or do with significant limitations.

As with any traditional SSG, the lack of a prescriptive framework doesn't mean that you can't leverage one. However, because Eleventy is JavaScript, it allows for potentially unique solutions. For example, you can leverage the aspects of a framework without requiring using one on the frontend. Netlify did so in their Netlify.com redesign that used Vue components in Eleventy at build time.

Learning Eleventy:

Gatsby

I would argue that no SSG has been more influential since the launch of Jamstack in 2015 than Gatbsy. Even if it was overshadowed in the past year, at least in part due to some controversies. Gatsby, which is React-based, ushered in the era of JavaScript-framework-based SSGs that now seems to dominate the Jamstack space. It also helped popularize the use of GraphQL for data in Jamstack applications and introduced a community-driven plugin architecture whose success other SSGs still try to emulate.

One of the biggest complaints you often heard about Gatsby was the build times, something they have worked hard to address this past year, in particular by launching incremental builds. This feature is supported on Gatsby's own Gatsby Cloud offering, but also via services like Netlify, and it can reduce build times to mere seconds in many cases. They also overhauled their routing to automatically create routes in a manner similar to Next.js.

Gatsby has always been an entry point into the Jamstack for new developers. They continued to enhance features for new developers, including the launch of Gatsby Recipes, which are prebuilt solutions for common problems. These offer both the code and provision the necessary resources for you. As you might expect, this also includes the ability for the community to contribute their own recipes. Combined with a redesigned and reorganized docs, Gatsby is set to continue to bring in new developers in 2021.

Learning Gatsby:

Nuxt.js

As the name might imply, Nuxt.js has a lot of similarities to Next.js, with the glaring difference being that it uses Vue instead of React. For similar reasons as Next.js, it also would be a bit misleading to refer to it as purely a static site generator as Nuxt can function as either an SSR framework for building SPAs or as an SSG. However, this past year Nuxt.js made some major improvements to their SSG offering. They introduced full static mode, which allows you to target an entire site as static and adds build and payload improvements specifically aimed at static apps.

Building upon those improvements, Nuxt also improved their static build time by allowing builds to be generated off of a build cache when only content has changed, meaning it can skip the full webpack build. This can yield dramatic decreases in build times wherever you deploy your app.

Learning Nuxt:

Hugo

Hugo is a "traditional" SSG built-in Go that was created back in 2013. By traditional, I mean that, like Eleventy, it focuses on providing the tools to generate full static sites, without any prescription on how they are built (i.e., no frontend framework). Hugo's biggest differentiator has always been its build time. Being built in Go means that Hugo is incredibly fast - often completing in mere milliseconds. This can be powerful both for large sites but also as deployment options like Netlify, for example, now charge for build minutes over a monthly allotment.

Over the past year, a number of improvements have been made to Hugo that continue to modernize how applications are built using it. Many of these features improved Hugo's asset building system to make it easier to use modern tools and processes like PostCSS, npm, and JavaScript bundling. Improvements included adding a native JavaScript bundling that supports import support, JSX transpilation, and TypeScript support. Other releases included improved PostCSS support and npm pack, which combines npm packages across the project, including themes and modules.

Learning Hugo:

Jekyll

Jekyll is a Ruby-based static site generator that popularized the entire concept of an SSG. It was originally created by GitHub co-founder Tom Preston-Werner in 2008 and gained a lot of popularity in part by being supported in GitHub Pages, which ran Jekyll's build process when a change was checked into GitHub - a process that has since become pretty much standard. Jekyll is a "traditional" SSG like Hugo and Eleventy. While it can create just about any kind of site, it continues to be more "blog-centric" by making it extremely easy to launch a static blog.

Jekyll 4.0, released in 2019, addressed the issue of long build times in Jekyll. 2020 didn't introduce any major changes to Jekyll but did add features like new and improved filters and new hooks.

Learning Jekyll:

Honorable mentions

Gridsome

Gridsome is another popular JavaScript-based SSG that uses the Vue framework. In many ways, like Nuxt.js is to Next.js, Gridsome is to Gatsby, offering features like a plugin architecture, GraphQL support, and others that bring a Gatsby-like experience to the Vue ecosystem.

Bridgetown

Bridgetown is a new SSG this year. It started as a fork of Jekyll that aims to bring modern web development tools and practices like the use of Webpack, PostCSS, and npm.

VuePress

VuePress is another Vue-based static website generator that is built by the Vue.js team itself that aims for minimal setup and a focus on Markdown content.

Scully While there have been multiple React and Vue-based static site generators, until Scully was released in late 2019, there was no Angular-based option.

Things to consider when choosing an SSG

As you may have seen from the descriptions, each of the options listed here is quite different. To pick the best static site generator, it's best to narrow your options based on your own preferences. A little research goes a long way. They will all get the job done. Nonetheless, here are some guidelines to help you make a choice.

Do you require a hybrid statically rendered and server-side rendered (SSR) site?

If having some parts of your site use server-side rendering is a requirement, then right now, you'd choose Next.js. Nuxt.js supports SSR and static rendering, but it is an either-or case at the moment to the best of my knowledge.

That being said, don't overstate the importance of this. It can be easy to opt for SSR in many cases simply as a matter of comfort and habit. I would argue that, in most cases, you can accomplish the same thing either through the use of APIs called either at build-time or on the client-side using JavaScript.

Do you want to use a prescribed frontend framework?

Frontend frameworks offer a lot of tools that can make the development of sites with complex UI requirements easier to build.But, in many cases, they can be heavy, especially if the site's requirements do not necessarily call for a frontend framework. For example, if the primary goal of your site is to serve up content in some fashion, you can probably get away without one and sprinkle in dynamic functionality using plain old JavaScript without a framework. In these cases, you're probably better off picking one of the "traditional" SSGs that offer the flexibility to choose not to use a framework.

How important is build time?

Especially in the case of large sites that need to generate a lot of pages, build time can not only impact your development by slowing down testing but also your costs by incurring overages at your deployment platform. It can also impact the experience of content editors who may need to wait long minutes to see an important change or fix go live or even have to wait for a preview to build.

If build speed is extremely critical, Hugo is the most obvious choice. Still, this is another concern that can be overstated by developers who tend to gravitate towards prematurely optimized performance. Almost all of the engines listed have dramatically improved their build times in recent years, closing the gaps that used to exist. In most cases, other concerns will be more critical in the long run than build time.

What type of project are you creating?

Depending on what you are building, there may be specialized tools for your specific use case. In terms of SSGs, a number of them specialize in documentation in general or API documentation specifically. These include Docsify, Slate and MkDocs.

Outside of documentation, I am not aware of any SSGs that specifically tailor to a use case. However, there are many that have starter projects or themes for specific use cases that can jumpstart your project. For instance, Next.js has a huge examples library, and Gatsby has an enormous plugin library, both of which offer quick tools that should help you get started with your specific use case. Honestly, just search your use case and the SSG you prefer, and you're likely to find a starter kit for the type of project you want to build.

Is language important to you?

First, let me emphasize that the end result, regardless of what SSG you choose, is still HTML, CSS, and JavaScript. Just because an SSG is built in Go or Ruby, for instance, doesn't mean that you need to code in Go or Ruby or that your end result will be any different. That being said, if you have a strong preference for a specific language or you have specific requirements that would require building plugins in the SSGs native language, then this can be important. While a majority of the tools discussed here are JavaScript-based, there are SSGs built in almost every language available - just go to Jamstack.org's list of generators and filter by your preferred language.

Closing Thoughts

As you may have noticed, there are no hard and fast rules for picking an SSG. A lot really depends upon the personal preference of you and your development team.

The good news is that the Jamstack ecosystem is thriving, which means that there are solutions out there that can fit just about any preference. It's incredibly easy to get started - you can typically build an entire example site from scratch in an afternoon and get a good feel for how a specific SSG works.

So my advice is to have fun and experiment - try out a few that catch your interest!

---

If you've enjoyed this post, please take a second to share it on Twitter.