While I completely agree with you (and also think that the grandparent post was a bit inflamatory), the argument here is not that newer technologies aren't better. The argument is that the techniques themselves were "forgotten" and are now being rediscovered.
This is easily verifiable by people claiming that the term "Server Side Rendering" can't be retroactively applied, even though it unambiguously means what PHP used to do.
I personally enjoy both the old and new techniques, and I think it's a natural progression to use those new frameworks for also rendering on the server. Not only because of code-sharing, but because I think they're better than old templating engines.
> argument is that the techniques themselves were "forgotten" and are now being rediscovered
Which is a silly, lazy argument.
> by people claiming that the term "Server Side Rendering" can't be retroactively applied
Show me one such claim. The only people I've seen use this argument are the detractors. The ability for JS to run both client/server means we can do things with it that are not possible with PHP or other server-only languages, and frameworks like React are pushing that boundary. Pointing out that JS has these unique opportunities is not even remotely the same as "forgetting" and "rediscovering" SSR.
> "The ability for JS to run both client/server means we can do things with it that are not possible with PHP or other server-only languages, and frameworks like React are pushing that boundary. Pointing out that JS has these unique opportunities is not even remotely the same as "forgetting" and "rediscovering" SSR."
Can you provide even a single example for something we can do with JS running on both the client and the server, that was otherwise "impossible" (quoting you here), or very difficult, without this capability?
Doing "new" stuff and being more performant is really in the domain of the web browser, not in the javascript libraries that run on browser engines. Saying React doesn't enable "new" stuff in that regard isn't really fair because React isn't meant to do that. What React does do is allow for the development of maintainable complex applications such as most major web apps you use including Instagram, Facebook.com, Netflix.com, etc.
> The ability for JS to run both client/server means we can do things with it that are not possible with PHP or other server-only languages, and frameworks like React are pushing that boundary.
Sure it does, but this doesn't mean that PHP wasn't rendering on the server. The term still applies to what PHP was doing.
> Pointing out that JS has these unique opportunities is not even remotely the same as "forgetting" and "rediscovering" SSR.
Pointing out those unique opportunities is not a problem, and I agree with you on that. But it has absolutely nothing to do with the usage of SSR or the term SSR. Also, using the same language on server and client is older than modern JS frameworks, which definitely counts as something being "rediscovered". And yes, is definitely a cool thing, nobody is claiming the contrary.
Yes it is. It's a method of achieving something or carrying something out. But not only it doesn't matter, I don't think anyone else is interested in a stupid semantics discussion.
This is easily verifiable by people claiming that the term "Server Side Rendering" can't be retroactively applied, even though it unambiguously means what PHP used to do.
I personally enjoy both the old and new techniques, and I think it's a natural progression to use those new frameworks for also rendering on the server. Not only because of code-sharing, but because I think they're better than old templating engines.