React Server Components represent one of the most significant shifts in how React applications are built. They are not simply a performance optimization — they change the fundamental model of where computation happens and what gets sent to the browser.
The core idea is straightforward: some components run only on the server and never ship their code to the client. This means you can fetch data directly in a component without an API layer, import server-side libraries without increasing bundle size, and keep sensitive logic out of the browser entirely.
What Changes in Practice
The most immediate practical change is how data fetching works. In a traditional React application, components render on the client and fetch data via API calls, which means users see loading states and there is latency between the initial render and the display of actual content. With Server Components, data fetching happens on the server as part of the render, so the HTML delivered to the browser already contains the real content.
This is particularly valuable for content-heavy pages — blog posts, product listings, dashboards with real data — where the first meaningful paint matters most.
The Client Boundary
Not everything can or should be a Server Component. Anything that requires interactivity — event handlers, state, browser APIs — must be a Client Component. The architecture that works well in practice is to keep the outer shell of a page as server components, and push client components down to the leaves of the component tree, encapsulating only the interactive parts.
This takes some getting used to. The mental model is different from what most React developers have been working with. But once it clicks, the result is applications that are faster by default, with smaller bundles and better initial load performance than the equivalent client-rendered approach.
Our Approach
We use Server Components as the default for new Next.js projects. The convention of opting into client behavior with the "use client" directive, rather than opting into server behavior, keeps us honest about where interactivity is actually needed. In our experience, most of any given application is display logic — and display logic belongs on the server.