3 ms·

It's not hiring difficulties, people have limited time and energy to specialise - you can't simply try harder and hire someone who is the best front end and the

by mrtksn 4y ago

It's not hiring difficulties, people have limited time and energy to specialise - you can't simply try harder and hire someone who is the best front end and the best backend developer at the same time. Sure, you can still have clean separation of concerns and send rendered page to the user instead having the user run the UI on their device and fetch data as needed but that's just extra work and higher data transfers(in fact, it's a common practice to send the initial page as a full HTML for SEO purposes). If that's your thing, sure go ahead. But you are keeping dismissing the interoperability part. Since you are now sending fully rendered browser specific output you loose your chance to use the same backend for different type of clients, such as mobile apps or other tools that can work with your system. You instantly need to create client specific output for each and every client type. If you want to do it, go ahead. Certainly things can be achieved in worse ways at higher costs, maybe some people have reasons to want that? I wouldn't know why though. An art form? A protest? A way to inflate the budget to bill more work for each type of client?

jhgb 4y ago
> It's not hiring difficulties, people have limited time and energy to specialise. I never claimed otherwise. > but that's just extra work and higher data transfers Not necessarily. For example, when compression is being employed, I doubt that something like Rails' Turbo will transfer measurably more data in a page update than sending a JSON or XML representation of the very same data. > But you are keeping dismissing the interoperability part. Since you are now sending fully rendered browser specific output you loose your chance to use the same backend for different type of clients No, I'm not! In a single address space, you can generate outputs for multiple clients just as easily as for one client. Literally nothing prevents you from doing that.
- mrtksn 4y ago
  A JSON containing the data to update a piece in the page will always be measurably smaller than the full UI, no matter how you compress it because you can compress the JSON too. If you use something that loads HTML or something like that from the server instead of reloading the whole page, congratulations you made a funny SPA. Sure you can make outputs for multiple clients just as easily. On the traditional SPA though, you don't need to make those at all. I think the advantages are clear at this point. > I never claimed otherwise. You literally called it "hiring difficulties". What's the point to argue after this?
  - jhgb 4y ago
    > A JSON containing the data to update a piece in the page will always be measurably smaller than the full UI There's no need to compress the full UI again. Rails' Turbo for example transfers only the minimum fragment required. > Sure you can make outputs for multiple clients just as easily. On the traditional SPA though, you don't need to make those at all. Neither do you have to do that in a traditional MPA. One client = one frontend, surely? > You literally called it "hiring difficulties". What's the point to argue after this? Did I misunderstand the comment I was responding? You wrote "people have limited time and energy to specialise". The way I interpreted it was that different people have different strengths, so it's difficult to hire someone who has many different strengths at once (and for example wouldn't poke a hole in your PHP code, to use your own example).
    - mrtksn 4y ago
      > here's no need to compress the full UI. Rails' Turbo for example transfers only the minimum fragment required. That's SPA fetching HTML instead of JSON or something. You are welcome.
      - jhgb 4y ago
        As per Wikipedia: > In a SPA, a page refresh never occurs This is not true with something like Turbo: the partial transfer may or may not take place depending on whether it's useful to do that. The point is that you don't have to even care about that (and I'm not even sure you even any control over that). From the perspective of a Rails programmer, you're generating whole pages. How they get to the client is immaterial to you. Think of it as compression (which is actually is, basically using the previously tranferred data as a dictionary).
        mrtksn 4y ago
        It's alright, Rails programmers can do that. Nice little trick for building SPAs. There are other systems that use the technique, it has some advantages and disadvantages. If it works for you, great. What's the point to argue against the advantages of SPA?
hw 4y ago
> But you are keeping dismissing the interoperability part. Since you are now sending fully rendered browser specific output you loose your chance to use the same backend for different type of clients, such as mobile apps or other tools that can work with your system. It really depends on what you are building and if the interoperability is a requirement vs costs and simplicity. I was part of a 4 person engineering team, all who are full stack, that built an app in Rails, started with server side rendering and later on moved to React, but much of what we had were still serverside rendered html. But our mobile app was done in Cordova and we didnt have to pay for mobile engineers (who usually are exclusively mobile) and to build out APIs for the mobile client. As a result our team was able to move multiple times faster than another team that had 4 frontend 6 backend and 8 mobile devs. There are inherent costs when you have multiple teams/components or even specializations, especially around coordination and communication.

by mrtksn 4y ago

jhgb 4y ago

> It's not hiring difficulties, people have limited time and energy to specialise. I never claimed otherwise. > but that's just extra work and higher data transfers Not necessarily. For example, when compression is being employed, I doubt that something like Rails' Turbo will transfer measurably more data in a page update than sending a JSON or XML representation of the very same data. > But you are keeping dismissing the interoperability part. Since you are now sending fully rendered browser specific output you loose your chance to use the same backend for different type of clients No, I'm not! In a single address space, you can generate outputs for multiple clients just as easily as for one client. Literally nothing prevents you from doing that.

mrtksn 4y ago
A JSON containing the data to update a piece in the page will always be measurably smaller than the full UI, no matter how you compress it because you can compress the JSON too. If you use something that loads HTML or something like that from the server instead of reloading the whole page, congratulations you made a funny SPA. Sure you can make outputs for multiple clients just as easily. On the traditional SPA though, you don't need to make those at all. I think the advantages are clear at this point. > I never claimed otherwise. You literally called it "hiring difficulties". What's the point to argue after this?
- jhgb 4y ago
  > A JSON containing the data to update a piece in the page will always be measurably smaller than the full UI There's no need to compress the full UI again. Rails' Turbo for example transfers only the minimum fragment required. > Sure you can make outputs for multiple clients just as easily. On the traditional SPA though, you don't need to make those at all. Neither do you have to do that in a traditional MPA. One client = one frontend, surely? > You literally called it "hiring difficulties". What's the point to argue after this? Did I misunderstand the comment I was responding? You wrote "people have limited time and energy to specialise". The way I interpreted it was that different people have different strengths, so it's difficult to hire someone who has many different strengths at once (and for example wouldn't poke a hole in your PHP code, to use your own example).
  - mrtksn 4y ago
    > here's no need to compress the full UI. Rails' Turbo for example transfers only the minimum fragment required. That's SPA fetching HTML instead of JSON or something. You are welcome.
    - jhgb 4y ago
      As per Wikipedia: > In a SPA, a page refresh never occurs This is not true with something like Turbo: the partial transfer may or may not take place depending on whether it's useful to do that. The point is that you don't have to even care about that (and I'm not even sure you even any control over that). From the perspective of a Rails programmer, you're generating whole pages. How they get to the client is immaterial to you. Think of it as compression (which is actually is, basically using the previously tranferred data as a dictionary).
      - mrtksn 4y ago
        It's alright, Rails programmers can do that. Nice little trick for building SPAs. There are other systems that use the technique, it has some advantages and disadvantages. If it works for you, great. What's the point to argue against the advantages of SPA?

hw 4y ago

> But you are keeping dismissing the interoperability part. Since you are now sending fully rendered browser specific output you loose your chance to use the same backend for different type of clients, such as mobile apps or other tools that can work with your system. It really depends on what you are building and if the interoperability is a requirement vs costs and simplicity. I was part of a 4 person engineering team, all who are full stack, that built an app in Rails, started with server side rendering and later on moved to React, but much of what we had were still serverside rendered html. But our mobile app was done in Cordova and we didnt have to pay for mobile engineers (who usually are exclusively mobile) and to build out APIs for the mobile client. As a result our team was able to move multiple times faster than another team that had 4 frontend 6 backend and 8 mobile devs. There are inherent costs when you have multiple teams/components or even specializations, especially around coordination and communication.