You’d either have to recreate the comment structure with the same tags and classes in JavaScript (hello, maintenance nightmare!), or you would create a hidden template element, clone that element, […]
Or do comments.innerHTML += replyFromServer; (or preferably, make the submit button just submit).
Sure, we gained some superpowers like keeping state between pages
session_start(); or (preferably, tbh) appending relevant state to link urls lets you do this too, and is generally clearer as to what is being retained. Clearing everything else on a regular basis helps ensure you don’t have spooky action at a distance where things start falling apart on one page because of an unrelated action on another.
idk, I click these articles hoping to see some rational reason why I might be wrong to prefer sticking to my old techniques, and I just don’t see it. oh well.
The author’s article would be stronger if they it did not presuppose a particular attitude towards PHP.
Consider the expressions used, such as “Were were all writing PHP to our heart’s content, … we were solving smaller problems”, “We’re not going back to PHP”, “the old PHP code we all hated”, “that crazy PHP code”.
The author appears to think that his opinion of PHP (whether it comes from experience or cargo-culting) is the general consensus, and I’m not sure that’s the case.
The article would’ve benefitted from concrete examples and compare how specific problems are solved by the server-side rendered paradigm espoused by Next.js and their kin. Even stronger then if it accounts for any increased complexity in the stack incurred by the latter. For example, I suspect that these days a PHP application would be simpler to deploy and maintain than Next.js, using PHP-FPM and Caddy.
I think if you mentally replace “PHP” with “PHP 3” everywhere it occurs in the article, it’s easier to see what the author means.
That said, I didn’t find it compelling either. And I suspect that, like some of the shitshows we used to see marshaling data from the client to the server when people started leaning too much on client side stuff with PHP (and others… I remember having some real fun with JSP and ASP.net), we’re going to see it with react on the server. That seems to be an unwillingness to retain past lessons about trusting serialized data from an untrustworthy source.
I think having react on client and server is going to exacerbate that, and we’re about to see a new round of it.
In that respect, I think React on the server may turn out to be quite a bit like PHP 3.
Hah, this comment inspired be to lookup when PHP 3 was a thing… and it turns out PHP 4 came out in May 2000! So those of us with an anti-PHP 3 bias are 24 years out of date at this point.
What got my attention when reading this was: “Looking back, I think it might’ve been an excuse to avoid writing too much JavaScript – and honestly, who could blame us?”
That’s an interesting idea because I absolutely do do things to avoid writing too much Javascript. explicitly so. And questioning that is worth something to me - am I blinded by an obsolete ideology? Was it ever REALLY a good idea, or unfairly biased even back then?
Those are great questions and despite the author’s attitude, I tried to keep an open mind… but like I hinted at in my other comment, the arguments either lack substance entirely or seem like they’re attacking strawmen rather than what I actually do/did. (I still have the code to some of my old work projects from 2005-2010 so I can check how I used to do it without the rose colored glasses!)
Of course, I have confirmation bias toward my existing beliefs too, but if this is to be actually overcome, authors need to attack it head on, not just assume everyone agrees with them already and knock down things that weren’t reality.
Author seems emotionally invested in the JS frameworks right now, so this probably makes it hard to reach an objective comparison. Which is fine (we aren’t robots) but they still present the history as if this were some settled argument and what’s new is an improvement over what came before.
I was excited by the prospect of rendering React on the server (components are a great idea for both server and client-rendered views IMO) but then found out some of them simply don’t work in a server context currently. That’s disappointing, I thought the whole point was to own the runtime/platform so you can render them wherever.
I find this article unpersuasive. The issues with PHP were largely about the language and stdlib design (e.g. this article, but also things like which mysql_ functions to use). But the “lack of ambition in our web apps” wasn’t true: Facebook was written in PHP, Slack was mostly PHP, and Lyft was a PHP monolith until ~2019. Rails apps never embraced a full SPA model and they were certainly as ambitious to make superior products as they are now.
Additionally… I really wish people, ever, would link evidence that customers want rich web apps that use everything megabytes of JavaScript provides. My belief is that Silicon Valley’s ecosystem decided this was something their products needed, and it certainly signaled sheen and “we’re serious” to investors and other people in the game, but I’ve yet to see any hard data of actual masses of customers choosing Product A over Product B because they just loved that it didn’t call the server for a refresh, or had a cute animation. In my observation, most people have a relationship to their products like most people have with JIRA: the “quality” of the product is irrelevant (many even hate them) but they’re still used because they’re invaluable for the product they provide, and I haven’t seen much edge in SPAs.
Like, even look at us (software people) and GitHub. Can we really say it was so much worse before they rewrote the frontend in React? Was there a great wash of quality after the rewrite? I’ve only heard people complain about what they lost in it, but more to the point, we were using GitHub fine in the jQuery days.
I don’t mean to rail against the author here, and I fear I’ve done the thing of not responding to the article at this point, but a set of feelings it triggered in me. In any case, maybe I’m old but:
PHP wasn’t about these issues, and in fact, it’s perfectly fine now.
React on the server just is. Not for me but if it works for others, that’s great
My feelings living through this time period don’t match as they were described. But they are, in fact, just my feelings.
having learned php recently for a personal project, i will say i agree with the title and not much more than that
react is not php
and at least for generating markup i would rather use php, honestly. my static site currently is a fairly small pile of php coördinated by a hand-written Makefile, and i’ve found the experience to be much lower-friction than anything in javascript (granted, this is NOT the typical use case)
also as a language i actually rather enjoy php. it has static typing, namespaces, easy integration with external programs, trivial but powerful templating support, and some syntactic choices that i should probably view as odd but actually like a lot
Or do
comments.innerHTML += replyFromServer;(or preferably, make the submit button just submit).session_start();or (preferably, tbh) appending relevant state to link urls lets you do this too, and is generally clearer as to what is being retained. Clearing everything else on a regular basis helps ensure you don’t have spooky action at a distance where things start falling apart on one page because of an unrelated action on another.idk, I click these articles hoping to see some rational reason why I might be wrong to prefer sticking to my old techniques, and I just don’t see it. oh well.
The author’s article would be stronger if they it did not presuppose a particular attitude towards PHP.
Consider the expressions used, such as “Were were all writing PHP to our heart’s content, … we were solving smaller problems”, “We’re not going back to PHP”, “the old PHP code we all hated”, “that crazy PHP code”.
The author appears to think that his opinion of PHP (whether it comes from experience or cargo-culting) is the general consensus, and I’m not sure that’s the case.
The article would’ve benefitted from concrete examples and compare how specific problems are solved by the server-side rendered paradigm espoused by Next.js and their kin. Even stronger then if it accounts for any increased complexity in the stack incurred by the latter. For example, I suspect that these days a PHP application would be simpler to deploy and maintain than Next.js, using PHP-FPM and Caddy.
Edit: typo
I think if you mentally replace “PHP” with “PHP 3” everywhere it occurs in the article, it’s easier to see what the author means.
That said, I didn’t find it compelling either. And I suspect that, like some of the shitshows we used to see marshaling data from the client to the server when people started leaning too much on client side stuff with PHP (and others… I remember having some real fun with JSP and ASP.net), we’re going to see it with react on the server. That seems to be an unwillingness to retain past lessons about trusting serialized data from an untrustworthy source.
I think having react on client and server is going to exacerbate that, and we’re about to see a new round of it.
In that respect, I think React on the server may turn out to be quite a bit like PHP 3.
Hah, this comment inspired be to lookup when PHP 3 was a thing… and it turns out PHP 4 came out in May 2000! So those of us with an anti-PHP 3 bias are 24 years out of date at this point.
Ah, JSONP.
What got my attention when reading this was: “Looking back, I think it might’ve been an excuse to avoid writing too much JavaScript – and honestly, who could blame us?”
That’s an interesting idea because I absolutely do do things to avoid writing too much Javascript. explicitly so. And questioning that is worth something to me - am I blinded by an obsolete ideology? Was it ever REALLY a good idea, or unfairly biased even back then?
Those are great questions and despite the author’s attitude, I tried to keep an open mind… but like I hinted at in my other comment, the arguments either lack substance entirely or seem like they’re attacking strawmen rather than what I actually do/did. (I still have the code to some of my old work projects from 2005-2010 so I can check how I used to do it without the rose colored glasses!)
Of course, I have confirmation bias toward my existing beliefs too, but if this is to be actually overcome, authors need to attack it head on, not just assume everyone agrees with them already and knock down things that weren’t reality.
Author seems emotionally invested in the JS frameworks right now, so this probably makes it hard to reach an objective comparison. Which is fine (we aren’t robots) but they still present the history as if this were some settled argument and what’s new is an improvement over what came before.
I was excited by the prospect of rendering React on the server (components are a great idea for both server and client-rendered views IMO) but then found out some of them simply don’t work in a server context currently. That’s disappointing, I thought the whole point was to own the runtime/platform so you can render them wherever.
I find this article unpersuasive. The issues with PHP were largely about the language and stdlib design (e.g. this article, but also things like which
mysql_functions to use). But the “lack of ambition in our web apps” wasn’t true: Facebook was written in PHP, Slack was mostly PHP, and Lyft was a PHP monolith until ~2019. Rails apps never embraced a full SPA model and they were certainly as ambitious to make superior products as they are now.Additionally… I really wish people, ever, would link evidence that customers want rich web apps that use everything megabytes of JavaScript provides. My belief is that Silicon Valley’s ecosystem decided this was something their products needed, and it certainly signaled sheen and “we’re serious” to investors and other people in the game, but I’ve yet to see any hard data of actual masses of customers choosing Product A over Product B because they just loved that it didn’t call the server for a refresh, or had a cute animation. In my observation, most people have a relationship to their products like most people have with JIRA: the “quality” of the product is irrelevant (many even hate them) but they’re still used because they’re invaluable for the product they provide, and I haven’t seen much edge in SPAs.
Like, even look at us (software people) and GitHub. Can we really say it was so much worse before they rewrote the frontend in React? Was there a great wash of quality after the rewrite? I’ve only heard people complain about what they lost in it, but more to the point, we were using GitHub fine in the jQuery days.
I don’t mean to rail against the author here, and I fear I’ve done the thing of not responding to the article at this point, but a set of feelings it triggered in me. In any case, maybe I’m old but:
having learned php recently for a personal project, i will say i agree with the title and not much more than that
react is not php
and at least for generating markup i would rather use php, honestly. my static site currently is a fairly small pile of php coördinated by a hand-written Makefile, and i’ve found the experience to be much lower-friction than anything in javascript (granted, this is NOT the typical use case)
also as a language i actually rather enjoy php. it has static typing, namespaces, easy integration with external programs, trivial but powerful templating support, and some syntactic choices that i should probably view as odd but actually like a lot
Sounds like the future is a little like old ASP.net.
What I fail to see, is why can’t you build a great experience with PHP, I have been doing that for years