Why React Server Components Are More Than Just Hype
After two years in production, RSC has matured. Here's what actually changed about how we build apps — and where the rough edges remain.
Anna Whitfield
Two years in, the noise has died down. React Server Components are no longer the experimental thing on a conference slide — they're the thing your senior engineer reaches for first.
The shift is subtle but real: most of your app no longer needs to ship to the browser at all. Pages that used to load 600 KB of JavaScript now ship a fraction of that, with no UX regression. Forms work without a hydration round-trip. Data fetches happen one place, not three.
What you actually win
- Smaller bundles. Components that don't need interactivity simply don't ship.
- Co-located data. The fetch lives next to the JSX that uses it. No more prop-drilling state.
- Fewer abstractions. The line between "page" and "component" finally fades.
Where the rough edges remain
Streaming is glorious until you need to set a status code from deep in the tree. Cookies remain awkward. And the mental model — what runs where, and when — still trips senior engineers in their first week.
None of this is a deal-breaker. Three years from now, the conversation will be: "you mean people used to ship the entire app to the browser?"
Related articles.
ITThe Quiet Power of TypeScript: Branded Types for Safer APIs
Branded types are the cheapest, least-known TypeScript trick that catches an entire class of bugs at compile time.
ITSelf-Hosting Postgres in 2026: A Practical Checklist
Managed Postgres is wonderful — until the bill arrives. Here's what we learned moving 200 GB back to a self-hosted instance.
