When would you choose CSR, SSR, SSG, streaming SSR or React Server Components for different parts of an app? Use a concrete product as an example.

Choose per route, based on what each part needs. First, the terms:

• CSR (client-side rendering): the browser builds the page with JavaScript.
• SSR (server-side rendering): the server builds the HTML on each request.
• SSG (static site generation): the HTML is built ahead of time, at deploy.
• Streaming SSR: the server sends HTML in pieces, as each part becomes ready.
• React Server Components: components that run only on the server and send no JavaScript to the browser.

Take a SaaS (software as a service) product with three parts: a marketing site, a public docs area, and a logged-in app.

Marketing site and docs: they change at deploy time and need SEO and a fast first paint. So use SSG, served from a CDN (content delivery network). Add revalidation for content edited in a CMS (content management system).

Logged-in dashboard: it is personalised, not indexed by search engines, and highly interactive. SSR of the shell plus streaming works well. The layout and fast data show immediately. Slow widgets stream in behind Suspense boundaries. So the whole page does not wait for the slowest query.

Server Components keep data fetching and heavy formatting libraries on the server, so they never ship to the browser. Only interactive islands, like filters and charts, are client components.

Highly interactive editor (a canvas, drag and drop): it can be mostly client-rendered after an SSR shell, because nearly everything depends on client state.

The trade-offs:

• SSR adds server cost and risks a slow TTFB (Time to First Byte: how long until the first byte of the response arrives).
• CSR delays content and hurts SEO.
• SSG goes stale.

Mixing strategies per route is normal.