17 ms·

I'm not an Uncle Bob fan by any stretch of the imagination, but he wrote a somewhat famous article about this phenomenon: http://blog.cleancoder.com/uncle-bob/2

I'm not an Uncle Bob fan by any stretch of the imagination, but he wrote a somewhat famous article about this phenomenon: http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html With each new wave - we get people that either lack the time, the willpower or the conditions to understand what came before them (the ground they're standing on), and this is how we end up rediscovering things every 2-3 years. It's much more tempting to just discard old knowledge, reinvent from scratch. People were doing "SSR" with PHP on the server-side 30 years ago, and still do today (can you imagine just how much progress that platform has made, and how much collective knowledge has been developed around it?). It's just not hip anymore, because it wasn't invented within the past 36 months.

thisiswrongggg 4y ago
Yeah, he should know. There so much irony of this criticism coming from a guy that contributed to the max to the entropy of dubious and cargocult terms and "principles" in the field.
zepolen 4y ago
You can't compare JS SSR with PHP, SSR implies there is CSR which is not the case with PHP. Then having one language, no, one _shared code base_ for both client and server, which automatically can only send the minimum necessary over the wire? That's a _huge_ step forward. And I say this as someone who was developing CGI scripts before PHP came along.
- csmpltn 4y ago
  > "Then having one language, no, one _shared code base_ for both client and server, which automatically can only send the minimum necessary over the wire? That's a _huge_ step forward." This is exactly the kind of non-nuanced, buzzwordy and handwavy advertising I was ranting about. 1. Why should having the client and server share the same codebase even be a goal in the first place? This should be a nuanced conversation with different trade-offs, there's no one-size-fits-all here. It's disingenuous to paint this as an ideal we all have to work towards on a whim. 2. I don't even know where's the innovation in being able to "send the minimum necessary over the wire". This is a pillar of decent software engineering. We've been severely regressing here due to the pervasive use of bloated abstraction layers, combined with a deep lack of understanding of how things work (ref. the Uncle Bob post I've linked earlier).
  - gbalduzzi 4y ago
    > 1. Why should having the client and server share the same codebase even be a goal in the first place? Because, in building complex and dynamic web apps, the alternative is to repeat a lot of the same logic in both frontend and backend. Of course if you are building a blog or a simple static page this is not useful, most of the new techniques are a response to more advanced requirements. For instance, right now I'm building a "buy form" for internal use (by employees only) in a shop. There is a ton of domain login used to select which field to display, what validation login to use, how to autocomplete some fields ecc ecc. The system is a PHP/Laravel server with SSR rendering and vue only used for some specific advanced components. Most of the logic inside the form has to be written two times: in PHP and in vue. Most enum types are repeated (and must be kept in sync). Having one shared codebase would simplify A LOT the development.
    - csmpltn 4y ago
      > "Most of the logic inside the form has to be written two times: in PHP and in vue" Why? That's just your choice of how to build your app, right? You could've avoided this by rendering templates on the server and sending static HTML to the client, keeping the business logic on the server. > "Most enum types are repeated" Here's just one of ten-thousand other battle-tested options you can use: https://github.com/apache/thrift/ https://github.com/apache/thrift/
      - rictic 4y ago
        > Why? To take just one of many examples, so that you can do the same validation client side and the server side. You have to do the validation on the server because the client can't be trusted, but if you only do it on the server you have to do a full page load to validate any of the inputs, give feedback, or vary the form fields displayed. e.g. how many times have you filled out a long and complicated form, pressed submit, waited several seconds, and then get dropped back at the same form where you have to hunt for the error message, change the requested field and try again. And heaven help you if you got multiple fields wrong, where the data from one informs the validation of another. Client-side logic can make this process much lower friction.
- ksec 4y ago
  >SSR implies there is CSR which is not the case with PHP. Wait a minutes, so now SSR is explicit to JS and with JS CSR?
  - ratww 4y ago
    That's definition is definitely not widely accepted, however some people seem to believe it is. So I guess it's open for debate.
