React architecture
React Server Components, Explained Without the Hype
The useful question is not “server or client?” It is “where does this work actually need to happen?”
6 min read
Sartaj Alam
Traditional React applications can send JavaScript for UI that never becomes interactive. Server Components let that display work stay on the server while React still composes the page as one tree.
What they actually solve
When a component only reads data and returns markup, the browser should not have to download and hydrate all of its implementation. A Server Component runs away from the browser, can access server-side resources, and sends a rendered result through React's server format.
This can reduce client JavaScript and keep database or API access close to the place that assembles the screen. It is an architectural tool first and a performance optimization second.
Think in boundaries, not page types
Server side
Prepare and compose
- Fetch and shape data
- Read files or databases
- Render article and catalogue UI
- Keep secrets off the client
Client side
Interact and respond
- Handle clicks and typing
- Use state and effects
- Access browser APIs
- Deliver instant feedback
A route can be mostly server-rendered and still contain small interactive islands. Pass serializable data into focused Client Components at the leaves instead of turning the whole page into client code.
The rule that keeps code clear
Use Server Components for data and display. Introduce a Client Component where interaction begins.
This is a starting point, not a law. Context providers, third-party libraries, and real-time behavior sometimes move the boundary. The goal is to make each exception deliberate.
Final thought
Server Components do not replace client-side React.
They stop us from treating the browser as the only place React can do useful work. When the boundary follows the product's actual needs, the result is usually smaller, safer, and easier to reason about.