React Server Components Made Me Rethink Client-Side

I built React apps for seven years with a clean mental model: server renders HTML, client hydrates it into something interactive. "Client-side" meant an empty shell that fetched data via API calls. Two buckets. Two worlds. React Server Components did not blur that line. They erased it.

The shift started with Next.js 13 and the App Router. I opened a project, saw 'use client' directives peppered through the component tree, and felt genuine confusion. Every React component I had written up to that point ran in the browser. The server existed to deliver the initial bundle and some JSON. Now I had to mark components that belonged on the client. The default pushed execution to the server. You opted in to interactivity.

A React Server Component runs on the server. It produces a serialized React tree — a format the client runtime can stream and reconcile without destroying existing state. When it ships its output to the browser, the client never receives the component's code. Zero JavaScript for that part of the tree.

What changed after building with this pattern: I stopped thinking about pages as monolithic rendering decisions. A product detail page can render the header and footer on the server with zero client cost, while keeping the add-to-cart button interactive.

The trade-off is how much added complexity your team absorbs. Server Components cannot use hooks, state, or event handlers. They cannot call browser APIs. You now maintain two component categories with different rules.

Is the trade-off worth it? For data-heavy applications where bundle size matters, the answer is yes. I watched a dashboard project drop its initial JavaScript payload by 40% after migrating data-fetching components to RSC.