What Is Resumable Rendering and How It Differs from Hydration and React Server Components

Recently, a conversation on X between Angular creator Miško Hevery and Dan sparked interest in a new technique called Resumable , which Miško demonstrated in the Qwik framework.

Resumable originates from the limitations of traditional server‑side rendering (SSR) where frameworks like React, Vue, and Angular first render on the client ( CSR ) and then perform a full hydrate step. This causes first‑paint delays, unnecessary JavaScript download, and slower metrics such as First Contentful Paint (FCP) and Time to Interactive (TTI).

The standard SSR flow consists of four steps: download HTML, download all JavaScript files, parse and execute the JavaScript, and finally bind events (hydrate). In many scenarios—e.g., an e‑commerce product page—only the HTML is needed for the initial view, making the remaining steps wasteful.

Resumable flips this model: the server generates the complete HTML and serializes interactive parts (event handlers, state) as data attributes. The client only downloads and executes JavaScript when an interaction occurs. This on‑demand approach dramatically reduces the JavaScript payload for the first paint, improving FCP and TTI.

Example of a button whose click handler is not downloaded until the user clicks:

export default component$(() => {\n  return (\n
{\n      // This code is not downloaded on first paint\n      console.log('click');\n      const div = document.querySelector('#container')! as HTMLElement;\n      div.style.background = 'yellow';\n    }}>\n      Execute\n
\n  );\n});

When the button is clicked, the framework fetches the serialized handler from the HTML attribute and executes it.

In contrast, React Server Components (RSC) also run on the server but serialize components as a custom JSX protocol streamed to the client, which is later transformed into HTML by React. RSC’s serialization is at the component level, while Resumable’s serialization is finer‑grained (individual state and event callbacks).

Key differences between Resumable and RSC:

Serialization format: Resumable stores data in HTML attributes; RSC uses a JSX‑based protocol.

Change detection: Resumable leverages fine‑grained signals to know exactly which pieces of state need rehydration; RSC relies on full component tree traversal.

Future direction: Resumable is expected to evolve on the server side, adding support for more data types, streaming serialization, and tighter control over what gets serialized.

Miško argues that React’s reluctance to adopt Resumable stems from a desire to maintain backward compatibility and avoid fragmenting its ecosystem, even though the technique could yield better performance. He also notes that many modern frameworks (Vue, Preact, Qwik, Angular, Solid.js) already employ similar signal‑based approaches.

In summary, Resumable rendering prioritizes server‑generated HTML and defers interactive JavaScript until needed, offering a performance advantage over traditional hydration and presenting a distinct architectural path from React Server Components.