A static site generator (SSG) is one of the critical components of the JAMstack. But there continue to be a lot of choices when it comes to static site generators, with new options still appearing with regular frequency. According to staticsitegenerators.net, there are 460 of them. Now, it's true, they vary in terms of whether they are currently maintained and updated, but even StaticGen, which aims to be more selective in what it includes, lists over 280 options.
So, how are you supposed to know what's right for you? I'd love to offer you a "X is the best SSG, hands-down" recommendation, but that's not realistic. Instead, in this post I want to offer you some guidelines that I think can help you choose the best SSG option for your project.
Before we start though, I want to note that this is, by nature, an opinionated exercise. My intent is to offer clear and useful advice, not to criticize any particular tool, either in my discussion of it or my exclusion of it (by nature, when dealing with hundreds of options, I am liable to leave someone's favorite off the list).
What Is Your Level of Experience?
If you are a genius developer with unlimited free time and a deep expertise in static site generators, then any of the options will likely work for you, but, then again, you probably think you should probably just go roll your own! For the rest of us, our level of experience can factor into choosing an existing option.
New to JAMstack?
If you are relatively new to the JAMstack it's a good idea to stick with some of the more established options with large communities. This is because finding "how to's" and help from a variety of sources on a range of topics will be much easier. Some of these options would include:
- Jekyll - One of the older options, Jekyll is built in Ruby. It built a large community in part based on the fact that it was the option originally supported by GitHub Pages.
- Hugo - Hugo is a Go-based SSG that has also been around for some time. It built a strong community due to its focus on a very fast build speed.
- Gatsby - Gatsby is a JavaScript-based solution that gained a lot of popularity in part based on its use of React, whose community grew enormously, and its ecosystem of plugins.
Some JAMstack Experience?
If you come in with some degree of experience with the JAMstack ecosystem and tools, there are a number of additional options that have been gaining steam lately. These have growing communities and are well-documented, but haven't been around as long as the other options, which may present some challenges. Some of the popular options in this category would be:
- Next.js - Next.js is a React framework that has been around a while and has a huge community. However, Next.js had limited options for the JAMstack, only recently adding some key features.
- Eleventy - 11ty is a JavaScript-based solution that has been gaining a good deal of popularity lately in large part because it does not rely on a specific frontend framework.
- Nuxt - Nuxt is like Next.js but for developers who prefer to use Vue.js as their frontend framework rather than React.
- Gridsome - Gridsome is another JavaScript-based option that has been gaining interest because of its use of Vue.js.
Experienced JAMstack dev?
Obviously, you are free to live on the cutting-edge if you like regardless of your level of experience, but I generally wouldn't recommend it for most - especially if you have some semblance of a deadline. As I mentioned, there are new SSGs coming out all the time, which, by nature, will have relatively small communities and available resources. Some recent examples include:
- Scully - Scully is a new JavaScript-based solution that finally gave Angular developers an option to create JAMstack sites using their preferred frontend framework.
- RedwoodJS - RedwoodJS is a brand-new JavaScript-based option that is earning a lot of buzz in part because it was built by Tom Preston-Werner, one of GitHub's co-founders (who also, not coincidentally, originally created Jekyll), and because it aims to bring a Ruby-on-Rails-like "full stack" approach to the JAMstack.
Does the Language or Framework Really Matter?
As you might have noticed, most of the options above are built upon JavaScript. This is a recent development in the world of SSGs. In fact, in the prehistoric SSG era (i.e. 2016) I was asked to give a presentation on JavaScript SSG tools. At the end, I would share which one I recommended you use, and the answer? None of them. Yet today, there are a number of outstanding JavaScript-based options.
There are also a ton of non-JavaScript options. Pretty much any language you write, there is an SSG built in that language. For example, there are some popular options for Python devs including Pelican and Lektor. There are options for almost any other language you can think of but the amount of usage, updates and community support is often limited. Heck, there's even a Swift-based option now.
That being said, I'd argue that, in most cases, the underlying language isn't all that important unless you plan to write your own extensions for the tool (assuming it supports them). Most of the time, you'll be working in whatever templating language/framework the SSG uses.
If you have strong opinions about a particular framework, then you may want to consider a tool that is built using your preferred framework (ex. React, Vue, Angular). It's important to keep in mind that just because you use a tool that isn't framework based (ex. Hugo, Jekyll or Eleventy) doesn't mean you can't use a frontend framework for your web application. So I would advise that you not let your preferred frontend framework limit your options.
On the other hand, if you don't know a particular framework, this can make the learning curve steep for some framework-based SSGs. For example, if you don't know React, it can make learning Gatsby or Next.js tougher. Or if you know Vue but not React, your learning curve on Gridsome or Nuxt may be easier.
It's Tough to Go Wrong
While I haven't used all of the options I discussed here, the truth is there are a ton of worthy options, so it's tough to make a wrong choice. There are some feature differences, of course, but having used a ton of SSGs over the years, I've found that you can get the job done with pretty much any option. In my view, narrowing your choices comes down to 3 main factors:
- How steep will the learning curve be? Factors like documentation, community help forums, language and framework can all be at play here.
- What features do you need and how heavily will you need to customize? While you an accomplish almost anything with any one of these tools, some have features, themes or plugins and a plugin ecosystem that can help speed up your development. If they don't have a feature or plugin you need and you may need to customize the functionality by writing a plugin of your own, then the language the tool was built in can become an important factor. Build performance can a "feature" and a factor here as well, especially if you have a large site that updates often.
- What are your personal preferences? Do you have a strong preference for a particular language or framework? Or a strong distaste for either? Personal preferences are important factors but be careful of letting them lead you to simply following the crowd - explore the options that can fit your needs not just what "cool kids" are using.
The JAMstack ecosystem is rich - take advantage of it and explore!
Top comments (9)
Pelican is another solid SSG. It was introduced the same time as Jekyl, a long time before Hugo or Gatsby came into being. Yes, it's that old.
It's reliable and actively maintained even after all these years, with a robust plugins system which most of the new SSG lack, and has a thriving community.
I think the reason it does not get mentioned in the current discussions, because it is built in Python. Most of the web development crowd has moved to JavaScript.
You're right and I do mention Pelican briefly in the post in the section about language. Having been working with these tools a long time, I am aware of it though I've never used it. I do think the JS tools get more attention these days, but two of the biggest (i.e. Hugo and Jekyll) are not JS.
Jekyll is the oldest, and Github pages support it out of the box. Hugo has speed working for it, and other SSG cannot even eat its dust.
So Pelican is very much like the middle child of SSG 😃
Really good post! The problem I face with using SSGs is that there are too many choices regarding SSGs and not really much info on what to choose and why. Your post touches very nicely on this and is very helpful.
Why cannot you build you own, like use Express with templating engine and web scrape it?
Still, there is a big problem with not being SPA-like in Internal Links, and JavaScript/SPA integration, if you need it.
Another idea is Webpack pre-render plugins, like Vue's, but I have no idea on how to make it work with async contents, like REST API (well, I am not well-trained in GraphQL...)
whoa!
I love Jekyll, I think it's the way to go, but I am trying Gatsby now.
Jekyll is slow and must use date in every markdown post filepath.
I wrote my own static blog generator because I had specific requirements :-). Example blog: Plurrrr.