Frontend Labs
⋯

34. Hydration and partial/progressive/resumable hydration

Hydration is the process of taking server-rendered static HTML and "waking it up" — attaching event listeners and internal framework state so it becomes interactive, without re-creating the DOM from scratch.

1. Server sends fully-formed HTML  -> browser paints it immediately (fast!)
2. Browser downloads the JS bundle  -> framework re-runs the same render
   logic client-side, comparing what IT would produce against the EXISTING
   server-rendered DOM
3. Framework attaches event listeners to the existing nodes instead of
   replacing them  -> page is now interactive

The classic cost: step 2/3 requires downloading and executing the entire JS bundle before any part of the page is interactive, even if the user only wants to click one button — full hydration doesn't scale well to large pages on slow devices/networks.

Partial hydration / islands architecture (Astro, Qwik's resumability, React Server Components) fixes this by only hydrating specific interactive "islands" (a like button, a comment form) while the rest of the page (an article body) stays pure static HTML that's never re-processed by JS at all.

Resumability (Qwik specifically) goes further: instead of re-running render logic to reconstruct state (traditional hydration), it serializes the already-computed state and event-listener wiring into the HTML itself, so the client can "resume" exactly where the server left off without re-executing any component code up front — event listeners are attached lazily, only when a user actually interacts with that specific element.

Generated from real-life-JS-guide.md · 8 Oct 2026 16:36