Why we still render on the server

Every few years the pendulum swings. Right now it is swinging back, and for good reason.

The problem it was meant to solve

Single-page applications were an answer to slow, full-page reloads on a network that has since got a lot
faster. If your product is a document editor or a design tool, the trade is obvious. If it is a marketing
site with a contact form, you have taken on a build pipeline, a hydration cost and a whole class of
accessibility bugs in exchange for a transition animation.

What server rendering gives you back

• A first paint that does not wait for JavaScript. The HTML is the content.
• Search engines that see what users see. No rendering budget to worry about.
• A smaller surface area. Fewer moving parts is fewer things that break at 3am.

Where the line actually is

Render on the server. Enhance on the client. If a feature genuinely needs local state — a chat window,
a calendar, a live dashboard — build that piece as an island and leave the rest alone.

This site is a working example: every page arrives as HTML, and the only JavaScript that ships is what
the feed, the chat and the call screen genuinely need.