For a long time, React server rendering came with a quiet bargain. The server would give the browser HTML early, so the user would not stare at a blank page. Then, once JavaScript arrived, React would come back and take ownership of that HTML from the root down.

That sounded like an implementation detail, but it was really an architectural claim: the page is one thing. It has one root. It becomes interactive as one program.

For some pages, that is true enough. A dashboard, an editor, or a dense application shell often wants to become one connected client-side system. But the web is full of pages that are not shaped that way. A product page has a buy box, reviews, recommendations, badges, media, a map, a few accordions, maybe a carousel nobody touches. A documentation page has mostly text and a search box. A marketing page has long stretches of server-rendered content with a few points of behavior scattered through it. Hydrating all of that through the same root was convenient for the framework, not necessarily honest about the page.

This is the thread that connects React 18 selective hydration, TanStack Start deferred hydration, and @lazarv/react-server hydration islands. They are all reactions to the same old bargain. But they are not the same reaction.

Scheduling the same root

React 18 selective hydration was the first big break in the waterfall. Before it, SSR in React had an awkward sequence: gather the data, render the HTML, load the JavaScript, hydrate the tree. Each step wanted to finish for the whole app before the next one could really begin. If comments were slow, the shell waited. If the comments bundle was large, the navigation waited. If hydration was expensive, even already-visible controls could feel stuck behind unrelated work.

Suspense changed the shape of that sequence. Once the server can stream HTML through Suspense boundaries, the ready parts of the page no longer have to wait for the slow parts. Once the client can hydrate through those same boundaries, the ready JavaScript no longer has to wait for every other bundle. And once React can notice that the user clicked inside a still-dry boundary, it can move that boundary to the front of the hydration line.

That is a real shift. The comments widget can arrive late without preventing the rest of the page from becoming useful. A sidebar can hydrate after a post. A user interaction can pull a boundary forward. Hydration stops being a single uninterrupted march from the root through the entire tree.

But React did not change who owns the page. It changed how the owner schedules work.

A Suspense boundary is a scheduling unit inside one React root. It lets React stream, pause, resume, prioritize, and preserve server HTML while code is still loading. It does not mean "this part of the document is no longer React's problem." If the boundary was server-rendered as part of the app, React still expects to reconcile it eventually. If parent state or context changes in a way that makes the preserved HTML stale, React has to protect consistency. If the code arrives and the boundary matters, hydration remains part of the plan.

That is why the old React WG question about stopping hydration for part of the document is such a useful hinge. The proposed trick was to suspend a boundary forever, mostly to keep static JSX-heavy content from entering the initial client work. The answer was essentially: that is not a stable ownership boundary. Updates can still force React to inspect it, context can still matter, and you may still have downloaded the code. The real direction, React maintainers suggested, was Server Components.

That answer points at the deeper issue. The desire was not only to hydrate later. It was to stop pretending the entire document had to belong to the client root in the same way.

A gate inside the app

TanStack Start's deferred hydration lives in the space just before that deeper shift. It accepts the single-root app model, but gives the developer a way to keep certain server-rendered subtrees out of the initial hydration queue until there is a reason to admit them.

import { Hydrate } from "@tanstack/react-start";
import { visible } from "@tanstack/react-start/hydration";

export function ProductPage() {
  return (
    <Hydrate when={visible({ rootMargin: "400px" })}>
      <Reviews />
    </Hydrate>
  );
}

The important thing in this example is not that reviews become lazy. They are still in the HTML. The server still rendered them. Users can read them. Crawlers can index them. CSS can style them. What changes is that the client tree does not have to hydrate that boundary during the first pass. The boundary can wait for visibility, idle time, interaction, a media query, a condition, or it can intentionally remain static for the initial document with never().

This is more than React selective hydration. React decides the order of hydration work that exists. TanStack Start can decide whether that work should be in the initial queue at all. Its compiler can also split the boundary's children into a deferred chunk, so the browser may avoid fetching that JavaScript until the boundary is close to hydrating. That changes both CPU timing and network timing.

The subtle part is that the server HTML is not treated like a loading placeholder. It is the thing the user sees while the boundary is waiting. In TanStack Start, fallback on <Hydrate> is not the skeleton shown during initial document hydration if server HTML already exists.

<Hydrate when={visible()} fallback={<ReviewsSkeleton />}>
  <Reviews />
</Hydrate>

On the first page load, if <Reviews /> was rendered into the document, the user keeps seeing the rendered reviews. The skeleton is for a different situation: the app is already running, a boundary first appears through client-side navigation or conditional rendering, and there is no preserved server HTML for that boundary. The same prop has to serve the post-startup client world, not replace the initial server world.

That distinction gives TanStack's model its character. Deferred hydration is not "show a spinner until the component wakes up." It is "preserve the server-rendered thing until the client has a reason to own it."

Still, the root remains the root. TanStack Start is explicit about that. A deferred boundary sits inside one React tree. Parent updates can force it to hydrate earlier if correctness requires it. Nested boundaries hydrate parent-first. Context and state are still part of the surrounding app model. This is not Astro-style island composition, where separate roots are dropped into a mostly static page. It is one React application with doors that can stay closed for a while.

That is a good model when the page really is one app, but some regions are non-urgent. Reviews below the fold, recommendation carousels, media-heavy embeds, comparison tables, maps, and rarely used panels are all good candidates. They belong to the app. They should be server-rendered. They just do not need to consume startup work before the user gets anywhere near them.

