React Server Components vs. Client Components

As React developers, we’re familiar with a standard data-fetching pattern: mount a component, show a loading spinner, use a useEffect hook to fetch data from an API, and finally, update the state to render the UI. This client-side rendering approach works, but it ships a lot of JavaScript to the browser and makes the user wait for data to load after the page is already visible.

Next.js with the App Router encourages us to rethink this. It asks, “What if we did the heavy lifting on the server before sending any UI to the browser?” This simple question is the key to a paradigm shift that leads to massive performance gains and a more streamlined developer experience. By default, components in the App Router are React Server Components (RSCs), which do exactly that.

Meet React Server Components

In the Next.js app directory, every component we create is a React Server Component by default. They have a few defining characteristics that make them so powerful:

• Zero client-side JavaScript: They run entirely on the server, period. Code inside a Server Component is never sent to the browser, which dramatically reduces the JavaScript bundle size. That’s a big win for performance.

• Direct backend access: Because they execute in a server environment, RSCs can handle tasks we’d normally delegate to the backend, like accessing databases, the filesystem, or secret API keys without any risk of exposing them to the client.

• Built-in async support: Server Components can be defined as async functions, allowing us to use await directly for data fetching. This simplifies data logic and removes the need for client-side hooks like useEffect.

• No interactivity: Because RSCs render on the server, they can’t use state (useState), effects (useEffect), or handle browser events like ...