The Gardener's First Unwatered Seedling: A Critique of the 'Hydration is Inevitable' Doctrine

There is a quiet, almost theological belief that runs through much of our modern front-end practice: that a server-rendered page is merely a dormant shell, an inanimate sculpture of HTML, awaiting the sacred breath of client-side JavaScript to become truly alive. We call this process 'hydration,' and we speak of it not as a choice, but as an inevitability. The received wisdom is clear: you build your page statically for speed, then you must, without question, re-baptize every component in the river of JavaScript to make it interactive. This is the doctrine of Hydration's Inevitability. But what if this fundamental act of re-animation is, in many cases, the first place we introduce instability and delay into an otherwise stable page?

We pour immense effort into crafting a pristine, immediately usable static experience. We optimize images, preload fonts, and structure our CSS to avoid jank. A user receives this complete, functional document in a matter of milliseconds. And then, we often proceed to set fire to our own work. The hydration script arrives, often a hefty bundle, and the main thread is seized. It meticulously rewalks the DOM we just sent, attaching event listeners, rebuilding its internal virtual representation, and re-rendering—quite literally—what is already there. This is the period of 'locked' interactivity, where a button may exist but cannot be clicked, a paradox of presence and absence that confuses users far more than a simple loading indicator ever could.

The Weight of the Unseen Water

The argument for this double work is, of course, interactivity. But the doctrine's flaw is its blanket application. It assumes every part of the page requires the full weight of a framework's reactivity. It rarely asks: what on this page is actually dynamic? A hero section with a static image and text does not need to be hydrated. A footer, brimming with links that should simply navigate, does not need the overhead of a JavaScript framework's event delegation. By hydrating everything, we are watering concrete, hoping something will grow.

The critique here is not of JavaScript frameworks themselves, but of the lazy assumption that hydration must be a monolithic, all-or-nothing event. The emerging counter-movement—of partial hydration, progressive hydration, and islands architecture—is a direct challenge to this doctrine. It proposes a more thoughtful, horticultural approach. Instead of flooding the entire garden, we identify the specific, interactive seedlings that truly need the water of JavaScript: a complex product carousel, a live search field, a interactive chart. We leave the rest of the layout—the sturdy trees and the decorative stones—to exist peacefully as stable, final HTML.

Abandoning the doctrine of inevitability requires more craft, not less. It demands we make deliberate choices about interactivity rather than defaulting to a framework's easiest path. It asks us to see our server-rendered HTML not as a temporary ghost, but as the permanent foundation. The goal is not to avoid water, but to direct it precisely, ensuring that the first seedling we see isn't already drowning in it.

Notes & further reading

A few pages I came back to while writing this: