Commentary

Why I keep choosing boring tech for what I build.

2026-04-02 · 4 min read · Content

This site is hand-written HTML, one CSS file, and a few hundred lines of vanilla JavaScript. No framework. No build step. No deployment pipeline beyond copying files onto a server. I have built things this way for about a decade. Every personal site I have built like this still works. Almost none of the framework-based ones do. That is not a slogan. That is the track record.

What I lose

Component reuse, mainly. The nav bar lives in a partials.js file instead of a proper component. Want a new top-level page? I touch three files, not one. The author experience is clunkier than React-and-Next.js would be.

I also lose the ecosystem. No quick npm install for that one nice slider. No SSR. No type checking unless I bolt it on myself. No hot reload. I save, I refresh. These are real costs. I am not going to pretend otherwise.

What I get

The site still works in five years. No dependency shipped a breaking change. No build tool got deprecated out from under it. No CSS-in-JS library rebranded itself and dropped its old API. HTML I wrote in 2017 renders, today, identically.

It is fast. Not "fast for a JavaScript site." Actually fast. The whole thing is under 50KB. The browser parses it in milliseconds. No hydration because there is nothing to hydrate.

I can read every line of it. When something breaks, the stack is shallow. The bug is in code I wrote. Not in transitively imported library number 47, three abstraction layers down, maintained by someone who has moved on.

It is portable. Open the folder in any browser. Drop it on any server. Zip it, email it. Static HTML is about the most universal computing format that exists, and that universality is itself a feature.

A framework hands you superpowers and then asks you to maintain a relationship with it for the entire life of the project. The static site does not ask you for anything.

When boring is the wrong call

For anything with serious interactive state, real-time updates, or complex auth, the framework cost is worth paying. I would pay it. I would not build a Slack clone like this. I would not build a banking app like this. That would be stubbornness, not principle.

A blog? A docs site? A small landing page? A personal project you want to come back to in three years without rebuilding it before you can even start? Boring wins, and it is not close.

A small heuristic

Before you reach for the framework, ask one thing: does the user's experience of this page actually require JavaScript? If the answer is no, the framework is decoration, not infrastructure. Decoration compounds its costs. The benefits mostly do not.

Off-topic, but related. The same logic runs through most other things I touch. Old tools. Plain text. Single files. The failure mode of choosing boring is "slightly less fashionable." The failure mode of choosing exciting is "the thing is broken and I cannot work out why." I know which of those I would rather be standing in.