Rendering Strategies
CSR, SSR, SSG, streaming SSR, islands and server components as points on a curve between where work happens and when the page becomes interactive.
The server sends a shell, the browser downloads a bundle, runs it, then asks for data. Everything a person can read sits behind that chain.
The server fetches the data and renders the markup per request, so content arrives early. Interactivity does not arrive with it.
Render every page once at build time and serve the files from an edge. The cheapest thing to serve, and the hardest thing to keep current.
The client attaches behaviour and state to markup that already exists. Until it finishes, the page looks finished and is not.
The client renders something different from what the server sent. The framework cannot quietly pick a winner, because it does not know which one is right.
Ship JavaScript only for the regions that are genuinely interactive. The saving is real; the cost is a component model that must declare its boundaries.
Send the page in pieces as each part becomes ready. One slow region stops holding the whole document hostage — and once the first byte is out, you cannot take it back.
Components that run only on the server and never ship. A framework-specific answer to "how much of this tree needs to be code in the browser at all".
There is no winner. There are seven questions, and a real application usually answers them differently for different routes.