4 ms·

> 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 n

by 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?
    - 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).
thiwaw93949500g 4y ago
The point of the person you are replying to is very clear so I am not sure why you insist on arguing. > Not sure what prevents you from doing that. The technology stacks used on the back-end, front-end, mobile apps, and their associated tooling are most of the time very different. Most developers aren't polyglot, or at the very least have a preferred ecosystem in which they are the most productive. By introducing physical boundaries, specialization is easier. For example instead of having a team only composed of Java developer, and having a development workflow and build process requiring Java knowledge, the back-end team may be composed of Java specialists, while the front-end is composed of nodejs + typescript folks, and the mobile app is composed of iOS or Kotlin experts. Is there a technical limitation preventing people from using typescript in a Java project and separating concerns using the java module system or basic folder hierarchy? No. However this rarely happens in practice unless there is clear physical boundary such as the one enabled by SPAs, because people specialize themselves.
- jhgb 4y ago
  > The technology stacks used on the back-end, front-end, mobile apps, and their associated tooling are most of the time very different. Which feels like a major mistake to me. My house doesn't use different construction technologies for different rooms. It was built all at once, why would it have one room built of bricks and another one from glass and steel? (Other than for some artistic reason, I imagine...) > Most developers aren't polyglot, or at the very least have a preferred ecosystem in which they are the most productive. Yeah, sure. But you don't need to artificially exclude the situation where for example everyone on the team speaks C# (like with the emerging Blazor projects). To say that different developers on a project often have different preferred ecosystems does not mean that different developers on a project must have different preferred ecosystems, even if they're working on different parts of the same project. That feels like a very weird form of segregation to me. "You're a girl, you'll learn cooking!" "You're a C# developer, you'll write the database interface!". Why couldn't the girl weld a bike frame and the C# developer write a Blazor UI?
  - mrtksn 4y ago
    The house analogy is wrong, we are not talking about using different tech for different apps but different tech for different parts of the system. Therefore, the house analogy would be using different materials for the floors, for the roof, for plumbing and electricity. Then you will notice that different experts install all these parts. The plumber wouldn't do the electricity. It's not that it's impossible to know plumbing and electrical systems at the same time but it's much easier when you are plumber or electrician instead of trying to be a jack of all trades.

by jhgb 4y ago

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).

thiwaw93949500g 4y ago

The point of the person you are replying to is very clear so I am not sure why you insist on arguing. > Not sure what prevents you from doing that. The technology stacks used on the back-end, front-end, mobile apps, and their associated tooling are most of the time very different. Most developers aren't polyglot, or at the very least have a preferred ecosystem in which they are the most productive. By introducing physical boundaries, specialization is easier. For example instead of having a team only composed of Java developer, and having a development workflow and build process requiring Java knowledge, the back-end team may be composed of Java specialists, while the front-end is composed of nodejs + typescript folks, and the mobile app is composed of iOS or Kotlin experts. Is there a technical limitation preventing people from using typescript in a Java project and separating concerns using the java module system or basic folder hierarchy? No. However this rarely happens in practice unless there is clear physical boundary such as the one enabled by SPAs, because people specialize themselves.

jhgb 4y ago
> The technology stacks used on the back-end, front-end, mobile apps, and their associated tooling are most of the time very different. Which feels like a major mistake to me. My house doesn't use different construction technologies for different rooms. It was built all at once, why would it have one room built of bricks and another one from glass and steel? (Other than for some artistic reason, I imagine...) > Most developers aren't polyglot, or at the very least have a preferred ecosystem in which they are the most productive. Yeah, sure. But you don't need to artificially exclude the situation where for example everyone on the team speaks C# (like with the emerging Blazor projects). To say that different developers on a project often have different preferred ecosystems does not mean that different developers on a project must have different preferred ecosystems, even if they're working on different parts of the same project. That feels like a very weird form of segregation to me. "You're a girl, you'll learn cooking!" "You're a C# developer, you'll write the database interface!". Why couldn't the girl weld a bike frame and the C# developer write a Blazor UI?
- mrtksn 4y ago
  The house analogy is wrong, we are not talking about using different tech for different apps but different tech for different parts of the system. Therefore, the house analogy would be using different materials for the floors, for the roof, for plumbing and electricity. Then you will notice that different experts install all these parts. The plumber wouldn't do the electricity. It's not that it's impossible to know plumbing and electrical systems at the same time but it's much easier when you are plumber or electrician instead of trying to be a jack of all trades.