Client-Side vs Server-Side Rendering: A Practical Explainer, Not a Buzzword List
The general concept, for any tech stack — not the Next.js-specific mechanics covered elsewhere here, but the actual tradeoff every rendering strategy answers.
This blog already has a Next.js-specific breakdown of SSR/SSG/ISR/CSR (linked below). This post is the more general version underneath it — the same core tradeoff, true for any stack, any language, any era of the web, not specific to any one framework's implementation.
The actual question both approaches are answering
Given a request for a page, where does the HTML that request receives get generated: on the server, before the response is sent — or in the browser, after the response (which contains little more than a JavaScript bundle reference) arrives?
Server-side rendering, the general idea
The server (whatever language it's written in — Node, Python, PHP, Ruby, it doesn't matter for this concept) builds the actual HTML for that specific request and sends it complete. The browser has real, visible content the moment the response arrives, before any JavaScript has even downloaded. This is, historically, simply how the web worked before client-side frameworks existed — PHP and Rails apps have always done this; SSR in the React world is a return to that model, not an invention of it.
Client-side rendering, the general idea
The server sends a mostly-empty HTML shell; a JavaScript bundle downloads, executes, fetches whatever data it needs, and builds the actual visible content entirely in the browser. Nothing meaningful is visible until that whole sequence completes.
The tradeoff, stated plainly
SSR costs server compute per request (or per build, for the static variant) and generally means a simpler, more resilient first paint. CSR costs an empty-then-populated first load, but can feel snappier for subsequent in-app navigation once the JavaScript is loaded and running, because it doesn't need a full server round-trip for every screen change. Neither one is "correct" in the abstract — it's the same real decision the Next.js-specific post walks through with concrete Next.js APIs; this post is that decision with the framework-specific vocabulary stripped away, so the underlying idea is clear on its own.
The Next.js-specific breakdown of SSR, SSG, ISR, and CSR.