Resumability and the Qwik Model

The Hydration Tax

Every framework that uses hydration pays the same tax: the browser must download, parse, and execute JavaScript to make the page interactive. Even with partial hydration, selective hydration, or islands — there's always a moment where JS runs before the user can interact.

Qwik asks a radical question: what if hydration didn't exist at all?

How Hydration Works (The Problem)

Let's be precise about what hydration costs:

Server renders HTML → sends to browser

Browser:
  1. Download all component JavaScript    (~500KB, takes 800ms on 3G)
  2. Parse and compile the JavaScript     (~300ms on mid-range mobile)
  3. Execute every component function     (~200ms for 500 components)
  4. Rebuild React's fiber tree           (happens during step 3)
  5. Attach event handlers via delegation (~10ms)
  6. Run useEffect callbacks              (~varies)

Total: ~1300ms before page is interactive

Steps 1-4 are pure overhead — the server already did this work. The browser is replaying what the server computed. This replay is the hydration tax, and it scales linearly with page complexity.

How Resumability Works (The Solution)

Qwik eliminates the replay. Instead of the client re-executing components, Qwik serializes the execution state into the HTML itself.

Server:
  1. Execute components
  2. Generate HTML
  3. Serialize component state, closures, and event handler references into HTML attributes
  4. Send enriched HTML to browser

Browser:
  1. Parse HTML (browser does this anyway)
  2. Done. Page is interactive.

No JavaScript download. No component re-execution. No fiber tree rebuild. The page is interactive the moment HTML parses.

<button
  on:click="./chunk-abc.js#handleClick[0]"
  q:id="4"
>
  Add to Cart
</button>

The on:click attribute contains a reference to a lazy-loaded chunk and a specific function within it. When the user clicks, Qwik:

1. Reads the attribute
2. Downloads chunk-abc.js (only this tiny chunk)
3. Calls handleClick with the serialized state
4. Page responds to the click

The JavaScript for this handler downloads on interaction, not on page load. If the user never clicks this button, its code never downloads.

The Serialization Magic

Qwik's key innovation is serializing things that other frameworks consider impossible to serialize: closures and execution context.

In React, a click handler is a closure:

function Counter() {
  const [count, setCount] = useState(0)
  return <button onClick={() => setCount(count + 1)}>{count}</button>
}

The onClick closure captures count and setCount from the component scope. These references are JavaScript runtime constructs — they can't be serialized to HTML and deserialized later. That's why React must re-execute the component to recreate the closure.

Qwik solves this with the $ suffix:

import { component$, useSignal } from '@builder.io/qwik'

export const Counter = component$(() => {
  const count = useSignal(0)

  return (
    <button onClick$={() => count.value++}>
      {count.value}
    </button>
  )
})

The $ marks a serialization boundary. component$ and onClick$ tell Qwik's compiler: "This function should be extractable into its own lazy-loaded chunk. Its captured variables should be serialized."

The compiled output:

<button on:click="./chunk-xyz.js#s_onClick[0]" q:id="5">
  0
</button>
<script type="qwik/json">
  {"refs":{"5":{"count":0}}}
</script>

The component state (count: 0) is serialized as JSON in the HTML. When the click handler downloads, it reads the serialized state and operates on it directly — no component re-execution needed.

Qwik's Global Event Listener

Instead of attaching individual event listeners (React's approach: one delegated listener on root), Qwik uses a global event listener that reads handler references from the DOM.

The Qwik loader is about 1KB of JavaScript — the only JS that runs on page load:

Page loads → Qwik loader (1KB) registers global event listeners
User clicks button → Global listener intercepts the event
Qwik reads the on:click attribute → "./chunk-abc.js#handleClick[0]"
Qwik downloads chunk-abc.js (if not already cached)
Qwik calls handleClick with the serialized context
UI updates

This is a fundamental inversion. Instead of downloading all code and waiting for interactions, you wait for interactions and download only what's needed.

The Tradeoffs

Resumability isn't free. It trades hydration cost for other costs:

The first-interaction latency is the most debated tradeoff. With hydration, once hydration completes, all interactions are instant — the code is already loaded. With resumability, the first click on any component triggers a network request to download its handler. On slow connections, this creates a noticeable delay on first interaction.

Qwik mitigates this with speculative prefetching — using service workers to prefetch handler chunks during idle time, before the user interacts. But it adds complexity.

Hydration vs Resumability vs Islands: The Full Picture