Blog

May 12, 2026 · Engineering

The Case for Less JavaScript

Every kilobyte you ship is a tax on the reader. Here's how I decide what earns its place.

The Case for Less JavaScript

Most of the JavaScript on most pages buys the reader nothing. They came to read, and they got a runtime instead. The fix is not zero JavaScript - it’s a burden of proof.

The default is HTML

Start every component as static markup. It renders, it’s accessible, it’s fast. That’s the baseline. Anything beyond it has to justify the cost.

Islands earn their hydration

A theme toggle? Hydrate it. A copy-to-clipboard button? Hydrate it. A 50 KB carousel for three images that could be a CSS scroll-snap row? Defend it or delete it. The island model makes the question explicit: this component, and only this component, ships JS.

Measure what the reader feels

Lighthouse scores are a proxy. The real metric is whether the page is usable before the spinner would have finished. Static-first gets you there by default, because there’s nothing to wait for.