The Evolution of Web Rendering: From jQuery to SSR, SSG, and ISR

One question has quietly driven twenty years of web architecture: where does the HTML get built? On the server before it is sent, or in the browser after it arrives? The answer has swung back and forth, and each swing fixed the real pain of the era before it while introducing new pain of its own. Understanding that arc explains why today's frameworks work the way they do, and why they can feel like they are reinventing ideas from 2004.

The original web: the server did everything

In the beginning, the server built the whole page. You requested a URL, a program on the server assembled a complete HTML document, often filling a template with data from a database, and sent the finished page to your browser. Think of the classic PHP, Ruby on Rails, or Django application.^[1] Every click was a full page load. The server did the work, and the browser displayed the result.

This had real strengths that the industry would later rediscover and miss. The first load was fast, because the browser received ready-to-show HTML. Search engines could read the content directly. The model was simple to reason about. Its weakness was that every interaction, even a small one, meant a full round trip and a full page redraw, which felt heavy and made rich interactivity awkward.

jQuery and progressive enhancement

As browsers gained the ability to fetch data in the background, developers started sprinkling JavaScript onto those server-rendered pages to make them feel more alive. jQuery, released in 2006, was the tool that made this practical.^[2] It smoothed over the maddening differences between browsers and gave everyone a simple way to find elements, change the page, and make background requests.

The philosophy of the time was progressive enhancement.^[3] The page worked as plain server-rendered HTML, and JavaScript layered extra polish on top: validate a form before submitting, update a section without a full reload, show and hide content. The server still owned the page. JavaScript was a helper, not the foundation.

The single-page app era

Then the center of gravity moved. As web applications grew more ambitious, trying to feel like desktop software, developers wanted to stop reloading the whole page for every action. The single-page application was the answer.^[4] The server sends a mostly empty HTML shell and a large bundle of JavaScript. That JavaScript then takes over, fetching data as needed and building the entire interface in the browser. This is client-side rendering, and frameworks like Angular, and later React and Vue, made it the default way to build serious web apps for most of the 2010s.

The appeal was obvious. Once the app loaded, navigation felt instant, because moving between views was just the JavaScript swapping out parts of the page instead of fetching a new document. The experience could rival a native application, and building complex, stateful interfaces became far more manageable.

The bill for client-side rendering

The single-page approach came with costs that took a few years to fully show up. The first load got slow. The browser now had to download a large JavaScript bundle, run it, and only then fetch the data and build the page. Until all of that finished, the user often stared at a blank screen or a spinner. On a fast laptop this was tolerable. On an average phone over an average connection, it could be genuinely bad.

Search was the other problem. Because the real content was assembled by JavaScript after the page loaded, anything that read the raw HTML saw an empty shell. Search engines and link previews struggled, which mattered a great deal for any site that depended on being found. The industry had traded away two of the old server-rendered model's best properties, fast first paint and readable content, to get smooth interactivity.

Back to the server, with the interactivity kept

The current era is about getting both. Rather than choosing between server rendering and a rich client, modern frameworks do server work first and then hand off to the browser. A few terms describe the variations.

Server-side rendering, SSR, builds the HTML on the server for each request, like the old model, but then the JavaScript takes over in the browser so navigation stays fast. The step where the client-side code attaches itself to the already-rendered HTML is called hydration.^[5] Static site generation, SSG, goes further and builds the pages ahead of time, at deploy, so they can be served instantly from a cache or CDN. This is ideal for content that does not change on every request, like documentation or a blog.

Incremental static regeneration, ISR, is the clever middle ground. Pages are served from a pre-built static cache for speed, but they quietly rebuild in the background on a schedule or when the underlying data changes. You get the speed of static files with content that stays reasonably fresh, without rebuilding the entire site for one update. Frameworks like Next.js made these patterns mainstream, letting a single application mix them page by page depending on what each page needs.

React Server Components

The most recent step pushes the idea deeper into the components themselves. React Server Components let individual pieces of an interface run on the server, where they can read from a database directly and send only their finished output to the browser, while other components remain interactive on the client. The aim is to ship less JavaScript by default, keeping heavy data work on the server and reserving the browser for the parts that genuinely need to be interactive. It is still maturing, and it is clearly the direction the ecosystem is moving.

Why the pendulum swung back

Step back and the shape is clear. We started on the server because it was the only option. We moved to the browser to get interactivity that the server model made awkward. We are returning to the server because doing everything in the browser made first loads slow and content hard to find, and we have learned how to keep the interactivity while fixing those two things.

The lesson is not that one approach beats the others. It is that the honest answer is usually a mix. Render on the server for speed and for search, build ahead of time what you can, and send interactive JavaScript only where the experience actually calls for it. The tools finally let you make that choice page by page, and even component by component, which is what the earlier eras were missing.