There was a stretch where building a web app meant, almost by default, shipping a JavaScript bundle that fetched data client-side and rendered everything in the browser. It solved real problems — rich interactivity, app-like navigation — at a real cost that took years to become fully visible: bundle size, slow first paint on weak connections, and a whole category of bugs that only exist because state now lives in two places, server and client, and someone has to keep them in sync.
What changed
Frameworks didn't invent a new idea so much as bring back an old one with better tooling. Server Components, streaming HTML, and partial hydration all share the same instinct: render what can be rendered on the server, ship JavaScript only for the parts that genuinely need to run in the browser, and stop treating "client-rendered by default" as the safe choice.
The practical effect is that a lot of UI — a product page, a settings panel, an article — never needed to be a client-side application in the first place. It needed to display data and respond to a small number of interactions. Rendering it on the server and sending HTML is frequently both simpler to reason about and faster to load than the client-rendered equivalent, without giving up the option to hydrate the genuinely interactive parts.
This isn't a return to 2010
It's tempting to call this "back to PHP" and leave it there, but the comparison undersells what's different. Modern server rendering keeps the parts that were genuinely worth keeping from the SPA era — component-based UI, type-safe data fetching, fine-grained interactivity where it's needed — while dropping the assumption that everything has to ship to the client to be considered "modern." The architecture got more options, not fewer.
The actual lesson
The interesting part isn't which framework wins. It's that "render everything on the client" turned out to be a default that got adopted more widely than its actual benefits justified, for a long stretch of the industry. The current swing back toward the server isn't nostalgia — it's the result of enough teams hitting the actual costs of that default and deciding, case by case, that not every screen needs to be a single-page application to feel fast.
