Comment by mrtksn | Hacker News Reader

Comment by mrtksn | Hacker News Reader

Parent Full thread

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.

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

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?

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

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

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?

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

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

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

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?

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.

There's also nothing stopping teams from developing the front-end in Java too. Java SPAs have been possible for over five years using TeaVM:

https://teavm.org

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

There is a full intro article in Java Magazine:

https://blogs.oracle.com/javamagazine/post/java-in-the-brows...

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

Reply on news.ycombinator.com