Static sites forever
The case for a personal site that is just files, and will still be files in twenty years.
Every page of this site is a file. Not a route resolved by a process, not a row hydrated by a runtime — a file, sitting in a directory, sent to you by the dumbest possible server doing the thing servers have done since 1991. This is a deliberate bet about time, and I want to write it down.
Personal sites die of dependency, not of neglect. The essay from 2009 is fine; the CMS under it is not. The database needs a version of PHP that needs a version of a server that nobody rents anymore. Every moving part is a clock counting down to a weekend of migration — and eventually one migration doesn't happen, and eleven years of writing 404s into the fog.
A directory of HTML has no clock, or almost none. Its dependencies are the
browser and the filesystem — the two most backward-compatible artifacts in
computing. It can move hosts with rsync. It can be archived by anyone with
wget, including future me, including the Internet Archive, including a
grandchild with a USB stick. Longevity is mostly the art of having fewer
dependencies than the things trying to kill you.
The build can be as modern as it likes — this one runs a component framework, a typed content pipeline, and a contrast-checking gate — because the build happens once, on my machine, where complexity is cheap and reversible. What leaves the machine is inert. The reader pays no tax on my tooling: an article here is readable with JavaScript disabled, because the JavaScript is decoration, not load-bearing wall.
There are honest costs — no comments without a third party, search done ahead of time, anything "live" fenced off — and this site accepts every one of them. They are the membership fee of the only club that interests me: sites that will still open.