Server-Side Rendering: Then and Now

Everything old becomes new again — especially in web development.

Ah, SSR (Server Side Rendering). Suddenly, everyone is excited about it like it’s some brand-new invention. Conferences are buzzing. Frameworks are adding new features. Developers are tweeting things like “Blazing fast SSR!” — and somewhere in the corner, an old PHP developer is sipping tea, quietly saying:

We’ve been doing this since the Netscape browser wars.

A Brief (and Slightly Nostalgic) History of Rendering

In the beginning, there was… PHP, JSP, ASP…

Back in the early 2000s (or even the 1990s if you go way back), websites were simple. You asked for a page, the server built it (maybe using PHP, JSP, or ASP.NET), talked to a database, generated some HTML, and sent it to your browser.

No client-side frameworks. No hydration. No virtual DOM. Just plain HTML, CSS, and maybe some JavaScript for a dropdown.

And it worked.

The SPA Era Begins

Then JavaScript frameworks appeared. AngularJS, React, Vue — and with them came the Single Page Application (SPA). Most of the work moved to the browser:

• JavaScript fetched data from APIs (first REST, later GraphQL).
• The browser did the rendering.
• The server was mostly just serving JSON.

This gave us fast, app-like experiences, but also brought some problems:

• Blank screens before JavaScript loads
• Poor SEO unless you handled it manually
• Performance issues on slow devices

SSR Is Back (Now With More JavaScript)

Now the pendulum is swinging back.

Modern SSR is popular again — this time powered by Node.js, Bun, and frameworks like Next.js, Nuxt, SvelteKit, and more.

Even though it feels new, the idea is the same:

Render the page on the server and send full HTML to the browser.

The difference? Now we render components instead of templates, and then hydrate them on the client to make them interactive.

It’s PHP… but with React.

The Evolution of Web Rendering

Here’s a quick overview of how rendering has changed:

Why Use SSR Now?

Even though it sounds old-school, SSR helps solve real problems in modern web development:

1. Better SEO

Search engines don’t like empty <div id="app"></div>. SSR gives them real content, which helps with rankings, link previews, and sharing.

2. Faster First Loads

Users see content faster, especially on slow devices or networks, because the browser doesn’t need to run a lot of JavaScript just to show the page.

3. Performance and Accessibility

Less JavaScript and faster load times make your site easier to use, especially for people with older devices or poor internet connections.

4. Shared Code

You can reuse logic for both server and client, so you don’t need to write the same code twice.

What About SSG and ISG?

SSR isn’t your only option.

• Static Site Generation (SSG) builds pages ahead of time. It’s great for content that doesn’t change often — like blogs, documentation, or landing pages.
• Incremental Static Generation (ISG) is a hybrid approach: it builds pages when someone visits them, caches the result, and updates it later. Perfect for things like product listings or catalogs.

In other words, you have choices:

• SSR for dynamic pages
• SSG for static pages
• ISG for semi-dynamic pages
• CSR (Client-Side Rendering) for interactive parts

Final Thoughts: The Cycle Continues

Technology changes. Tools evolve. But the goal stays the same:

Show useful content to the user, as fast and reliably as possible.

We might be using JavaScript on the server now, but that doesn’t mean this is something new. It’s just the latest version of an idea that’s been working quietly since the ’90s.

And if you listen closely, you might still hear an old PHP server whisper:

“Told you so.”