e12e 4y ago
> People were doing "SSR" with PHP on the server-side 30 years ago, and still do today (can you imagine just how much progress that platform has made, and how much collective knowledge has been developed around it?). It's just not hip anymore, because it wasn't invented within the past 36 months. Well, kind of. The thing is that the natural progression from server side rendering/content-generation with only html and css, via Asynchronous JavaScript and XML (AJAX) to the current js-first paradigm - was a transition from hypertext document system to "movable code" (In the terms of Fielding's REST thesis)[1]. Keeping state/cache consistent works differently in the two paradigms (and they have different benefits/trade-offs). There's a real tention between "application" and "document system". And a lot of what seems insane about contemporary web dev, is when people take something that is clearly easily/well solved as a "document system" (eg: blog/homepage) - and implement it as an application (essentially writing half of a web browser in js - with custom routing/addressing and widgets). It's the reverse of the problem react et al tries to solve: writing an application using a document system (ie: a complex php app). [1] Ed: In particular "Mobile Agent" - the last section in https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_5 https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch...
- indymike 4y ago
  > There's a real tention between "application" and "document system". Not really. The web implements a "document as application" or "living document" model. Since the most rudimentary software is just printing static text (and static graphics) you get quite a bit of mileage with just HTML & CSS. The web scales nicely from this to fully interactive applications, and I think some of the tension you are perceiving comes from the fact it's easy to disable or override features built into to the browse, and often developers find a way to do something novel, and in doing so, break thinks like the clipboard.
  - e12e 4y ago
    I think you misread my comment - obviously hypertext systems are "applications" for some definition of "application" - but there are distinct types, constraints and architectures. Mysql and php are not my first choice for creating a multi-player driving game - and even for an irc client they're not my first choice. However, for an asynchronous message board, news or mail client they might be fine.
mypalmike 4y ago
- ratww 4y ago
  While Vanilla-PHP was definitely mostly just doing text substitution and had injection issues, there were other languages and template engines that were able to fix this by having more sensible defaults where raw-html interpolation is not a default. Also, keep in mind that injection attacks are definitely still possible with modern frameworks. The same old techniques apply when you're dealing with data originating from users. Sure, the raw-html interpolation is not a default anymore, but like I said that's also present in old backend tech.
  - mypalmike 4y ago
    The comparison I am responding to is original PHP ("30 years ago", which itself is garbage of course, given the language did not exist 30 years ago), not the new goalposts you have planted.
    - ratww 4y ago
      I'm not disputing anywhere that the original PHP has issues, and in fact I'm acknowledging that in the beginning of the first paragraph. Adding additional information and context is not moving goalposts. What I'm actually reacting to is the rude provocation at the second paragraph that grandparent must "Look at the actual tech here. Do a tutorial. Discover what the difference is". They probably don't have to, because this specific advantage is not novel. ...not that this deserved any answer, considering the original reply is now flagged/dead. Maybe someone should tell you to check the website guidelines.
      - mypalmike 4y ago
        My reply was not intended to be rude or provocative. "We did this ages ago" is said so often, rudely and in ignorance, as it was here. And while there are often parallels to support the claim, the important distinctions are missed in ways that are best taught with hands on experience. Hence the suggestion to actually learn the new tools. If course, this is arguing in the internet with a curmudgeon, which I should not have bothered doing. I just don't want to see hn become slashdot, where this poo pooing of new tech happened in every thread.
thr0wawayf00 4y ago
> It's just not hip anymore, because it wasn't invented within the past 36 months. Yes, technology moves in cycles but statements like this grossly generalize. The amount of Javascript running on the web has exploded over the last decade plus to the point that frameworks like React were released to create more modern, interactive experiences because that's what business demanded. Then the industry started figuring out that the virtual DOM was kind of a scam from a performance standpoint and started looking for ways to achieve better performance and SEO, which brought us back to SSR and more advanced client/server architectures like this.
- quelltext 4y ago
  > Then the industry started figuring out that the virtual DOM was kind of a scam from a performance standpoint Could you elaborate? Not a frontend guy but my understanding was that the virtual DOM is what's necessary to enable a simplified model where you can code as if your entire view was rerendered from scratch when there's a change. Mutating the DOM only where and when you need to in a handcrafted fashion is always going to be faster, it's just not scalable, I guess. So, in that context the virtual DOM is not really a scam. Not sure in what sense it is? Was it claimed to be performing better than it does?
  - ratww 4y ago
    Your understanding is correct. Virtual DOM never promised better performance than pre-rendered static HTML. It only achieves better performance (and better UX) than dumbly re-rendering the whole website whenever the underlying data changes. The reason people are doing SSR with modern JS-frameworks is quite simple: some kinds of content aren't a good fit for SPAs (or maybe there are other constraints that favour rendering it all in the server), but it might still be desirable to use modern JS-frameworks. For example: you wouldn't implement a blog as an SPA, but it might still be desirable to use React to render everything.
ratww 4y ago
I mean, sure, there were "web pages being rendered on the server" back in the day. But that was the rule, and there was no name for it. Wikipedia's SSR page used to be called "Server Side Scripting", which is kind of a misnomer, and is very generic. That would also include serving JSON from the backend... and "scripting" not only limited in scope but also non-ambiguous. So, someone had to invent a term. The name "Server Side Rendering" is quite good actually, it describes what's actually happening rather than being some random buzzword. (Of course, there will be people claiming "ackshually SSR is only when a Next.js-like-framework does it", but that was never agreed upon by the majority of devs)
zeroonetwothree 4y ago
I’ve been developing for the web since, well not quite 30 years ago (PHP isn’t even 30!), but let’s say 25 years ago. I’ve used so much different tech in those years that I have a pretty good sense of it, and I even contributed to the development of both PHP and React. And you are totally off base. Modern frameworks are far superior for building modern web apps than older serverside tech. Demands have changed and so we need new tools to address this. Does this mean every single “new hotness” is truly a set change? No, of course not, a lot of things are just fads. Actually I would put SSR slightly in that camp, for while it’s certainly beneficial it’s not really a game changer. It’s just a modest performance optimisation (in some cases!).
- ratww 4y ago
  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.
  - tomnipotent 4y ago
    > 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.
    - 4y ago
nindalf 4y ago
Others have responded to the technical deficiencies in your comment. I’ll just say it’s a bit rich to be telling the developers of React - “all this can be done with a server side rendered PHP”. The developers of React are well aware of what PHP can do, because they work at a company with one of the largest PHP (-ish) codebases in the world. Almost all pages on Facebook were completely server rendered, but they’re gradually moving towards React based web pages. Please consider that the people making technical decisions might know what they’re doing. Please don’t condescend.
- chrischen 4y ago
  The funny thing is as far as I know they still use PHP to render React (via embedded javascript interpreter) on the server.
  - nindalf 4y ago
    You have a source for that? The React code I've seen at Facebook is client rendered.
    - chrischen 4y ago
      > Whenever they want to run JavaScript on server (e.g. rendering React on server) they just use V8 directly rather than using Node. I forgot where I read it, but it was someone on the internet where they embed V8 and call from PHP (Hack). https://hashnode.com/post/10-things-you-probably-didnt-know-about-javascript-react-and-nodejs-and-graphql-development-at-facebook-cink0r0e500h5io53fpl7ediu https://hashnode.com/post/10-things-you-probably-didnt-know-... It's true they don't really use SSR that widely, as Facebook.com doesn't really need it, but I'm pretty sure they do use streaming SSR, which offers UX benefits.
      - nindalf 4y ago
        From your link > Yes, Facebook uses SSR heavily. However, according to Lee, there are very few areas where they use React to render components on server. This was primarily a decision based on their server environment which is Hack. Yeah this is my whole point. That person was attempting to school devs at Facebook on the benefits of server side rendering in PHP. And whatever you said was quite niche.
dgb23 4y ago
I've been doing both, or rather different kinds of combinations from almost full PHP to PHP with jQuery/Backbone/Angular, and since a while React SPA to Node based including Nextjs. Also just using dependency less JS and htmx as well. All depending on the scope and requirements of the particular projects. For side projects I've built stuff with quite few other languages. This is for professional context. My conclusion so far is that most of the criticism towards JS based solutions is largely outdated if you pick your tools and libs well. The leverage of something like Nextjs and similar is pretty significant over traditional SSR, even for cases where the latter made more sense a while ago, increasingly so. I don't think PHP is going anywhere in the near future, but I see fewer and fewer reasons to use it at all. 1. When people talk about isomorphic code for frontend related stuff, they often pick form validation as the example. But this is just one of many things. It's also the tooling, testing, types and other integrations that you miss if your frontend logic is spread across language boundaries. 2. Unoptimized performance of a PHP vs Node/Next application is quite significant as PHP needs to recreate the whole application state with every request. 3. Frontend without or "minimal" JS is a pure luxury that you almost never get to have and if you do, it comes with its own complexities. 4. Websockets and other features are a pain to use (if you can use them at all) in PHP. 5. Development is faster and more responsive with a React/Nextjs/etc. based implementation. The feedback loops are faster, tooling and libraries are more integrated. 6. There are quite few good libraries popping up in recent years for JS that give you more leverage than what I'm used to from PHP. 7. Commoditized hosting PHP has been one of its strengths, but even that is being outcompeted slowly but steadily. 8. By default there are things you cannot do or only with additional (unnecessary) effort if you split your frontend logic into two places, rather than having a single, comprehensive codebase. Frameworks and libraries like Next, Remix, this one and others are leveraging that. Yes it gets more complex but you also get more optimizations Please note that I don't particularly like either JS or PHP. I think both languages and ecosystems are quite terrible in their own ways and have to be tamed by pragmatic developers. So no emotional attachment there.
- idkwhoiam 4y ago
  Cost is a big reason in many countries. PHP is still the cheaper option for dynamic websites. Shared webhosting costs peanuts.
chrischen 4y ago
You’re only looking at the outputs or end result and from that perspective React is just going to put out what is very similar to the “DHTML” stuff back then. At the end of the day everything is still just pushing HTML to browsers. What React introduces is functional composition to application design (if you do it right at least), and the main benefit of this is in maintainability, scalability, and reusability. For most simple apps this benefit can be completely moot, which is why some can feel the setup or learning of a new paradigm for seemingly no benefit can be a regression. In fact if you wanted to use React in the same way that PHP was used a decade ago, you still can, and it isn’t any more difficult to do so. You just end up with much less maintainable code. You can render React server side just like PHP, and either mount dynamic client side interactive components purely on the client side just like the “good old days,” or you can also render them server side and take advantage of client side hydration at the component level (like the previous method but you also get an initial server render). While this sounds complex, it really is just about as complex as making a server rendered PHP with some interactive JS bits, but just adding some new words to describe the process. The goal of new React features like server components is to bring the maintainability of functional composition and get this optimization for free while still being able to define your UI in terms of reusable functions.

thisiswrongggg 4y ago

Yeah, he should know. There so much irony of this criticism coming from a guy that contributed to the max to the entropy of dubious and cargocult terms and "principles" in the field.

zepolen 4y ago

You can't compare JS SSR with PHP, SSR implies there is CSR which is not the case with PHP. Then having one language, no, one _shared code base_ for both client and server, which automatically can only send the minimum necessary over the wire? That's a _huge_ step forward. And I say this as someone who was developing CGI scripts before PHP came along.

csmpltn 4y ago
> "Then having one language, no, one _shared code base_ for both client and server, which automatically can only send the minimum necessary over the wire? That's a _huge_ step forward." This is exactly the kind of non-nuanced, buzzwordy and handwavy advertising I was ranting about. 1. Why should having the client and server share the same codebase even be a goal in the first place? This should be a nuanced conversation with different trade-offs, there's no one-size-fits-all here. It's disingenuous to paint this as an ideal we all have to work towards on a whim. 2. I don't even know where's the innovation in being able to "send the minimum necessary over the wire". This is a pillar of decent software engineering. We've been severely regressing here due to the pervasive use of bloated abstraction layers, combined with a deep lack of understanding of how things work (ref. the Uncle Bob post I've linked earlier).
- gbalduzzi 4y ago
  > 1. Why should having the client and server share the same codebase even be a goal in the first place? Because, in building complex and dynamic web apps, the alternative is to repeat a lot of the same logic in both frontend and backend. Of course if you are building a blog or a simple static page this is not useful, most of the new techniques are a response to more advanced requirements. For instance, right now I'm building a "buy form" for internal use (by employees only) in a shop. There is a ton of domain login used to select which field to display, what validation login to use, how to autocomplete some fields ecc ecc. The system is a PHP/Laravel server with SSR rendering and vue only used for some specific advanced components. Most of the logic inside the form has to be written two times: in PHP and in vue. Most enum types are repeated (and must be kept in sync). Having one shared codebase would simplify A LOT the development.
  - csmpltn 4y ago
    > "Most of the logic inside the form has to be written two times: in PHP and in vue" Why? That's just your choice of how to build your app, right? You could've avoided this by rendering templates on the server and sending static HTML to the client, keeping the business logic on the server. > "Most enum types are repeated" Here's just one of ten-thousand other battle-tested options you can use: https://github.com/apache/thrift/ https://github.com/apache/thrift/
    - rictic 4y ago
      > Why? To take just one of many examples, so that you can do the same validation client side and the server side. You have to do the validation on the server because the client can't be trusted, but if you only do it on the server you have to do a full page load to validate any of the inputs, give feedback, or vary the form fields displayed. e.g. how many times have you filled out a long and complicated form, pressed submit, waited several seconds, and then get dropped back at the same form where you have to hunt for the error message, change the requested field and try again. And heaven help you if you got multiple fields wrong, where the data from one informs the validation of another. Client-side logic can make this process much lower friction.
