Static Site Generators

The quiet return of plain HTML

There is a satisfying irony in modern web development: after twenty years of ever more elaborate machinery, some of the fastest, most reliable sites on the internet are once again just folders of HTML files. Static site generators did not invent this idea - hand-coded HTML predates all of us - but they made it practical at scale. And in doing so, they quietly exposed an uncomfortable truth. For an enormous slice of the web, the server we spent years tending was solving a problem we did not actually have.

Think about what a traditional CMS does on every single page view. A visitor requests an article. Code wakes up, queries a database, fetches the post, fetches the author, fetches the comments, assembles a template, and renders HTML - all so it can hand back a page that, in practice, looks identical to what it produced for the previous visitor a second ago. We did that millions of times a day, then bolted on caching layers to avoid doing it. The caching layer was a confession: the work was redundant.

Doing the work once

A static site generator simply moves that assembly to build time and does it once. The result is the same HTML, produced ahead of demand, sitting on a CDN ready to be served. The shift sounds modest. Its consequences are not.

Security is the most dramatic. A static site has no database to inject into, no admin login exposed to the open internet, no plugin running untrusted code on every request. The entire category of vulnerabilities that has plagued popular content systems for years simply does not apply, because there is nothing executing when a visitor arrives. You cannot exploit a server that is not there.

Then there is the operational calm. No patching a runtime at midnight. No database backups to verify. No mysterious memory leak under load. A traffic spike that would have toppled a server is absorbed by the CDN’s edge cache without anyone noticing. I have watched static sites shrug off front-page traffic that would have cost a dynamic stack real money and real sleep.

The trade-off nobody should hide

It would be dishonest to pretend this is free. Static sites are bad at exactly the things servers are good at: anything genuinely per-user or real-time. Comments, search, authentication, a shopping cart with live inventory - none of that lives naturally in a pre-built file.

The honest answer is that the industry stopped pretending the front end and the dynamic bits had to be the same system. The Jamstack pattern - static front end, dynamic features delivered by APIs and services - is the pragmatic settlement. Your pages are static; your comments come from a service; your search runs client-side or against a hosted index. You pay for dynamism only where you actually use it, instead of paying for a server on every page that never needed one.

Choosing your weapon

By late 2022 the tooling had matured into genuinely good options, and the choice says something about your priorities. Jekyll is the comfortable elder, especially if you live on GitHub Pages. Hugo is the speed demon - a single Go binary that builds thousands of pages before you have finished blinking, which is why it owns the large-documentation niche. Eleventy is the minimalist’s favorite, shipping essentially no JavaScript and trusting you to add only what you need. Gatsby and Next.js drag React into the picture, trading lean output for a rich component ecosystem and, in Next’s case, an escape hatch back to server rendering when a project outgrows pure static.

My bias, for what it is worth, leans toward the lean end. The web got heavy. Pages that are mostly text now routinely ship megabytes of JavaScript to render words a browser could have displayed instantly from plain HTML. Eleventy and Hugo feel like a corrective: they remind you that the default should be fast, and that you should add weight deliberately, not by accident.

Why this matters beyond performance

The deepest win is not speed or even security. It is that your content becomes plain text in Git. Suddenly your website has history, branches, code review, and one-click rollback - the same discipline you apply to code. Publishing stops being a nervous ceremony and becomes a side effect of merging a pull request. You write, someone reviews, you merge, and minutes later a globally distributed copy is live. If the build fails, the old version simply stays up.

That is the unglamorous magic of static site generators. They did not give us a flashy new capability. They took something we were overcomplicating and made it simple, fast, and durable. In a field addicted to novelty, that is a rarer and more valuable thing than it sounds.