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.
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.
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.
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.
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.
Editor note: See how you can integrate comments to your static site here.
The best static site generators options in 2021
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
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.
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.
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.
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.
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.
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.
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 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.
Do you want to use a prescribed frontend 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?
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.