Hydration is a term used in computer programming when generally talking through the process of filling an object with data.
An object is partially hydrated when only some of the fields are loaded into it. One may want not to load data that is not going to be used to avoid wasting bandwidth, security pitfalls, CPU cycles loading, transferring, and setting routines. [3]
When it comes to web development it usually means to fasten a loaded markup with functionality, using client-side JavaScript to add application state and interactivity to server-rendered HTML.
Hydration (or rehydration) is a technique in which client-side JavaScript converts a static HTML web page, delivered either through static hosting or server-side rendering, into a dynamic web page by attaching event handlers to the HTML elements. [2]
Rehydration: “booting up” JavaScript views on the client such that they reuse the server-rendered HTML’s DOM tree and data. [1]
Differences between rendering approaches on the web has implication in performance metrics. One must consider the trade-offs through the lens of experience.
Server rendering is a way to avoid additional round-trips for data fetching and templating on the client. The full HTML for a page is generated on the server in response to navigation. Server rendering produces: [1]
- Fast First Paint (FP)
- Fast First Contentful Paint (FCP)
- Fast Time to Interactive (TTI)
This is possible because you’re just sending text and links to the user’s browser and so, it works well for a large spectrum of device and network conditions.
It sounds interesting, right? A faster TTI means a fully interactive page available to users asap. However, as with a lot of other things in development, we must consider the trade-off.
The primary drawback to this approach: generating pages on the server takes time, which can often result in a slower Time to First Byte (TTFB). [1]
Client-side rendering relies on the browser to fully render pages using JavaScript. All logic, data fetching, templating, and routing are handled on the client rather than the server. [1]
In terminology definitions presented in [1] Server-Side Rendering, Client-Side Rendering, and Rehydration are defined in separated bullets under the Rendering context. Still, they are bounded when it comes to application.
It means that server rendering and client-side rendering can be combined through rehydration in something called Universal Rendering or simply SSR. [1]
One may consider performance drawbacks as the negative impact on Time To Interactive delaying interactivity due to JS due to no response to input until the client-side JS is executed and event handlers have been attached.
Hydratation is related to the user experience through performance metrics. Not only a technique but also a strategy designed to deliver the expected interactivity experience to the user.
An infographic is available in [1] showing the server-client spectrum:
Conclusion
In 2019, developers were encouraged by Jason Miller and Addy Osmani, to consider server rendering or static rendering over a full rehydration approach. One reason comes down to User Experience due to how extremely easy is to end up leaving users confused between pretense and reality.
Experiences with little or no interactivity, server rendering can represent a more scalable solution to these issues. Experiences built with CSR that rely on large JavaScript bundles should consider aggressive code-splitting, and be sure to lazy-load JavaScript - "serve only what you need, when you need it". [1]
The "Hydration" term was removed from Angular docs in 2017.
References
[1] Rendering on the Web (Jason Miller, Addy Osmani) in web.dev - 2019
[2] Hydration in web development - Wikipedia
[3] What does it mean to hydrate an object?
[*] Cover image taken from https://www.ironin.it/
Top comments (0)