ExampleTech
Example post, written to show this format.
React Server Components are a boundary
A way to keep reading-heavy pages as HTML, and to stop one click handler from dragging a whole layout into the browser.
React Server Components are easier to misuse than to explain, so this is the explanation I wanted the first time I shipped one.
A server component runs on the server, renders to a payload, and does not ship its implementation to the browser. That sentence is the whole feature. The part that changed my pages is what I can import inside that component: a markdown parser, a database client, a date library, a syntax highlighter. None of those have to become JavaScript on the client if the component never crosses the boundary.
The boundary is the thing to design. A client component is a component with state, effects, or browser APIs, marked so the bundler sends it down. Everything it imports comes with it, including other components that did not need to be clients. The mistake I made, and the one I keep seeing, is putting "use client" on a layout because a menu button needed onClick. The button is the client. The article underneath it can stay on the server and show up as HTML.
I use the boundary like a kitchen pass. Reading happens on one side. Interaction happens on the other. A tech note on this site is a server render: the file is read, the markdown is compiled, and the HTML is what the browser gets. The theme button is a client island, and it does not need the markdown compiler in its pocket. That split is the practical meaning of the feature. It is not a moral claim about JavaScript.
There is a cost, and it is worth naming. The moment a component is a client, children passed in as elements can still be server-rendered, but a child imported by the client file cannot. I have lost an hour to that distinction more than once. The repair is usually to move the import up, render the server part there, and pass it into the client as children. The rule I follow now: client components are leaves, or they are thin frames around children they do not import.
Server components are also not a data-fetching religion. If the page is a highly interactive tool, a client component and a small request are still the honest design. I do not drag a canvas, a timer, or a text editor through the server to prove a point. The React docs describe the split directly, which helps on the days the jargon drifts: Server Components.
What I want from the feature is modest. Pages that are mostly reading should arrive as mostly HTML. Libraries that exist to produce that HTML should stay on the server. And one button should not be able to smuggle the whole tree into the browser bundle.