untitled RSCs overview

React server components have sorta existed for a bit, but people are only now (2025/04) really finally having a discussion about them.

... And by "people are having a discussion about RSCs" I mean "people are generally hating on some combination of RSCs and Next.js".

I've been using RSCs in prod since July 2023 — for context, that's only a couple months after Next.js v13.4 shipped their App Router as stable, inclusive of RSCs, in May 2023.

So let's try to tackle:

• What even are RSCs?
• Why use RSCs?
• How's Next.js involved?
• Who's upset and why?

What are RSCs?

React server components are basically just server-exclusive react components which return in a special, serialized jsx format to the client.

The RSC payload is a custom protocol that React made (neither JSON nor HTML). It's a serialized tree that is interpreted by the client.

Only the serialized result of RSCs makes it to the client (i.e., no client-side JS).

Why use RSCs? Like, what's the value?

There's really only a couple exclusive "features" of RSCs compared to traditional React client components:

1. RSCs can access server-only stuff
   • Since RSCs run exclusively on the server, you can use server-only stuff like the filesystem, secrets, etc.
   • 🦶🔫 — Careful with what you return.
2. RSCs can be async
   • You can use await in an async RSC.
   • Need data? No useEffect or tanstack-query necessary (well, mostly; see #parallel systems). Heck, you can even call Prisma, Drizzle, or whatever directly.
   • 🦶🔫 — You'll wanna get familiar with <suspense> so you can stream the response to the client when it's ready instead of holding up rendering.

... but what RSCs encourage and unlock is a lot more significant than just server access and async components.

RSCs provide more compositional guidance

I can hear a bunch of you thinking:

"more compositional guidance" sounds like a fancy way to say "less flexibility"

... And you're not wholly wrong, but you're not right either.

Think about it: a good portion of JSX you write doesn't necessitate any JavaScript on the client — you just couldn't really establish a boundary for which JSX necessitated client JS and which didn't.

Because of this ⤴️, the client has been overloaded with responsibilities in a SPA world and it had the implication of "allowing" (encouraging?) us to centralize more and more responsibility in the client.

More responsibility in the client also means more flexibility in the client. But that flexibility can lead to more compositional chaos — because you can sort of do anything, anywhere. Components that shouldn't necessarily be responsible for something can be simply because nothing's really stopping them. (This honestly a hard problem to describe without examples or actually working with RSCs guidelines — stick with me)

RSCs provide a fluid way to establish boundaries between what should just be rendered and what needs to be interactive / reactive in the client.

Client boundaries will put more guidelines on your compositional approach — which may feel limiting at first, but it ultimately "forces" some better patterns like:

• More URL state utilization (common state between server and client)
• Less props drilling (because you can't pass props from client → RSC)
• More web platform usage (forms, view transition API, etc)

Beyond encouraging better patterns, the boundaries and RSCs unlock some stuff:

• zero client JS by default
• streaming components
• fetch while rendering (non-blocking async components)
• component cachability (and incremental regeneration)
• more capable third-party components (eg drop-in server functionality)

I think that's a solid summary of the "what" and "why" — let's look at some actual RSCs to give concrete examples before tackling the "weird" and "bad".

RSC examples

• rsc in cc prop "slot"
  • rsc as child (children "slot")
• rsc data fetching
• suspended async component
• suspending multiple components
  • together
  • individually
  • modes? are they still experimental?
• suspense fallback
• Rsc to cc serialization boundary
• use params/qs for state
• Anti patterns
  • CC data → RSC props

"Weird" parts of RSCs

Note: some of these points may not necessarily be the result of RSCs, but they're related enough and a bit weird.

• there are many client boundaries; your app is like an onion of server and client boundaries
• you can't import RSCs in client components, but you can pass RSCs into client components via props (like children) since they're serialized at that point
• in React, promises are serializable and can be passed from RSCs to client components. I think this is just a React thing, but I never knew/thought about it before RSCs
• string directives continue to be weird
  • string directives in this realm aren't intuitive either: "use client" denotes a client component, but "use server" denotes a server action function (not an RSC)
• "indeterminate" components which are neither/both RSC or client components depending on their usage
  • I'm honestly not sure how to refer to them so I'm just calling them "indeterminate" components
  • these components can be imported and rendered by either RSCs (making them an RSC) or client components (making them client components)

"Bad" parts of RSCs

• in the wrong hands, RSCs are a fancier / easier way to write worse experiences (eg bad loading states) and unsafe code
  • Theo phrased it well: "A lot of bad devs use React and Next. This is the cost of being the default option. Previously, those bad devs would have to use an API from (likely better) backend devs. Now they can just call db from their components."
• inherently more complicated DX and mental overhead
• how do they even really work?
  • when do they render?
  • how do they re-render?
  • how do PWAs fit in?
  • are server actions functions part of RSCs?
• increased tooling complexity
  • SPAs are pretty simple — you can just include a script on the page and ship a single HTML page
  • "rube goldberg" vibes
  • "The issue is the tradeoffs involved in making it work. It leaks into, or even demands control over layers that are previously not in scope for client-side frameworks. This creates heavy complexity (and associated mental overhead) in order to get the main benefits it promises." — via Evan You
• difficult introspection / debugging
  • RSC devtools do exist, but RSCs are still difficult to debug because of their cross-boundary nature and tooling complexity
• you'll often have parallel systems for server and client, eg:
  • data fetching, call deduplication, caching / revalidation. can be somewhat unified via different interfaces.
  • sort of: state, logging
  • dev tools (RSC + React devtools)
• slow adoption
  • can't really name many RSC-specific library components
  • few frameworks / options
    • Next.js
    • Hono
    • Remix, Tanstack Start, others at some point
  • few prominent advocates
  • limited educational resources
  • shallow talent pool → longer onboarding

What about Next.js and Vercel?

Ah, right right... I'll try to be fairly objective, but I think subjectivism is hard to avoid here too.

At a high level, I think Next.js and Vercel:

• took on a really tough task with RSCs given how "different" the compositional patterns are from traditional SPAs
• made a lot of questionable decisions along the way
• probably confused people with what is RSCs vs Next.js

Next.js is very capable software, but it requires a high degree of investment to truly reach the high UX ceiling it enables. And that's sort of a problem because most people don't need perfect UX; most people just need "good enough" UX and want fast, low-investment DX.

Given Next.js' popularity, this amounts to Next.js and Vercel being a "bad first impression" and/or "ambassador" of RSCs.

If you want more about all this, here's some bullets:

• Next.js docs aren't my favorite (or my coworkers, or acquaintances)
  • they're are pretty, but mostly showcase complexity
  • they're usually very lengthy
  • anecdotal: nothing feels like it approaches the god-tier quality of the Remix tutorials and YouTube videos that existed from the beginning
  • anecdotal: seriously, wtf is a prod digest error and how do I make use of it? I know it's mostly a react thing but like... Why not explain it if it's sort of integral to your framework?
• Unintuitive defaults
  • cache all fetch calls (they rolled this back)
  • prefetching all visible links
  • you might even argue that RSCs are an unintuitive default if only because most people don't expect to default into the React behavior that they've been using for a decade (though I don't necessarily agre, I cam see the argument)
  • (not really their fault, but as a "face" of these things) string directives aren't intuitive either: "use client" denotes a client component, but "use server" denotes a server action function (not an RSC)
  • having to use unintuitive APIs like export xxxx = "some shit" or whatever the fuck that you'll always have to find in their docs
• API churn
  • fetch caching behavior
  • unstable_cache → DynamicIO/"use cache"
  • request APIs became async: params(), searchParams(), cookies(), headers()
• use of unfinalized things in "stable" Next.js releases
  • RSCs (only finalized in React 19)
  • React 19
  • pretty much their entire caching solution, even through the most recent version (15.2)
  • arguably: the App Router (possible PEBCAK tbh, but feels like it's still got some jank)
• poor dev server performance
  • Turbopack is improving this
  • ... but it's still a real memory hog
  • ... AND frequently fails (hello, context error)
  • ack that some of this is also caused by popularly included stuff like zod, tRPC, etc
• poor dev ←→ prod behavior parity
  • I don't trust any Next.js code before I see it running in a prod-like build
  • In fairness: it tends to have way better performance and behavior in prod
• platform lock-in on Vercel
  • ack that they're working with OpenNext on this
• people perceive their social media presence as kinda "snooty" and "deceiving"
  • not gonna add citations on this one 🥸
• people perceive Vercel as "taking over" React
  • eg acquiring various members of the React team

Related reading, other options, etc

"The issue is the tradeoffs involved in making [RSCs] work. It leaks into, or even demands control over layers that are previously not in scope for client-side frameworks. This creates heavy complexity (and associated mental overhead) in order to get the main benefits it promises."
— Evan You

The fast navigations we are used to are arguably a FLAW of SPAs - the lack of data loaders meant that it was hard to block navigation. But it resulted in bloated JS payloads, loading spinner hell, and absolute chaos as your apps scale.
— Theo

React Server Components are nice in theory, but 5 years in, it just isn’t working out.

It’s been fun, React. You taught me a lot.

Have fun with your react-server-dom-esm-vite-client/server bundles. I’m done. ✌️
— MJ

People are mad that the fast nextjs demos prefetch. Even though it’s customizable.

It just seems like people want:
- everything to be fast to load
- fast to interact or navigate
- not download all the js up front
- not download all the data up front
- not have cascading waterfalls.

And they want it all automatically with no tweaking.

— Anonymous friend

LINK DUMP

• RSCs primitives via Parceljs

VIDEO DUMP
(haven't watched yet, but seemed comprehensive)

Conclusion + this author's opinion

• I generally like RSCs
• Adopting an RSC mindset took effort
• RSCs compositional model made me a better React developer (as React's entire purpose is basically just composition)
• Next.js still frustrates me a lot, and frequently
• Probably wouldn't recommend Next.js or RSCs for most projects or teams, but they're pretty great for the right projects and teams

That's the end I guess. Yell at me on Twitter: https://x.com/tyler_dot_earth