OK, this is not going to be an all encompassing, objective review of available static site generators (SSGs). In this article I will talk about what SSGs I have been enjoying this year, and why.
Recently someone commented that I seem to use a different static site generator (SSG) for every project. This prompted a conversation about the pros and cons of sticking with a familiar stack VS trying something new. I explained my position - for projects that are time sensitive (most projects) I prefer to use technologies that are familiar and predictable to me. However, for projects where I have more freedom, i.e personal projects, I like to try new things. And yes, I have a bit of a thing for SSGs. It's only through trying new things that you can find and familiarise yourself with those killer solutions, that you'll come to rely on later. I think SSGs are a great example of this. There are lots of products that we call static site generators, and they differ greatly. I like to keep my hand in with a few, so I know what to reach for when I don't have the luxury of time to experiment.
I wrote a similar post to this back in early 2016; I thought an interesting way to frame this today might be to look at how the landscape and my preferences have changed since then. One of the points I made in that 2016 post was that I hadn't found a non-developer friendly way to manage content for static sites. Maybe I wasn't looking in the right places, but it feels like this is an area that has really improved since then. Headless CMSs are very much part of the JAMstack landscape, of which SSGs are now almost synonymous. This brings me to my first SSG mention:
Gridsome
Getting your data from an external source (such as a headless CMS) can be a little fiddly. Some SSGs are more focused on making this easier than others. I don't have a huge amount of experience with Gridsome, but enough to know that CMSs feel like first-class citizens here. It's early days, but the Starters page at least sets out a direction for ready-made integrations with a really good selection of content / data sources. To try this out, I recreated a simple site I had previously made with Nuxt. Like Nuxt, Gridsome is Vue.js based, which made this migration quick and easy. It's worth mentioning that the two versions are different in that the Nuxt version was server side rendered, while Gridsome creates pre-rendered HTML. That said, the code required to fetch and query the data felt much simpler with Gridsome, thanks to the CMS specific plugin, and the leveraging of GraphQL. If you're into JavaScript frameworks, and in particular Vue, this is a SSG to keep an eye on.
While I wasn't strictly integrating CMSs with static sites in 2016, I was pulling data from APIs. This is a staple of JAMstack today, but just a few years ago the ability to pre-render HTML from remote APIs didn't feel like a common SSG feature. In fact, one of the SSGs I mentioned in the 2016 post, I chose purely for this feature. That SSG was Roots, which is no longer under active development. At the time I used it to build my portfolio site. Today I use my next SSG mention:
Hugo
Hugo, much like many modern SSGs offers the ability to work with remote data. It does so via its getJSON and getCSV functions. What perhaps sets Hugo apart from other SSGs is that this, and other common features are ready to use, out of the box. So whether you want taxonomies, shortcodes, word count, theming - these things are all ready to go in your freshly created Hugo site. For a lot of use cases, you only need to concern yourself with templating. About those templates though, Hugo uses Go's templating language, so unless you are familiar with Go, templating logic will take a bit of getting used to. I didn't find this to be too much of a pain, I do however think the templating in Hugo is the thing most likely to put me off reaching for it. Not so much because you need to work with the ways of Go, but because I've found myself tending to put a lot of logic and variables in these templates at times, which while gets the job done, leads to messy and complicated templates. If I'm going to pinpoint what is most likely to put me off using Hugo, I should say what is most attractive about it. Besides being feature rich and capable, I think the community might be the biggest attraction. The Hugo website has a dedicated and active forum, where in my experience, your questions will be answered. I much prefer the forum format over something like a Discord or Gitter, which seem to be popular with other projects.
In 2016 I mentioned two other SSGs, Jekyll, which was powering my blog at the time, and Middleman, which I identified as my go-to SSG. These two have in common their dependancy on Ruby. This commonality is a significant factor in why I no longer use them. After using Jekyll for many years, a macOS update broke Jekyll on my machine. I was only maintaining one Jekyll site (my blog) by this time, so after spending a significant amount of time troubleshooting I decided it would be quicker to just rebuild my blog with a different SSG. I don't imagine this extreme scenario is common, but I think some consideration should be given to whether you want to setup / maintain a Ruby development environment, just for static sites. This is probably in part why out of the top ten SSGs on staticgen.com eight are written in JavaScript. As it turns out, since moving away from Jekyll I haven't looked back. The SSG that now powers my blog, has become my new go-to SSG (so I guess its a sort of winner). That SSG is:
Eleventy
Coming back to my point about trying new things - finding an excuse to try Eleventy was really worthwhile. Not only did I find it to be a good drop-in replacement for Jekyll, but having made a few sites with it I found it to be very versatile. Versatility runs right through Elevently. If you are making something simple, it can get out of the way, with zero configuration; making something more complex, it can be very powerful. The options available for working with data I've found to be particularly powerful. JavaScript data files mean you can prepare your data in any way that JavaScript allows, and make it available to your templates. The versatility extends to the templating language too, you can configure Eleventy to use the languages you want. No more putting up with what the SSG dictates. What I think Eleventy generally does really well is allow you to bend and shape it to your needs. It doesn't really presuppose anything about your code. I would say this is less true of other SSGs, to varying degrees. Something like Gridsome is dictating a lot, you are definitely building a Vue app in that case. Hugo on the other hand doesn't necessarily dictate the code that reaches the browser, but your templates will probably be less concise, as you jump though Hugos hoops. If you don't mind doing your own wiring, and you value elegance and simplicity, then Eleventy should be on your shortlist of SSGs.
Honorable mention
A lot has changed in SSG land in a past few years, including my preferred tools. I was wondering if there are any SSGs I was using in 2016 that I would still use today. I could think of one: Lektor. I don't think Lektor has changed much over those years, and it feels kind of pre JAMstack. That said, the value it had to me in 2016 it still has now. Lektor is a static content management system, it only deals with flat-file data. What makes Lektor interesting is while most SSGs tend to be centred around Markdown files with metadata, Lektor has its own file format which allows any number of fields. It's like the difference between Wordpress with and without Advanced Custom Fields. You even get an admin GUI to edit the content once the fields are configured. I find the idea of a very simple setup for a site where pages can be configured to have any combination of fields to be quite liberating; I can see myself using Lektor again in the future.
Top comments (0)