SSGs were revolutionary when they entered the scene around 2008. But they are still relevant. And they are still great. And for many of the same reasons they were compelling in 2008.
There are a lot of reasons to love static site generators (SSG) more than 15 years after they hit the scene.
This is because SSGs often provide a framework for working more efficiently and DRYing up code without obfuscating the code presented to the user. You can see exactly what's being generated and have control over it.
It's more comforting for me to loosen up that control after I know enough about what's going on to have confidence in the process.
As much as I love SSGs, they aren't right for every situation. The truth is that they don't scale well. And I've tried. At the enterprise level, with thousands of pages and an increasingly complex architecture, we trie to make an SSG work, and it just didn't do well.
Generally speaking, SSGs are not built to serve large or complex websites. They can, but it's usually more challenging than choosing a framework built for more complexity.
Without going into the details of the benefits and challenges (which I'd be happy to do if you ask, because I love talking about these things), there's one thing about SSGs that keeps me coming back and at least considering them for any project: you can't break production.
When users interact with that code, all the content is (or should be) already there. No need to go fetch content.
Fewer moving pieces. Fewer opportunities for things to go wrong.
It’s difficult to choose a CMS today because there are so many options. But why are there so many options?
Learn how to build a static API with Node.js. We'll write a node build script that converts local YAML files into a set of structured JSON output files.