ksec 4y ago
>SSR implies there is CSR which is not the case with PHP. Wait a minutes, so now SSR is explicit to JS and with JS CSR?
- ratww 4y ago
  That's definition is definitely not widely accepted, however some people seem to believe it is. So I guess it's open for debate.

e12e 4y ago

> People were doing "SSR" with PHP on the server-side 30 years ago, and still do today (can you imagine just how much progress that platform has made, and how much collective knowledge has been developed around it?). It's just not hip anymore, because it wasn't invented within the past 36 months. Well, kind of. The thing is that the natural progression from server side rendering/content-generation with only html and css, via Asynchronous JavaScript and XML (AJAX) to the current js-first paradigm - was a transition from hypertext document system to "movable code" (In the terms of Fielding's REST thesis)[1]. Keeping state/cache consistent works differently in the two paradigms (and they have different benefits/trade-offs). There's a real tention between "application" and "document system". And a lot of what seems insane about contemporary web dev, is when people take something that is clearly easily/well solved as a "document system" (eg: blog/homepage) - and implement it as an application (essentially writing half of a web browser in js - with custom routing/addressing and widgets). It's the reverse of the problem react et al tries to solve: writing an application using a document system (ie: a complex php app). [1] Ed: In particular "Mobile Agent" - the last section in https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_5 https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch...

indymike 4y ago
> There's a real tention between "application" and "document system". Not really. The web implements a "document as application" or "living document" model. Since the most rudimentary software is just printing static text (and static graphics) you get quite a bit of mileage with just HTML & CSS. The web scales nicely from this to fully interactive applications, and I think some of the tension you are perceiving comes from the fact it's easy to disable or override features built into to the browse, and often developers find a way to do something novel, and in doing so, break thinks like the clipboard.
- e12e 4y ago
  I think you misread my comment - obviously hypertext systems are "applications" for some definition of "application" - but there are distinct types, constraints and architectures. Mysql and php are not my first choice for creating a multi-player driving game - and even for an irc client they're not my first choice. However, for an asynchronous message board, news or mail client they might be fine.

mypalmike 4y ago

ratww 4y ago
While Vanilla-PHP was definitely mostly just doing text substitution and had injection issues, there were other languages and template engines that were able to fix this by having more sensible defaults where raw-html interpolation is not a default. Also, keep in mind that injection attacks are definitely still possible with modern frameworks. The same old techniques apply when you're dealing with data originating from users. Sure, the raw-html interpolation is not a default anymore, but like I said that's also present in old backend tech.
- mypalmike 4y ago
  The comparison I am responding to is original PHP ("30 years ago", which itself is garbage of course, given the language did not exist 30 years ago), not the new goalposts you have planted.
  - ratww 4y ago
    I'm not disputing anywhere that the original PHP has issues, and in fact I'm acknowledging that in the beginning of the first paragraph. Adding additional information and context is not moving goalposts. What I'm actually reacting to is the rude provocation at the second paragraph that grandparent must "Look at the actual tech here. Do a tutorial. Discover what the difference is". They probably don't have to, because this specific advantage is not novel. ...not that this deserved any answer, considering the original reply is now flagged/dead. Maybe someone should tell you to check the website guidelines.
    - mypalmike 4y ago
      My reply was not intended to be rude or provocative. "We did this ages ago" is said so often, rudely and in ignorance, as it was here. And while there are often parallels to support the claim, the important distinctions are missed in ways that are best taught with hands on experience. Hence the suggestion to actually learn the new tools. If course, this is arguing in the internet with a curmudgeon, which I should not have bothered doing. I just don't want to see hn become slashdot, where this poo pooing of new tech happened in every thread.

thr0wawayf00 4y ago

> It's just not hip anymore, because it wasn't invented within the past 36 months. Yes, technology moves in cycles but statements like this grossly generalize. The amount of Javascript running on the web has exploded over the last decade plus to the point that frameworks like React were released to create more modern, interactive experiences because that's what business demanded. Then the industry started figuring out that the virtual DOM was kind of a scam from a performance standpoint and started looking for ways to achieve better performance and SEO, which brought us back to SSR and more advanced client/server architectures like this.

quelltext 4y ago
> Then the industry started figuring out that the virtual DOM was kind of a scam from a performance standpoint Could you elaborate? Not a frontend guy but my understanding was that the virtual DOM is what's necessary to enable a simplified model where you can code as if your entire view was rerendered from scratch when there's a change. Mutating the DOM only where and when you need to in a handcrafted fashion is always going to be faster, it's just not scalable, I guess. So, in that context the virtual DOM is not really a scam. Not sure in what sense it is? Was it claimed to be performing better than it does?
- ratww 4y ago
  Your understanding is correct. Virtual DOM never promised better performance than pre-rendered static HTML. It only achieves better performance (and better UX) than dumbly re-rendering the whole website whenever the underlying data changes. The reason people are doing SSR with modern JS-frameworks is quite simple: some kinds of content aren't a good fit for SPAs (or maybe there are other constraints that favour rendering it all in the server), but it might still be desirable to use modern JS-frameworks. For example: you wouldn't implement a blog as an SPA, but it might still be desirable to use React to render everything.

ratww 4y ago

I mean, sure, there were "web pages being rendered on the server" back in the day. But that was the rule, and there was no name for it. Wikipedia's SSR page used to be called "Server Side Scripting", which is kind of a misnomer, and is very generic. That would also include serving JSON from the backend... and "scripting" not only limited in scope but also non-ambiguous. So, someone had to invent a term. The name "Server Side Rendering" is quite good actually, it describes what's actually happening rather than being some random buzzword. (Of course, there will be people claiming "ackshually SSR is only when a Next.js-like-framework does it", but that was never agreed upon by the majority of devs)

zeroonetwothree 4y ago

I’ve been developing for the web since, well not quite 30 years ago (PHP isn’t even 30!), but let’s say 25 years ago. I’ve used so much different tech in those years that I have a pretty good sense of it, and I even contributed to the development of both PHP and React. And you are totally off base. Modern frameworks are far superior for building modern web apps than older serverside tech. Demands have changed and so we need new tools to address this. Does this mean every single “new hotness” is truly a set change? No, of course not, a lot of things are just fads. Actually I would put SSR slightly in that camp, for while it’s certainly beneficial it’s not really a game changer. It’s just a modest performance optimisation (in some cases!).

ratww 4y ago
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.
- tomnipotent 4y ago
  > 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.
  - 4y ago

nindalf 4y ago

Others have responded to the technical deficiencies in your comment. I’ll just say it’s a bit rich to be telling the developers of React - “all this can be done with a server side rendered PHP”. The developers of React are well aware of what PHP can do, because they work at a company with one of the largest PHP (-ish) codebases in the world. Almost all pages on Facebook were completely server rendered, but they’re gradually moving towards React based web pages. Please consider that the people making technical decisions might know what they’re doing. Please don’t condescend.

chrischen 4y ago
The funny thing is as far as I know they still use PHP to render React (via embedded javascript interpreter) on the server.
- nindalf 4y ago
  You have a source for that? The React code I've seen at Facebook is client rendered.
  - chrischen 4y ago
    > Whenever they want to run JavaScript on server (e.g. rendering React on server) they just use V8 directly rather than using Node. I forgot where I read it, but it was someone on the internet where they embed V8 and call from PHP (Hack). https://hashnode.com/post/10-things-you-probably-didnt-know-about-javascript-react-and-nodejs-and-graphql-development-at-facebook-cink0r0e500h5io53fpl7ediu https://hashnode.com/post/10-things-you-probably-didnt-know-... It's true they don't really use SSR that widely, as Facebook.com doesn't really need it, but I'm pretty sure they do use streaming SSR, which offers UX benefits.
    - nindalf 4y ago
      From your link > Yes, Facebook uses SSR heavily. However, according to Lee, there are very few areas where they use React to render components on server. This was primarily a decision based on their server environment which is Hack. Yeah this is my whole point. That person was attempting to school devs at Facebook on the benefits of server side rendering in PHP. And whatever you said was quite niche.

dgb23 4y ago

I've been doing both, or rather different kinds of combinations from almost full PHP to PHP with jQuery/Backbone/Angular, and since a while React SPA to Node based including Nextjs. Also just using dependency less JS and htmx as well. All depending on the scope and requirements of the particular projects. For side projects I've built stuff with quite few other languages. This is for professional context. My conclusion so far is that most of the criticism towards JS based solutions is largely outdated if you pick your tools and libs well. The leverage of something like Nextjs and similar is pretty significant over traditional SSR, even for cases where the latter made more sense a while ago, increasingly so. I don't think PHP is going anywhere in the near future, but I see fewer and fewer reasons to use it at all. 1. When people talk about isomorphic code for frontend related stuff, they often pick form validation as the example. But this is just one of many things. It's also the tooling, testing, types and other integrations that you miss if your frontend logic is spread across language boundaries. 2. Unoptimized performance of a PHP vs Node/Next application is quite significant as PHP needs to recreate the whole application state with every request. 3. Frontend without or "minimal" JS is a pure luxury that you almost never get to have and if you do, it comes with its own complexities. 4. Websockets and other features are a pain to use (if you can use them at all) in PHP. 5. Development is faster and more responsive with a React/Nextjs/etc. based implementation. The feedback loops are faster, tooling and libraries are more integrated. 6. There are quite few good libraries popping up in recent years for JS that give you more leverage than what I'm used to from PHP. 7. Commoditized hosting PHP has been one of its strengths, but even that is being outcompeted slowly but steadily. 8. By default there are things you cannot do or only with additional (unnecessary) effort if you split your frontend logic into two places, rather than having a single, comprehensive codebase. Frameworks and libraries like Next, Remix, this one and others are leveraging that. Yes it gets more complex but you also get more optimizations Please note that I don't particularly like either JS or PHP. I think both languages and ecosystems are quite terrible in their own ways and have to be tamed by pragmatic developers. So no emotional attachment there.

idkwhoiam 4y ago
Cost is a big reason in many countries. PHP is still the cheaper option for dynamic websites. Shared webhosting costs peanuts.

chrischen 4y ago

You’re only looking at the outputs or end result and from that perspective React is just going to put out what is very similar to the “DHTML” stuff back then. At the end of the day everything is still just pushing HTML to browsers. What React introduces is functional composition to application design (if you do it right at least), and the main benefit of this is in maintainability, scalability, and reusability. For most simple apps this benefit can be completely moot, which is why some can feel the setup or learning of a new paradigm for seemingly no benefit can be a regression. In fact if you wanted to use React in the same way that PHP was used a decade ago, you still can, and it isn’t any more difficult to do so. You just end up with much less maintainable code. You can render React server side just like PHP, and either mount dynamic client side interactive components purely on the client side just like the “good old days,” or you can also render them server side and take advantage of client side hydration at the component level (like the previous method but you also get an initial server render). While this sounds complex, it really is just about as complex as making a server rendered PHP with some interactive JS bits, but just adding some new words to describe the process. The goal of new React features like server components is to bring the maintainability of functional composition and get this optimization for free while still being able to define your UI in terms of reusable functions.