PHP has as much client-side rendering as React SSR does.
I think the sleight of hand that is happening right now, and that gets people a little confused, is that React is shaping up to be this thing that handles both front and the backend where other solutions can't do that. Sure – but it does that by overloading and complicating what React once was (neither of which per-se negative, I think it's just an apt description of what is going on)
Where other solutions might have abstracted the frontend part into a thing with a different name (or not bother doing it at all) React chooses in a rather unprecedented move to call it all just... React (well, there's Remix and such, but alas). Which is fine, as long as you understand that this new "React" will now probably lead to "React Frontend Dev" and "React Backend Dev", because the work and the complexities that these rolls entail did not just disappear by rolling it into the same name.
It's not entirely clear if architecturally there are going to be more benefits than footguns, but I think it's cool that they are trying.
React borrowed these concepts from Solid, SvelteKit, and Remix.
Not that there’s anything wrong with that. It’s pushing things forward. (And by forward, I mean, yes, also a little backward. We had server-side dominance with php, etc., then frontend-only with Vue/React… Now we finally get to serve our cake and consume it, too.)
I sometimes hear snarky comments about the proliferation of all these frameworks. But here is the tangible benefit of that “competition.” (Really more cooperation than competition)
More like React scrambled to add a feature to check a box in a comparison chart with the upstarts no matter how cumbersome or disruptive the API changes ended up relative to existing codebases.
The new frameworks were poised to eat React's lunch, they knew it, and they needed something quick to hold back the rising tide.
They may succeed, but only due to inertia, not a better/cleaner solution.
I had my own server side component system in PHP, 20 years ago.
And when the marvel of AJAX happened I enabled some of the components to be requested separately by the client code, rendered and sent to the client to replace the part of the website they occupied when they were rendered when the page was served initially.
Technically it wasn't client side rendering but it wasn't far from it.
And for actual client side rendering I experimented with compiling my HTML templates into XSLT and sending XML with data instead of HTML to the browser and letting it render it to HTML using provided XSLT. Because it was blazing fast when compared to JS at the time.
So, yeah, I guess thank you industry for coming around to what some twentysomething years old made just to build some websites for his freelancing.
I'm sure that React is engineered way better than not only what I achieved, but also what I could ever hope to achieve. I'm not against React. I'm just saying that it's an implementation of really natural (good?) old ideas. Just in JS.
> And when the marvel of AJAX happened I enabled some of the components to be requested separately by the client code, rendered and sent to the client to replace the part of the website they occupied when they were rendered when the page was served initially.
I did the exact same thing. I made a page with a table that was fully rendered server side. Any change in the display, such as pagination, sorting or filtering would trigger the same PHP code that returned a HTML fragment. The Javascript for that was easy. Just send an AJAX request to the server and replace the <tbody> element with the new content.
The PHP code itself was separated in components which made it easy to share the rendering logic for the initial page and the page used for the AJAX request.
React solves this in a more convenient way, but I am really surprised that we had to wait until 2023 before it happened.
