895: React Server Components: Where are we at?

Episode Summary

Executive Summary: The episode explains what React Server Components (RSC) and server functions are in 2025, how they differ from client components and SSR, and where they’re actually usable today. The hosts argue RSC is powerful but still fragmented, bundler-heavy, and mostly practical only in Next.js and Waku, with broader adoption slowed by framework limitations, streaming constraints, and incomplete ecosystem support.

Main Topics: What React Server Components Are: RSC are presented as components rendered on the server or at build time, sending only their output to the browser. They can be async, suspend, and stream, allowing data fetching and rendering to happen without client-side loading logic. Server Functions and RPC-like UI Calls: The discussion explains server functions (formerly server actions) as server-side functions callable from client UI or forms, enabling RPC-style workflows and state management hooks like useActionState. Current Framework Support: The hosts review ecosystem support: Next.js is fully supportive, Waku is a promising minimalist option with full RSC support, React Router has stalled, TanStack Start is planned but not shipped, and Bun/DIY approaches remain limited or impractical. Bundling Complexity and Developer Friction: A major theme is that RSC pushes deeply into bundler internals, making framework authoring and app maintenance harder. The hosts cite multiple Vite processes, singleton issues, and general complexity as major sources of frustration. Why Some Developers Dislike RSC: Criticism centers on opinionated frameworks, missing parity across React ecosystems, streaming limitations such as cookies/redirects, and the feeling that React's promise is fragmented across tools rather than standardized everywhere. Standards vs Framework Lock-In: The conversation emphasizes that many of the useful ideas around RSC are not purely React-specific but are still implemented through framework-specific tooling. The hosts argue RSC is not strong lock-in, but JSX itself is harder to escape. Future of the Web Platform: The episode connects RSC to newer web APIs like view transitions and move-before, plus React Activity/Offscreen. The hosts suggest the platform is becoming better suited to framework-assisted rendering, though not enough to eliminate complexity.

Key Arguments: RSC are not just a Next.js feature; they exist in multiple frameworks, but real support is still limited. Server components reduce client bundle size by doing heavy work like markdown parsing or code highlighting on the server. Streaming makes RSC powerful but also creates constraints, such as being unable to set cookies after streaming starts. Framework authors face deep bundler complexity when implementing RSC, which slows adoption and makes parity hard. Waku demonstrates that a more minimal React framework can support RSC well and port much of an existing Next.js app. The lack of ecosystem parity means developers cannot rely on a single consistent React platform across frameworks. RSC are not considered strong lock-in because much of the logic can remain standard, but JSX itself is more difficult to replace. Some criticism of Next.js is really criticism of streaming limitations or general React ecosystem fragmentation rather than Next alone.

Data Points: Time since RSC discussion began: 5 years - The hosts repeatedly note that React Server Components have existed for about five years but still have not fully caught on. Build time after moving from Next.js to Waku: 2 minutes - The host says the site’s build process on Waku is around two minutes and significantly faster than before. Build speed improvement: about half - The host describes the move from Next.js to Waku as cutting build time roughly in half. React Router RSC status: not shipped yet - React Router’s RSC support has been discussed for years but is still unreleased. Waku status: pre-1.0 - The host stresses that Waku is still early and should be treated as unstable for large applications. Porting success rate: 98% - The host says roughly 98% of the Next.js codebase could be moved to Waku because it was largely standard React Server Components.

Pivotal Quotes: "React server components are nice in theory, but five years in, it's not working out." — Michael Jackson: Cited as a critique of the direction and implementation complexity of React Server Components. "Building a framework that supports React server components goes so deep into the bundler realm." — Host: Used to explain why implementing RSC is difficult for framework authors and why support remains fragmented. "I don't feel good about it, not because I don't believe in the API, but I just think five years and to have this be the result is not good." — Host: Closing judgment on the state of the ecosystem and the slow pace of adoption.

Implications: For listeners, RSC are usable now but only in a narrow set of frameworks and with tradeoffs. The industry still lacks parity, and if adoption doesn’t widen soon, enthusiasm may give way to alternative approaches.