For roughly a decade the default answer was to send an empty page and let the browser assemble it. That decision made sense in a particular context: rich, app-like products used repeatedly by people on good hardware. It was then applied to everything, including sites that are essentially text.
What the browser actually pays for
Every kilobyte of JavaScript is paid for three times. Once to download it, once to parse and compile it, and once to execute it. The first cost has improved with better networks. The second and third are bound to the device, and the median device is far slower than the one on your desk.
Server rendering does not eliminate that work. It moves the first meaningful paint ahead of it, which for content is most of the battle.
Where the line falls
The useful question is not "server or client" but "what does this screen owe the reader in the first second".
- An article owes them text. Render it on the server, hydrate almost nothing.
- A dashboard owes them their data. Render the shell on the server, stream the rest.
- An editor owes them a canvas. Do that work in the browser and stop apologising for it.
Most products contain all three, which is why the arguments last so long. They are usually arguments about different screens.
Choose the rendering strategy per route, not per company.
The part that gets forgotten
Server rendering only helps if what you send back is small and cacheable. Rendering on a server and then shipping the entire application bundle anyway gets you the worst of both: a slower response and the same execution cost. Measure what actually arrives at the browser before declaring the migration a success.
