Choosing a static site generator

Updated: Tue Nov 26 2024

My initial SSG requirements

When rebuilding my site, it made sense to me to build the site with an SSG because it’s fast, self-contained, and relevant to what we do as technical communicators. The underlying architecture is also far simpler than a database-driven site like my current WordPress site.

• Based on experience, I wanted to avoid Gatsby — too complex requires a team of devs.
• Looking for as plug and play as possible (in retrospect, ha!).
• As low-code as possible. Sure, I can play with HTML, CSS, and configuration and template files, but I didn’t really have time to learn modern JavaScript or Typescript.
• Time to market — How quickly could I publish this so it was relevant to my job search?

I’ve played around with static site generators (SSGs) in the past, and in a prior role our output went through a heavily customized version of Gatsby, though I wasn’t hands-on with it; we had a team of developers to support it.

Lessons learned

However, I quickly learned that when you decide to build a website from scratch with an SSG, you’re building it from scratch. There are many starter themes and frameworks; I played with a few. But at that early stage of the process I didn’t understand enough about how the SSGs worked to know how to properly use them. I also had the time to build from scratch, and inclination to learn some newer tech. I get to play the role of a developer and understand how content is programmatically consumed while revamping the content and content strategy of my site.

A big problem ended up being that I wanted to play with all the toys and build the site, so the focus on the content came last. This explains so much why a content-first approach is so often ignored by developers. But in my case I think this worked out, as I had lots of opportunity to update my messaging, and create a cohesive framework of this series, and make the content more portable.

Also, there is just a lot to do