The term Server-Side Rendering (SSR) is often misunderstood, with many using it to describe practices that predate its creation or don’t technically qualify. From PHP templates to React’s isomorphic apps, the definition of SSR has evolved—and so has the confusion around it.

This article dives into the origins of SSR, what it truly means, and why understanding the distinction matters in modern web development.

So Here’s the Deal

We didn’t have SSR back in the PHP days. That term didn’t exist. It was created in the 2010s. No one called this stuff SSR before that.

What did they call it? If you believe Wikipedia, it was called server-side scripting (as opposed to client-side scripting).

Fun fact: if you check Wikipedia, they didn’t even add “SSR” to the server-side scripting article until 2021. Here’s the diff. And honestly? I think this is wrong.

Before SSR, There Was...

Until React introduced the term “rendering,” we didn’t use that word. The closest thing we had was server-side templates. Here’s an old snapshot.

The idea was simple: you’d use a static site generator or server scripting to build your dynamic web page.

Some people argue: “Well, if I use server templates, I’m rendering them on the server.”

The Problem With That

Rendering in React doesn’t always mean producing HTML or DOM. It produces VDOM (virtual DOM). The lines blur when you call renderToString because then the component is actually rendered to HTML.

This is why people started claiming their PHP apps were doing SSR. But here’s the issue: this loses the distinction between actual SSR and regular dynamic scripting.

The Main Difference

You can only do SSR on parts that could also be rendered on the client.

For example:

const App = () => <div onClick={handleClick}>Hello</div>;

You can run this app twice: once on the server and once on the client.

But:

<div><?php echo "Hello"; ?></div>

This can’t run on the client. There’s no rendering here—no “client-side” or “server-side” distinction. This is just old-fashioned dynamic scripting.

SR vs. SSR

Since no one uses those old terms anymore (except maybe in ASP), I think I’m giving up and just calling it Server Rendering (SR) vs. Server-Side Rendering (SSR).

One huge difference is hydration.

In the PHP world, there’s no hydration, but they’re still sure they have SSR. That doesn’t make sense. You can only have SSR if you have hydration.

Hydration: The Key

React has two key methods:

• renderToStaticMarkup: Produces HTML you’re not expected to hydrate. This is closer to server templating.
• renderToString: Produces HTML that gets hydrated on the client. This is SSR.

Angular Universal didn’t have SSR until 2023. What they had was SR: producing HTML on the server, then dropping it once scripts loaded and rendering the app as an SPA into an empty tag.

That’s not the same as PHP, but it’s also not the same as real SSR.

The Early Days

Early on, React apps were “pre-rendered” using headless Chrome to save them as HTML strings. That snapshot went into a CDN. Technically, a server wasn’t even necessary to make this work. ?

It was a pointless endeavor, but Google recommended it for SEO at one point. I tracked down that article once, but I’m not sure if I can find it again.

Why Care About This?

React Server Components (RSC) forced us to revisit this topic.

Technically, RSC doesn’t do SSR. This surprised a lot of people.

The React team tried explaining it but gave up. The gist is that server components are just templates—they produce static HTML. Client components go through SSR to produce both HTML and DOM.

Inertia.js and SSR

Inertia.js makes a similar distinction. PHP runs on the server, but your JavaScript app gets SSR’d by running on the server to produce HTML and then hydrating on the client.

So, Can PHP Do SSR?

No. Like RSC, PHP is doing dynamic scripting (SR) with a step that does SSR.

If you run a React app with a middleware like Hono, injecting some dynamic code into HTML and later calling renderToString, it feels similar. In both cases, it’s SR with a step of SSR.

That’s why it’s bonkers when people claim, “We did SSR in PHP in the ’90s.”

What About SSG?

Every time I bring this up, someone asks about SSG. I don’t care.

The term Static Site Generation (SSG) actually predated React. SSG means producing HTML—no rendering or hydration required. Did you produce HTML? Congrats, you’re doing SSG.

The React Innovation

React frameworks introduced isomorphic apps, using hydration to adopt HTML on the client without re-creating it.

That HTML had to be produced by SSR.

Qwik and “Resumability”

Does Qwik do hydration? That’s the big question.

Qwik developers say no, but I’m leaning towards yes. If you like Qwik, you’d need to chop off another piece of SSR and call it Resumability.

If you prefer listening to discussions over reading, you can hear more of these arguments in audio form from this podcast episode about React Server Components in Go

The above is the detailed content of What Most People Get Wrong About the Term SSR. For more information, please follow other related articles on the PHP Chinese website!