Streaming SSR: the shell first, the slow part later
renderToReadableStream is real. The receive function plays the browser's part: it appends each chunk and runs React's small inline script, which moves the finished menu into the place of the fallback. No React code runs in the "browser" for that swap.
Rendering strategies differ in where and when a page's HTML is made: in the browser (CSR), on the server for each request (SSR), once at build time (SSG), at build time and then refreshed (ISR), or on the server in pieces as data arrives (streaming); hydration then makes server HTML interactive.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Use renderToString to log the HTML for <Badge label="New" />, where Badge returns <span className="badge">{label}</span>.
Choose a strategy for each page of a news site: About page, an article, the live-scores widget, the logged-in reader's saved list. Give one reason each.
Explain it without notes
Compare CSR, SSR and SSG: where and when is the HTML made, and what are the costs of each?
What is hydration and why is a server-rendered page not interactive straight away?
How does streaming SSR with Suspense improve on plain SSR?
What is ISR and what does stale-while-revalidate mean?
Preview
Console
Nothing logged yet.Expected console output
after chunk 1: Cafe | Loading menu...
after chunk 2: Cafe | Tea | Coffee