React Server Components Without the Jargon
Server Components are simpler than they sound: some components run only on the server and send their result to the browser.
React Server Components have a reputation for being confusing, partly because the explanations are full of new vocabulary. The core idea is small. Some components render on the server, have direct access to data, and send their output to the browser. Others render in the browser and handle interaction. You choose per component.
A Server Component can read from a database, call an internal API or read the filesystem directly, without a fetch layer or an API route in between. Its code never ships to the browser, so heavy dependencies such as markdown parsers or date libraries cost nothing on the client. It cannot use state, effects or event handlers because it does not run in the browser.
A Client Component, marked with "use client", is the React you already know: hooks, event handlers, browser APIs. The boundary is the file, and everything a Client Component imports becomes client code too. That is why the advice is to push "use client" down to the smallest interactive leaf: a button, a form, a carousel.
The two kinds compose naturally. A server-rendered page can include a client-side search box and pass it already-fetched data as props, as long as the props are serializable. Functions and class instances do not cross the boundary; plain objects do.
The mental model that works: server for data and layout, client for interaction. Start every component on the server and move it to the client only when it needs to respond to the user.
