RSC outside Next.js: the framework is the bundler

RSC is React infrastructure, not a framework feature

The RSC protocol and its reference implementations ship from the React repository itself, as bundler-specific bindings: react-server-dom-webpack, with siblings for other bundlers (Turbopack and Parcel have their own packages; the Vite integration has matured separately as a plugin). The server half exposes functions like renderToPipeableStream — but from react-server-dom-webpack/server, producing a Flight stream, not HTML; the client half exposes createFromFetch / createFromReadableStream, which consume that stream and hand React a renderable tree. None of this mentions Next.js. What Next.js (and every other RSC framework) adds is the machinery around the protocol — and underestimating that machinery is the Hook’s two-sprint lesson.

There is also a second React build involved: packages opt into the react-server export condition, and under that condition react resolves to a build where client-only hooks simply do not exist — useState in a server component fails at module resolution, not at runtime by politeness. Your server bundle and client bundle therefore resolve different code for the same import. This detail alone disqualifies “just run the same bundle on both sides” approaches.

The four parts a minimal RSC setup needs

Strip away every framework and the irreducible checklist is four items:

1. A Flight server. Something that takes a request, renders the server component tree under the react-server condition, and streams the payload. Tens of lines with react-server-dom-webpack/server.
2. A bundler plugin maintaining two module graphs. It must find every 'use client' directive, cut the graph there, compile the client side into chunks, and — the part everyone forgets — emit the client manifest: the table mapping module references in the payload ("./RangePicker.js") to the chunks and export names the browser should load. Get the manifest wrong and hydration dies with “Could not find the module in the React Client Manifest.”
3. A client runtime. A small bootstrap that fetches the stream, runs it through createFromFetch, and renders the resulting tree — usually inside startTransition so payload swaps do not blow away in-progress input.
4. A router that refetches payloads. Navigation must intercept link clicks, fetch the new route’s Flight payload instead of HTML, and reconcile it in. Without this you have RSC-rendered first loads and full-page reloads forever after — server components that “re-render on navigation” only if something actually navigates that way.

Items 2 and 4 are where the engineering lives. The bundler work is invasive (two graphs, cross-graph references, manifests kept in sync across dev and prod builds, HMR that understands the cut), which is why RSC support arrives per-bundler and per-framework rather than as one npm install.

Together, these four parts explain the Hook’s failure precisely: the team had item 1 (a Flight stream) but was missing items 2, 3, and 4 — the parts that are not the protocol, but the frame that makes it usable. Without the manifest, references in the payload resolve to nothing; without the router, client components never get their payload updates; without the react-server condition, hooks bleed into the wrong bundle.

Who actually implements it — an honest map

As of early 2026 the landscape, judged by completeness rather than marketing: Next.js App Router is the most complete production implementation and has been the proving ground since 2023 — RSC, server functions, streaming, and caching layered on top (its caching being the most-complained-about part, a Next design, not an RSC requirement). Waku is the minimal reference: a small Vite-based framework built around RSC by design, useful both for production-lite cases and for reading — it is the cleanest way to see the four parts with little else around them. React Router (v7, carrying the Remix lineage) has been landing RSC support as the successor direction of that ecosystem. Parcel ships RSC support with its own react-server-dom bindings, and the Vite RSC plugin effort has been maturing toward making RSC a bundler capability rather than a framework exclusive. The honest summary: one battle-tested implementation, several credible ones converging, and the protocol layer shared by all of them. What you should not expect: dropping RSC into an existing CRA or bare-webpack SPA — CRA is deprecated and its sealed config predates the directive; you would be writing the bundler plugin yourself, which is the job you were trying to avoid.

What transfers, and what the complexity buys

Everything in lessons one and two is framework-portable, because it is protocol-level: server components as the zero-bundle data layer, 'use client' as a module-graph cut, the serialization rules, the DTO discipline at the boundary, the children pattern, server functions as public endpoints. Learn it once; it is the same in Next, Waku, React Router, or anything Flight-based — only file conventions and caching semantics differ.

The tradeoff paragraph your architecture review deserves: RSC charges a real complexity tax — two execution environments to reason about, a serialization boundary that can leak or throw, framework-coupled infrastructure, harder debugging (a stack trace that starts on the server and ends in a hydration mismatch), and team retraining. A classic SPA + REST API keeps one mental model and lets a small team ship; if your app is a dashboard behind a login where the bundle is cached after first visit and SEO is irrelevant, RSC may buy you little. It pays where its structure matches the product: content- and data-heavy pages, bundle-sensitive audiences, large teams that benefit from the enforced data/UI split, and apps already paying for an SSR tier. Adopting half of it — the discipline without the infrastructure — is free, and the discipline is most of the senior-level value anyway.