Web Development

React Server Components two years in: what changed our minds

We were skeptical in 2024. After two years of shipping RSC in production on real client sites, here is what works, what does not, and the mental model that actually clicks.

Updated 2 min read

React Server Components shipped in Next.js 13 in late 2022 and the discourse has not stopped. After two years of shipping RSC-first apps for real clients, our team’s position has shifted from “wait and see” to “default unless proven otherwise”.

The mental model that clicks#

Stop thinking “server vs client component”. Start thinking “data-fetching boundary”. The server component fetches and renders to HTML; the client component handles interactivity. The boundary is the seam where you hand props down.

What works in production#

  • Content sites. RSC + ISR is the fastest practical setup for headless CMS work. No hydration cost on the body, no flash of loading state, full Core Web Vitals.
  • Dashboard reads. Server-render the data, client-render the interactivity. Cuts JS bundle 40–60% on most dashboards we ship.
  • Forms with server actions. Server actions in Next.js 15.x finally killed the “create an API route just to submit a form” pattern. Cleaner, less code.

Where it still hurts#

State that crosses many components (user preferences, theme, cart). The “use client” boundary creep is real, and Context still does not work in RSCs. We end up with a thin client-only provider layer wrapping otherwise-server pages.

The recommendation#

For any new marketing site, dashboard or content-heavy app: start RSC-first. Add “use client” only where you need it. For existing SPAs with heavy state libraries, the migration cost is real, do not chase it for its own sake.

We ship Next.js 15 + RSC by default on every web development engagement.

More from Web Development