3 ms·

I don't know why it feels like creative accounting to you(I actually do, see next paragraph). Indeed, by drawing a circle around a code you change the architect

by mrtksn 4y ago

I don't know why it feels like creative accounting to you(I actually do, see next paragraph). Indeed, by drawing a circle around a code you change the architecture through separation of concerns and break down larger problem into smaller parts. As a result of this, your system acquires new properties. It all matters because the code is written by people and people specialise. Maybe from computational perspective you are just moving the computation from one place to another but from development perspective you are breaking down code into pieces that specialised people can work on. Instead of having a linux wiz coding CSS or front-end guy creating security holes in your PHP code you have a front-end dev who can talk to backend-dev and all do their parts and the mobile-app-dev can join the party later and simply use the existing work done by the back-end dev. All that when having some of your computations offloaded to the client devices. It's pretty neat.

jhgb 4y ago
> Indeed, by drawing a circle around a code you change the architecture through separation of concerns and break down larger problem into smaller parts. I'm not saying "don't have cleanly separated components". I just fail to see why it matters that the network communication has to happen between very specific modules and not some other ones. Ideally your system wouldn't even notice at all if you moved the "network border" within your system. Some systems would notice that, mainly performance-wise (for example moving a database engine (which uses random access to a large amount of data) across the border could be a problem), but I imagine that many would not. > or front-end guy creating security holes in your PHP code You do realize that this falls under the "hiring difficulties" qualification I've added in my previous comment? > you have a front-end dev who can talk to backend-dev and all do their parts and the mobile-app-dev can join the party later and simply use the existing work done by the back-end dev People can communicate with each other and collaborate regardless of whether their code runs on the same machine or not. For example, now with Microsoft's Blazor, just because the user interface is going to be programmed in the same address space and process as the backend doesn't mean that two different people with different strengths can't work on two different parts of the same large program. You can still have the guy who's better at dealing with UI design do the UI, and the guy who's good at writing fast database code write the backend. Not sure what prevents you from doing that.
- 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?

by mrtksn 4y ago

jhgb 4y ago

> Indeed, by drawing a circle around a code you change the architecture through separation of concerns and break down larger problem into smaller parts. I'm not saying "don't have cleanly separated components". I just fail to see why it matters that the network communication has to happen between very specific modules and not some other ones. Ideally your system wouldn't even notice at all if you moved the "network border" within your system. Some systems would notice that, mainly performance-wise (for example moving a database engine (which uses random access to a large amount of data) across the border could be a problem), but I imagine that many would not. > or front-end guy creating security holes in your PHP code You do realize that this falls under the "hiring difficulties" qualification I've added in my previous comment? > you have a front-end dev who can talk to backend-dev and all do their parts and the mobile-app-dev can join the party later and simply use the existing work done by the back-end dev People can communicate with each other and collaborate regardless of whether their code runs on the same machine or not. For example, now with Microsoft's Blazor, just because the user interface is going to be programmed in the same address space and process as the backend doesn't mean that two different people with different strengths can't work on two different parts of the same large program. You can still have the guy who's better at dealing with UI design do the UI, and the guy who's good at writing fast database code write the backend. Not sure what prevents you from doing that.

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?