Server Components Changed How I Think About React

The starting point

React is often introduced as a library for building interactive interfaces, so it is natural to associate components with browser code. Server Components challenge that assumption. A component can exist primarily to assemble data and markup on the server without becoming JavaScript that the browser must download and execute. That distinction is useful because it forces a clearer question: which part of this interface actually needs a browser runtime?

Rendering location is an architectural decision

If a component only reads data, formats it, and produces markup, sending its implementation to the browser can be unnecessary. Server rendering allows database access and other server-only operations to stay on the server boundary. The result is not merely smaller client code; it is a cleaner ownership model. Secrets, database connections, and privileged operations do not need to become concerns of interactive UI code.

Client Components still matter. A form that reacts to keystrokes, a drag interaction, or a component using browser APIs has a legitimate reason to run in the browser. The useful mental model is therefore not server versus client as competing architectures, but server by default with carefully chosen client islands.

The interesting part is the boundary

The hardest decision is often not how to write a component but where its responsibility should stop. A server component can fetch the data it needs and pass serializable information into a client component. This creates an explicit boundary between data acquisition and browser interaction. Once that boundary is visible, a lot of accidental complexity disappears.