Static sites outlive their frameworks

Every few years a framework promises to make the web simple and instead makes it a build pipeline. The site works beautifully — until a dependency is deprecated, a toolchain moves, or the person who understood the config leaves.

We keep coming back to plain HTML, CSS and a little JavaScript. Not out of nostalgia, but because it is the only stack we have found that is still working a decade later without anyone tending it.

What a build step costs you

A build step is not free. It is a promise that you will keep a toolchain alive: version bumps, security patches, breaking changes, and a CI job that must not rot. That is a real, recurring cost — and it is invisible in the demo and very visible in year three.

• Supply chain. Every dependency is a thing that can be compromised or abandoned.
• Time to fix. A typo in a template should take a minute, not a toolchain debug.
• Longevity. HTML from 2005 still renders. A config from 2021 may not.

What you give up

Convenience, honestly. No component model, no type-checked templates, no hot reload. On a large application that matters a great deal, and a framework earns its keep. On a content site — which is what most of our work is — it rarely does.

The test we use

Before adopting anything, we ask a blunt question: if we stop maintaining this tomorrow, does the site still work? For a static site the answer is yes. For a build-dependent site the answer is usually no, and the site slowly rots in place.

That single question has saved us from more complexity than any style guide.

Use the tools that earn their cost. But choose the ones that will still be here when you are not.