The static site generator detour

Jekyll landed in 2008 and the pitch was that your blog is a git repository.¹

Write Markdown, commit, a program turns it into HTML, the HTML goes on a server that does nothing but serve files. No database, no application, nothing to patch on a Tuesday because of a vulnerability disclosure. GitHub Pages made it free and the idea spread through developers who were tired of maintaining WordPress installs for their personal sites.

Hugo arrived in 2013 with the same model and a build fast enough to be unremarkable at thousands of pages. Eleventy came later with a friendlier attitude to JavaScript. The category settled.

What it got right is worth listing, because a lot of it is not about speed.

Content in version control. History, branches, review, and a backup by construction. After you have worked this way, going back to content that exists only in a database feels like working without a net.

Content in a readable format. Markdown files with front matter can be read by anything, migrated with a script, and opened in fifteen years by a text editor.

No runtime. The attack surface of a directory of HTML is approximately zero. This is the part people underrate: a large fraction of CMS operational pain is patching.

Deployment as a build artifact. The site is a folder. You can diff two builds and see exactly what changed.

Then the ceiling, which everyone hits in the same order.

The first is that non-developers cannot use it. This is not a small caveat, it is the whole reason CMSes exist. Asking a marketing colleague to clone a repository, install a toolchain and open a pull request to fix a typo is not a workflow, it is a refusal.

The second is that anything dynamic needs another system. Search, comments, forms, anything personalised. You end up with a static site plus four SaaS products, which is not obviously simpler than the thing you replaced.

The third is build time. Fine at a hundred pages. At fifty thousand, a typo fix is a fifteen minute wait, and incremental builds are the hardest problem in the category.

The response was git-backed editors. Netlify CMS put a form in front of the repository and committed on save, which is exactly the missing fourth part from the earlier definition. It made a static site into a CMS by adding a way in that was not the storage format.

They mostly worked. The reason they did not take over is that the editing experience was thin next to what people were used to, and the abstraction leaked constantly: merge conflicts surfaced as errors nobody could act on, and build failures meant a publish silently did not happen.

The lasting lesson from the whole period is not that static is better. It is that content in files is better, and that the thing which made the workflow unusable for most people was never the storage. It was the absence of an interface.