5 ms·

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 clien

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.
    - gbalduzzi 4y ago
      > 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. No, that's a requirement on most business cases, my comment stated 'complex and dynamic web apps'. Re-rendering the whole page everytime the user checks a box or clicks a button just to replace some fields in a whole page is (a) terrible UX, (b) hard to track the state between page refresh, (c) wrong practice and (d) bad performance. > Here's just one of ten-thousand other battle-tested options you can use: https://github.com/apache/thrift/ https://github.com/apache/thrift/ Sure, I should setup a complex and huge dependency for just one of the many problems I highlighted. What a great idea
      - ratww 4y ago
- indymike 4y ago
  > This is exactly the kind of non-nuanced, buzzwordy and handwavy advertising I was ranting about. I spent four years working on a Meteor.js app. Meteor's main appeal is isomorphic code and a high degree of reactivity. As the app evolved we replaced the in-built MongoDB with GraphQL. It was nice to have one language and GraphQL was very useful. Eventually this kind of model may be the future, but the next project I did, instead of Meteor, I went with a more conventional Vue front end with REST & websocket api for the backend. The reason for the change is that while Node is really nice, Django and Go get predictable outcomes with less time spend on tooling, patching and updates. With a small team, losing lots of hours to "our build broke because an upstream dependency changed a function signature" is not a good thing.
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.

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.
  - gbalduzzi 4y ago
    > 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. No, that's a requirement on most business cases, my comment stated 'complex and dynamic web apps'. Re-rendering the whole page everytime the user checks a box or clicks a button just to replace some fields in a whole page is (a) terrible UX, (b) hard to track the state between page refresh, (c) wrong practice and (d) bad performance. > Here's just one of ten-thousand other battle-tested options you can use: https://github.com/apache/thrift/ https://github.com/apache/thrift/ Sure, I should setup a complex and huge dependency for just one of the many problems I highlighted. What a great idea
    - ratww 4y ago
indymike 4y ago
> This is exactly the kind of non-nuanced, buzzwordy and handwavy advertising I was ranting about. I spent four years working on a Meteor.js app. Meteor's main appeal is isomorphic code and a high degree of reactivity. As the app evolved we replaced the in-built MongoDB with GraphQL. It was nice to have one language and GraphQL was very useful. Eventually this kind of model may be the future, but the next project I did, instead of Meteor, I went with a more conventional Vue front end with REST & websocket api for the backend. The reason for the change is that while Node is really nice, Django and Go get predictable outcomes with less time spend on tooling, patching and updates. With a small team, losing lots of hours to "our build broke because an upstream dependency changed a function signature" is not a good thing.

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.