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.
It lets you code in Java, compile to a native SPA, and gain all the benefits you'd expect from a single, strongly-typed language top to bottom (refactoring, POJO reuse on the front end, etc.).
> 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?
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.
> 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.