The Diver's Unbalanced Ballast: On the Hollow Promise of the 'Zero JS' Movement

There’s a purity test making the rounds in our circles. It’s a seductive, almost ascetic ideal: the website that loads without a single kilobyte of JavaScript. It is held up as the ultimate emblem of performance, an uncompromising return to the web’s foundational document model. Zero JS. The phrase itself is a banner, a rallying cry against the bloated client-side frameworks that have, admittedly, often steered us into murky, sluggish waters. But in our zeal to jettison cargo, we risk throwing overboard the very ballast that keeps our craft stable and responsive in a living, interactive sea.

The critique isn’t of the principle—lean, semantic HTML is a profound good. The problem is the absolutism. The ‘Zero JS’ movement, in its most evangelical form, mistakes the tool for the outcome. It champions a technical characteristic (the absence of a file type) over the human experience (the presence of thoughtful interaction). It’s like praising a book for having no spine, because spines add weight. The goal was never ‘zero.’ The goal was ‘appropriate.’

The Forgery of Faux Simplicity

In practice, the pursuit of this purity often leads to a strange kind of forgery. To avoid JavaScript, we lean harder on the server, rebuilding entire pages for the smallest state change. We use elaborate combinations of CSS hacks and HTML form submissions to mimic simple interactions, creating fragile, obscure code that is far less maintainable than a few lines of clear, focused JavaScript. The complexity doesn’t vanish; it merely migrates, often into more convoluted territory, all while we proudly display a ‘0 kB’ badge from our static site generator. We’ve swapped a visible, debatable dependency for an invisible, tangled one.

More critically, this dogma can actively harm the very inclusivity it claims to serve. By rejecting JavaScript wholesale, we implicitly reject the users who rely on it for enhanced accessibility. A properly written, progressively enhanced interactive component—a custom combobox, a live region for notifications, a complex form validation—can offer a far richer and more accessible experience than what HTML and CSS alone can muster. To deny this is to privilege a theoretical performance metric over the tangible daily needs of real people.

The web is not a static archive. It is a medium for application, for conversation, for state. JavaScript is the language of that state. To declare it anathema is to willfully limit the web’s potential to that of a linked pamphlet. Our craft isn’t about building the fastest possible tomb for information; it’s about building the most appropriate vessel for an experience. Sometimes that vessel is a sleek, static dinghy. Often, it needs a rudder, or a sail, or a bilge pump—small, purposeful scripts that give the user control and the interface resilience.

Let us not be divers so obsessed with shedding weight that we forget why we entered the water. The goal is to move with grace, to explore depth, to interact with the environment. Ballast isn’t baggage; it’s what keeps you upright. A few ounces of purposeful, lazy-loaded, well-crafted JavaScript isn’t the enemy. The enemy is, and always has been, thoughtless burden. Our critique should be aimed at the latter, not at a single, powerful tool in our craft.

Notes & further reading

A few pages I came back to while writing this: