Hydration

During hydration, the framework traverses the server-rendered DOM and builds its internal Virtual DOM representation. It must perfectly match the existing HTML structure without causing mismatches. If a discrepancy is found between the server-rendered HTML and the client's first render, a hydration mismatch occurs, forcing the framework to destroy and recreate that portion of the DOM, negating the performance benefits of SSR.

The core purpose of hydration is to bind interactivity to inert HTML. The framework attaches event listeners (e.g., onClick, onChange) to DOM elements based on the component tree. This process, often called event delegation, typically attaches a single root listener and uses internal mapping to route events to the correct component handlers, rather than attaching listeners to every individual node.

Modern frameworks like React 18 and Astro support selective hydration, where only specific interactive components are hydrated, leaving the rest as static HTML. This is a core principle of the Islands Architecture. Techniques include:

• Progressive Hydration: Hydrating components based on their visibility or importance over time.
• Lazy Hydration: Deferring hydration until a component scrolls into the viewport or is interacted with.

An emerging alternative to hydration is resumability, pioneered by frameworks like Qwik. Instead of replaying the application's execution to rebuild state on the client, resumability serializes all necessary state, listeners, and component boundaries directly into the HTML. The client then resumes execution where the server left off without downloading or executing the component tree's JavaScript upfront, resulting in near-zero overhead for interactivity.

Hydration is often the primary bottleneck for Time to Interactive (TTI). The cost includes:

• JavaScript Download: Fetching the framework and component code.
• Parse & Compile: The browser's main thread must parse and compile the JavaScript.
• Execution: The framework must walk the DOM and build its internal state. This can lead to a frustrating uncanny valley where a page looks ready but doesn't respond to clicks.

A mismatch error typically surfaces in development mode with warnings like 'Expected server HTML to contain a matching...'. Common causes include:

• Using browser-only APIs like window or document during server render.
• Rendering content dependent on time zones or random numbers.
• Incorrectly nested HTML tags (e.g., a <div> inside a <p>). The fix usually involves using useEffect hooks or dynamic imports to isolate client-only logic.