Resumability, Islands, and Choosing a Rendering Strategy

Full-page hydration re-executes your entire component tree in the browser to attach behavior to server-rendered markup — expensive, and wasteful for pages that are mostly static with only a few interactive parts. Two real architectural responses have emerged: islands, which change what gets hydrated, and resumability, which changes whether hydration as a replay step needs to happen at all*. Both are worth knowing conceptually, because they represent genuinely different answers to the same problem, not just implementation details of one one.

Islands: hydrate the interactive parts, not the page

Islands architecture (popularized by Astro, and used in similar forms elsewhere) starts from a simple reframing: most of a page is static content — headings, paragraphs, images, layout — and only small, specific parts are genuinely interactive. So treat the page as static HTML by default, and mark individual components as "islands" that ship their own JS and hydrate independently.

The practical win is that hydration cost scales with how much of the page is actually interactive, not with the page's total size. A long article with one embedded poll widget pays to hydrate the poll, not the article. Islands can also hydrate on different triggers — on page load, when scrolled into view, or only on first interaction — giving fine-grained control over when that JS cost is paid at all.

Resumability: skip the replay entirely

Islands still hydrate each island the traditional way: download its JS, execute its component logic in the browser, attach listeners. Resumability (the model behind Qwik) asks a more aggressive question: what if the browser never had to replay any render logic at all? The server serializes enough information into the HTML — what event listeners exist, what state they close over — that the browser can wire up a listener for, say, a button click, purely by reading that serialized information, deferring the actual JS download for that behavior until the moment it's needed (often literally the click itself).

This is a genuinely different execution model, not a faster version of the same one, and it comes with real trade-offs: it requires a framework built around this model from the ground up (you can't bolt resumability onto an arbitrary React app), the serialized state can make the initial HTML payload larger, and the ecosystem, tooling and hiring pool are all far smaller than React's. It's worth knowing this exists and what problem it targets — "close to zero JS executed before an interaction happens" — more than treating it as something every team should reach for today.

A framework for actually choosing

None of the rendering-strategy lessons in this stage exist in isolation — picking one, in an interview or in production, comes down to answering the same handful of questions per route, not per app:

1. How often does the content change, and does it differ per visitor? Rarely-changing, shared content → SSG/ISR. Frequently-changing or per-request content → SSR. Private, post-shell, per-user content → CSR (often layered on top of an SSR/SSG shell).
2. Does this route need to be indexed or load fast on a bad connection? If yes, you want real content in the first response — SSR, SSG, or ISR, not CSR.
3. How interactive is it, and how much of the page is that interactivity? Mostly static with a few interactive widgets → islands/partial hydration is worth the added complexity. Heavily, uniformly interactive (a dashboard, an editor) → full hydration or CSR is simpler and the islands model buys you little.
4. What's the team and infrastructure reality? Streaming SSR needs streaming-capable hosting; resumability needs a framework built for it; ISR needs a revalidation trigger you can trust. The "correct" answer on paper can be the wrong one for a team that can't operate it.

The honest, senior answer to "which rendering strategy should this app use" is almost always "it depends, and probably more than one, per route" — and being able to say why, for a specific page, is the actual skill being tested.

What to remember

• Islands architecture hydrates only the specific interactive components on a page, leaving static content as plain, never-hydrated HTML.
• Resumability goes further, serializing enough state that the browser can attach behavior without replaying render logic at all — a different execution model, not a faster version of hydration.
• Both trade ecosystem maturity and tooling familiarity for a genuinely lower hydration cost — know what problem each solves, not just that they exist.
• Choosing a rendering strategy is a per-route decision driven by change frequency, per-visitor variance, indexing/speed needs, and how much of the page is actually interactive — not a single choice for the whole app.