A real island

The RSC version of the story starts from a more complicated default. Server Components run on the server and their component code does not become part of the client bundle, but the page can still be one React tree on the client. The static output produced by Server Components is still represented through the RSC payload and can still sit under the page root that React hydrates and reconciles. In that model, "server" does not automatically mean "outside the client React tree." It often means "rendered on the server, then represented inside the client-owned page tree."

That is already useful, because it keeps server-only code and browser code separate. But it does not, by itself, break the old root-level bargain. A static paragraph rendered by a Server Component may not ship its component implementation to the browser, but if it is part of the page root, it still belongs to the client React app's tree shape.

@lazarv/react-server pushes that further with "use hydrate" islands. A component can mark a server-rendered subtree as a hydration island:

function ReviewsIsland() {
  "use hydrate: visible; rootMargin=600px; id=reviews";

  return <Reviews />;
}

The runtime renders the island as normal server HTML, but it also writes an island-specific RSC payload and later calls React hydration for that island as its own root. That is the central point. The island is not a delayed region of a larger client tree. It is a separate React tree.

The page root does not have to be a client root just because this part of the page eventually becomes interactive. The static content above the island, below it, and around it does not participate in a React app on the client at all. It remains document HTML. There is no root-level React owner waiting to reconcile it, no page-wide hydration pass that has to account for it, and no fiction that the entire document is one client program with a few slow parts.

The page can have no client components at the root, no root RSC hydration payload, and still contain an island that wakes up later.

That is not merely deferred work. It is a true island.

With React selective hydration, a Suspense boundary inside the main root gets scheduled more intelligently. With TanStack Start deferred hydration, a subtree inside the main root waits at a gate. With an @lazarv/react-server hydration island, a new hydrate root appears inside an otherwise non-React document. Once hydrated, that island may also behave as a local outlet and use primitives such as Link local and Refresh local, but that is downstream of the more important fact: it is not owned by the page root.

This is the part that makes "use hydrate" more than a trigger syntax. The familiar strategies are there: load, idle, visible, interaction, media, and never.

function AccountMenuIsland() {
  "use hydrate: interaction; events=pointerenter,focusin; id=account_menu";

  return <AccountMenu />;
}

But the strategy is not the architecture. visible is just when the door opens. The architectural question is what is behind the door. In TanStack Start, it is a deferred part of the same app root. In @lazarv/react-server, it is a separate React hydrate root with its own payload, mounted into a document whose surrounding content is not part of the client React tree. That difference matters when you are deciding whether the page itself should become client-owned.

Fallbacks are part of the contract

It also changes how fallback should be understood. React's Suspense fallback is a rendering fallback: what should appear when content is not ready. TanStack Start's Hydrate fallback is mostly a client-mount fallback: what to show when no initial server HTML exists for a boundary that appears after the app is already running. In @lazarv/react-server hydration islands, some of the most important fallbacks are operational. If IntersectionObserver is unavailable for a visible island, hydrating immediately is safer than leaving visible UI permanently inert. If matchMedia is unavailable for a media island, eager hydration is again the better failure mode. If an interaction island wakes on the first click, you should not assume that exact click will replay into the newly hydrated component; for controls where the first click must perform the action, earlier intent events like pointerenter or focusin are better triggers.

These details are easy to treat as API trivia, but they are where the model becomes real. A user does not care that a section is governed by an elegant hydration strategy if the first click disappears. They do not care that the page saved JavaScript if a visible control never wakes up on their browser. Deferred hydration is only a performance feature when its failure modes preserve trust.

Ownership, not laziness

That is why I think the comparison has to be framed around ownership, not around laziness.

React selective hydration is not "less hydration." It is hydration with better scheduling. It keeps the single-root app model and makes it far less wasteful.

TanStack Start deferred hydration is not "Suspense but later." It is an admission gate for preserved server HTML inside one React app. It lets the app say: this part is visible now, but client ownership can wait.

@lazarv/react-server hydration islands are not just "defer this component." They are a way to keep the page root out of the client React app entirely while giving selected subtrees their own client life. That is the RSC-native answer to the discomfort behind the old forever-suspending Suspense idea.

Once you see the difference, the design question changes. It is no longer "how do we hydrate the page faster?" Sometimes the right answer is to hydrate sooner. Sometimes it is to hydrate later. Sometimes it is to stop making the page root responsible for hydration in the first place.

The better question is: which part of this page needs client ownership, and when?

If the page is an application shell, React's selective hydration is the base layer. Use Suspense boundaries, stream what is ready, code split what is heavy, and let React prioritize the interaction path.

If the page is one app with non-urgent regions, TanStack Start's deferred hydration is the sharper tool. Keep the HTML. Delay the JavaScript. Let visibility, idle time, media, condition, or intent decide when the boundary becomes interactive.

If the page is mostly server-owned with a few islands of behavior, an RSC island architecture is the cleaner shape. Do not hydrate the root just to support a filter, a menu, or a counter. Give that subtree its own hydrate root and let the surrounding document remain outside React on the client.

Hydration used to be described as the tax paid after SSR. That was always too blunt. Hydration is not one tax. It is a set of ownership decisions that happen over time. React 18 made those decisions schedulable. TanStack Start made them deferrable inside the root. @lazarv/react-server makes them separable enough that the root can sometimes stop being a client React root at all.

The page root was a useful default. It should not be the only unit we are allowed to think with.