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:
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, much like many modern SSGs offers the ability to work with remote data. It does so via its
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.
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.
Thanks to torchlight.dev for the syntax highlighting in this post.