What Does Hydration Mean?
What Does Hydration Mean? êŽë š
The term hydration gets thrown around a bunch when talking about JavaScript frameworks.
Short answer
itâs the process which JavaScript executes, reconciles, and makes interactive the HTML that is already in the DOM via server-side rendering (SSR).
Iâll elaborate for clarity.
The JavaScript framework Next.js, a React-based framework, is capable of server-side rendering and hydration, so letâs start there, knowing that other major frameworks do this too. I appreciate the clarity of the docs of React itself:
In React, âhydrationâ is how React âattachesâ to existing HTML that was already rendered by React in a server environment. During hydration, React will attempt to attach event listeners to the existing markup and take over rendering the app on the client.
But first, letâs begin with client-side only rendering. Say we have some fruit inventory. We loop over it making buttons that, when clicked, show the inventory. Ya know, like every very real world application.
export default function FruitPage() {
const inventory = [
{
name: "Apple",
quantity: 10
},
{
name: "Orange",
quantity: 8
},
{
name: "Banana",
quantity: 27
}
];
return (
<div className="box">
<h2>Check Fruit Quantities</h2>
{inventory.map((fruit) => {
return (
<button
onClick={() => {
alert(`There are ${fruit.quantity} ${fruit.name}s.`);
}}
key={fruit.name}
>
{fruit.name}
</button>
);
})}
</div>
);
}`
Iâll chuck that on CodePen here, which will run no build step here and just client side render it:
CodePen Embed Fallback
The HTML that the browser receives for that page is sometime referred to as an âempty shellâ. Itâs an HTML document, but it doesnât have any of the real content that weâre intending to put there. We get this:
<div id="root"></div>
The client-side rendered application gets rendered inside that when itâs ready. Iâm not going to say that there is no place in this world for client-side-only rendering, but Iâll say itâs not ideal generally and I like that more and more itâs not the default. Why not ideal? If JavaScript doesnât load for any reason, there is no website at all. And there are lots of reasons why JavaScript wouldnât load (much moreso than HTML), like a mistake is throwing an error, there was a network hiccup, itâs a large file that is taking an unexpectedly long time on the userâs network, the user is intentionally or unintentionally blocking it, etc.
If we run this is an off-the-shelf Next.js build instead, which does have a build step, the HTML output will look like this instead:
Iâve highlighted the minified HTML there to show that the HTML weâve written in React/JSX makes itâs way into the HTML that is served by the app.
This is much better! Content is being rendered here directly in HTML in that first response from the server. The browser can work with that and get it rendered immediately. And any programmatic method for hitting the URL for content (e.g. a bot, a curl, etc) will succeed.
Then JavaScript loads and hydrates that HTML. Remember how the buttons had onClick handlers on them? That interactivity will not be present on that first HTML render of site. Thatâs not ideal (and maybe makes buttons a bad example for SSR), but the point is that the content is there. We could be talking about the entire contents of an important marketing landing page, for example.
Tradeoffs
There are tradeoffs here. Weâre layering on another framework to our framework and adding a build process. Weâre adding dependencies and thus long term fragility to our setup. But for the most part, serving âreal HTMLâ to the browser is considered A Good Thingâą and Iâll go ahead and go on the record for saying you should be serving HTML with content to browsers from servers.
It could be argued that going with a framework that uses SSR then hydrates leads to more complex code. You always have to be thinking and coding around the fact that a component can be rendered both by a server and on the client. Youâre writing JavaScript, and it may feel client-side-y. You might reach for the window object or a method on it and be wrist-slapped that that doesnât exist in a server context, so you write conditionals to code around that, which can cause different issues. You might have to fetch data in a way that is server-first and perhaps handled differently than you would on the client. Not to mention: you need a server! Pure-client rendered apps can get away with being served from purely static hosting, which is much more likely to be cheap or free.
What can go wrong?
The most likely problem is mis-matching HTML. Since we started with Next.js, hereâs a post showing off a variety of examples of how this can happen with that framework. In development, youâll likely face show-stopping full page errors with hydration errors, because the framework really wants you to fix them, and you should. Generally, the production build of the site with smooth over the user-facing errors so that the site is still functional. The trouble is that then the site is quite literally doing double the work and the SSR page is being blown away entirely when the client one comes in and doesnât match. Iâve seen user-facing hydration errors breaking a site entirely, so again: possibly fragility here. Dealing with these kind of problems is work and may introduce complexity again.
Does using a JavaScript framework with SSR absolutely require hydration?
If you donât need any interactivity at all, no. Personally, I like the component model of building sites with JavaScript-based components even if itâs largely just static content. Astro excels at that (hereâs a course), but other frameworks can be configured to not output any JavaScript (thus skipping any hydration process).
A blog post famously said âHydration is pure overhead.â
Builder.io
⊠hydration is recovering event handlers by downloading and re-executing all components in the SSR/SSG-rendered HTML. The site is sent to the client twice, once as HTML, and again as JavaScript.
Overhead indeed. Perhaps not ideal, but probably worth it.
The framework Qwik avoids hydration at all with a concept it coined as âresumabilityâ. I honestly donât know enough about it to fully understand the tradeoffs there (I promise: there are always tradeoffs), but if youâre certain that hydration is your main problem, itâs worth a look.
You should also drink more water.