React Server Components: when not to use them
Server Components are a good default, but not for everything. Where I still choose plain client components in 2026, and why.
Server Components are the right default for most pages I build. Data fetching co-located with markup, zero bundle cost, no loading-spinner waterfalls. But after two years of shipping them in client projects, I keep a short list of situations where I deliberately opt out.
Highly interactive islands
If a component holds state that changes on every keystroke or drag (editors, filter panels, anything canvas-based), making the tree around it server-rendered buys you little and costs you flexibility. I draw the boundary one level higher than the docs suggest and keep the whole island client-side.
When the data layer is the product
For the analytics dashboard I wrote about in my Metrix case, the client cache is the feature: optimistic updates, cross-view normalization, offline tolerance. RSC’s request/response model fights that. A classic SPA shell with a smart cache was simpler and faster.
Teams that aren’t ready
This one is unpopular. RSC moves complexity from runtime to architecture: you need discipline about boundaries, serialization, and "use client" creep. If a team is still learning React itself, I’ll happily ship a Vite SPA. A boring stack that ships beats a modern one that’s stuck.
The heuristic
Server Components for content, client components for tools.
If the page is something users read, RSC. If it’s something users operate, client. Most apps are both. The skill is drawing that line yourself instead of letting the framework draw it for you.