Cost Structures Dressed as Architectural Truth

In 2005, Jesse James Garrett published "Ajax: A New Approach to Web Applications" and argued that the web's round-trip-to-the-server model was an artifact of its hypertext origins. Developers needed to "forget what we think we know about the limitations of the Web." Fifteen years later, the React team published an RFC for Server Components, arguing that client-side JavaScript bundles had grown unsustainable. A single component rendering Markdown could require over 240K of JS. Two hundred and forty kilobytes to turn text into formatted text. Developers, the implication went, needed to forget what they thought they knew about the necessity of the client.

Both announcements carried the quiet confidence of discovery, though both were probably describing economics.

The CGI era didn't produce manifestos about server rendering being architecturally correct, because there was nothing to argue against. Client devices were slow, connections were narrow, and JavaScript was universally considered a "toy language suitable only for creating frivolous annoyances." You couldn't find a job as a JavaScript developer. There was no market. Every CGI request spawned a new process on the server, which was expensive, but a Pentium running Netscape Navigator wasn't rendering anything complex either. Computation was cheapest on the server, so that's where rendering lived. Nobody called it a philosophy.

Then Google released the V8 engine in 2008 and client-side execution got fast enough to take seriously. The first widely adopted single-page application frameworks appeared around 2010. The argument shifted: why pay for server rendering when the user's own device could handle it? One CSR advocate's case study made the logic explicit. Client-side rendering reduces server load, cuts infrastructure costs, and as devices improve, "performance differences are guaranteed to diminish further." Cost optimization acquired the language of architectural inevitability.

What followed was accumulation. The median web page shipped about 300KB of JavaScript in 2015. By 2020, 411KB. By 2024, 613KB on desktop. Nearly half went unused during page load. Nobody decided to double the JavaScript. Each library, each dependency, each convenience was individually reasonable. But the client had absorbed so much rendering complexity that the complexity itself became a cost: slower loads, worse search rankings, sprawling dependency trees with real security exposure. Meanwhile, server compute got cheaper. Edge networks put servers milliseconds from users. The economics quietly reversed, and the rhetoric followed.

Frameworks like Astro started rendering pages to static HTML and hydrating only the interactive pieces. Teams reported bundle sizes dropping 60%.

Which raises a question I find genuinely hard to resolve. Some technology patterns oscillate: thick clients, thin clients, the perennial cycle. Others accumulate into something stable. Nobody is re-debating packet switching. TCP won. What determines which kind of pattern you're in?

The current hybrid architectures, server for data, client for interaction, islands of JavaScript in a sea of static HTML, look like accumulation. They look like the industry finally absorbing the lessons of both eras. But every swing looked like that from the inside.