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!

JavaScript is widely used in websites, mobile applications, desktop applications and server-side programming. 1) In website development, JavaScript operates DOM together with HTML and CSS to achieve dynamic effects and supports frameworks such as jQuery and React. 2) Through ReactNative and Ionic, JavaScript is used to develop cross-platform mobile applications. 3) The Electron framework enables JavaScript to build desktop applications. 4) Node.js allows JavaScript to run on the server side and supports high concurrent requests.

Python is more suitable for data science and automation, while JavaScript is more suitable for front-end and full-stack development. 1. Python performs well in data science and machine learning, using libraries such as NumPy and Pandas for data processing and modeling. 2. Python is concise and efficient in automation and scripting. 3. JavaScript is indispensable in front-end development and is used to build dynamic web pages and single-page applications. 4. JavaScript plays a role in back-end development through Node.js and supports full-stack development.

C and C play a vital role in the JavaScript engine, mainly used to implement interpreters and JIT compilers. 1) C is used to parse JavaScript source code and generate an abstract syntax tree. 2) C is responsible for generating and executing bytecode. 3) C implements the JIT compiler, optimizes and compiles hot-spot code at runtime, and significantly improves the execution efficiency of JavaScript.

JavaScript's application in the real world includes front-end and back-end development. 1) Display front-end applications by building a TODO list application, involving DOM operations and event processing. 2) Build RESTfulAPI through Node.js and Express to demonstrate back-end applications.

The main uses of JavaScript in web development include client interaction, form verification and asynchronous communication. 1) Dynamic content update and user interaction through DOM operations; 2) Client verification is carried out before the user submits data to improve the user experience; 3) Refreshless communication with the server is achieved through AJAX technology.

Understanding how JavaScript engine works internally is important to developers because it helps write more efficient code and understand performance bottlenecks and optimization strategies. 1) The engine's workflow includes three stages: parsing, compiling and execution; 2) During the execution process, the engine will perform dynamic optimization, such as inline cache and hidden classes; 3) Best practices include avoiding global variables, optimizing loops, using const and lets, and avoiding excessive use of closures.

Python is more suitable for beginners, with a smooth learning curve and concise syntax; JavaScript is suitable for front-end development, with a steep learning curve and flexible syntax. 1. Python syntax is intuitive and suitable for data science and back-end development. 2. JavaScript is flexible and widely used in front-end and server-side programming.

Python and JavaScript have their own advantages and disadvantages in terms of community, libraries and resources. 1) The Python community is friendly and suitable for beginners, but the front-end development resources are not as rich as JavaScript. 2) Python is powerful in data science and machine learning libraries, while JavaScript is better in front-end development libraries and frameworks. 3) Both have rich learning resources, but Python is suitable for starting with official documents, while JavaScript is better with MDNWebDocs. The choice should be based on project needs and personal interests.


Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

SecLists
SecLists is the ultimate security tester's companion. It is a collection of various types of lists that are frequently used during security assessments, all in one place. SecLists helps make security testing more efficient and productive by conveniently providing all the lists a security tester might need. List types include usernames, passwords, URLs, fuzzing payloads, sensitive data patterns, web shells, and more. The tester can simply pull this repository onto a new test machine and he will have access to every type of list he needs.

WebStorm Mac version
Useful JavaScript development tools

Atom editor mac version download
The most popular open source editor

EditPlus Chinese cracked version
Small size, syntax highlighting, does not support code prompt function

DVWA
Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is very vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, to help web developers better understand the process of securing web applications, and to help teachers/students teach/learn in a classroom environment Web application security. The goal of DVWA is to practice some of the most common web vulnerabilities through a simple and straightforward interface, with varying degrees of difficulty. Please note that this software