Rendering strategies & meta-frameworks

Overview

"Where does the HTML come from, and when?" is the first architecture decision of any web product, and every acronym in this space — CSR, SSR, SSG, ISR, islands, RSC — is one answer with one cost profile. The pendulum swung from server-rendered pages to client-side apps and is swinging back with the server in a new role; meta-frameworks (Next.js, Remix/React Router, Astro, SvelteKit, Nuxt) exist to package these strategies with routing, data loading, and deployment. Choosing well means knowing what each strategy costs in latency, complexity, and infrastructure — not which one is fashionable.

Key points

• The strategy spectrum: CSR (empty shell + JS builds everything — cheap to host, slow first paint, SEO friction), SSR (HTML per request — fast first paint, needs a server, TTFB on the critical path), SSG (HTML at build time — fastest and cheapest, only for content known ahead), ISR/on-demand revalidation (SSG that heals itself), streaming SSR (send the shell, flush the slow parts later).
• Hydration is the tax collector: server HTML is inert until the JS re-attaches; users see a page they can't use yet (web performance's INP and the uncanny valley). Everything after classic SSR — islands, progressive/selective hydration, resumability (Qwik), React Server Components — is an attempt to shrink or dodge this tax.
• Islands & partial hydration (Astro): static HTML by default, hydration only for the interactive widgets — the right default for content-heavy sites with sprinkles of interactivity.
• React Server Components: components that run only on the server — zero client bundle, direct data access — composed with client components at explicit "use client" boundaries; data flows down as serialized UI, mutations return via server actions. A real shift in where the data layer lives, with real complexity added to the mental model.
• Pick by page, not by app: marketing pages want SSG, dashboards behind login are fine as CSR, feeds want SSR/streaming. Meta-frameworks let strategies mix per route — the skill is matching strategy to content volatility and interactivity.
• The deployment story is part of the choice: SSR means servers or edge runtimes, SSG means a CDN; edge rendering moves TTFB close to users but constrains the runtime. Vendor coupling (notably Next.js ↔ Vercel) is an architectural dependency to weigh like any other.

Details

Choosing, honestly

The meta-framework landscape

Next.js (App Router: RSC-first, the most capability and the most conceptual surface), Remix / React Router (web-fundamentals posture — loaders/actions over forms, progressive enhancement), Astro (content-first, islands, framework-agnostic), SvelteKit/Nuxt (the same ideas for their ecosystems). They converge on the same primitives: file/route-based data loading, nested layouts, server mutations, per-route rendering choice.

Practice

• Same page, three ways — build one product page as CSR, SSG, and streamed SSR (any meta-framework); measure TTFB/LCP/INP on a throttled connection and write down the table you observe rather than the one the docs promise.
• Islands retrofit (source) — rebuild a JS-heavy content page in Astro with only the carousel hydrated; watch the bundle drop by an order of magnitude.
• RSC boundary kata (source) — take a small Next.js App Router app and justify every "use client" directive out loud; the exercise is drawing the server/client line deliberately.
• RealWorld full-stack build (source) — milestone 4 migrates the CSR app to a meta-framework and measures what it bought.

Related

• Browser internals — what the browser does with the HTML each strategy produces.
• Web performance — the metrics these strategies are traded against.
• Component architecture & state management — server rendering relocates state; the classification still decides where it goes.
• Cache management — ISR and CDN revalidation are cache invalidation wearing a frontend badge.
• API design — loaders, server actions, and BFFs are the API seam of the meta-framework world.