Zero Runtime JavaScript Is a Budget, Not a Badge

ZERO JS is a useful constraint and a useless slogan. Every page here starts at zero client-side JavaScript, which means every script that ships has to win an argument against a static alternative.

The three exemptions

This site allows exactly three interactive behaviours:

1. Theme switching. A single inline snippet in <head> reads storage and sets a class before first paint. Without it, the page flashes the wrong canvas colour for a frame — a real regression, not a preference.
2. UTC clock. Eleven bytes per second of text, updated by one setInterval that does no layout reads. It is metadata, not content.
3. Turnstile. The contact form depends on a third-party challenge. That script is the only remote JavaScript on the site and it never loads on a reading page.

Everything else — navigation, filtering, archive ordering — is resolved at build time.

What “no runtime” actually buys

• Predictable render. The HTML is the application. There is no hydration boundary, no client router, no state to desynchronise.
• Durability. An Astro site built in 2026 is a directory of files. It does not need a matching Node version to keep rendering five years from now.
• A hard design constraint. If a feature needs client state, it has to justify an architecture change in review. Most features do not survive that conversation, which is the desired outcome.

The cost

Content updates require a commit and a rebuild. There is no editorial UI, no draft preview for non-technical collaborators, and search — if it ever arrives — will be a build-time index rather than a client query.

That trade is correct for a personal engineering site: the author is the editor, and the archive is small enough that an index is a few kilobytes.

Rule of thumb

Ship a script when the static version is worse for the reader, not when it is merely more work for the developer.