How RSC is reshaping the mental model of React apps — what to render where, and the patterns that actually work in production.
React Server Components aren't an optimization. They're a new mental model for where data lives and where work happens. Teams that approach RSC as "a faster way to render React" tend to bounce off it. Teams that approach it as a new boundary in the architecture get unreasonably productive.
The boundary is the point
The whole game is the server/client boundary. Server components own data fetching, secrets, and heavy computation. Client components own interactivity, state, and anything that touches the browser. The most expensive mistakes happen when teams try to blur this line — passing functions across the boundary, lifting all state to a client root, or wrapping everything in 'use client' to avoid thinking.
Composition patterns that scale
The pattern that holds up best in production: server components by default, client components as small islands, and composition via children rather than props. A client component that takes children can wrap server-rendered content without forcing the children into the client bundle. This single trick unlocks most of RSC's real benefits.
- Default to server components — opt into client only when you need interactivity
- Pass server-rendered children into client components instead of importing them
- Keep client components leaf-shaped, not tree-shaped
- Co-locate data fetching with the component that uses it
“RSC rewards teams who treat the server/client boundary as a product decision, not an implementation detail.”
When RSC is the wrong tool
Highly interactive single-page apps — design tools, dashboards with deeply linked state, real-time collaborative editors — gain little from RSC and pay real complexity costs. If your app is 90% interactive and 10% content, stick with a traditional client-rendered architecture. RSC's sweet spot is the inverse: content-heavy apps with interactive islands.
Lean into the boundary, resist the urge to smear state across it, and the architecture mostly takes care of itself. Fight it, and every feature becomes a debate about which side of the line a component belongs on.
Want to discuss this in your context?
Book a quick call with the team that wrote this.
