> SPA makes the backend much more simpler as all the HTML rendering is not its concern anymore.
That feels like creative accounting of code to me. Is the rendering really simpler, or does it merely happen in a different place?
That feels like creative accounting of code to me. Is the rendering really simpler, or does it merely happen in a different place?
Also makes it possible to separate the people who build the API and the people who build the UI which can have many advantages such as hiring more specialised people and decouple the releases. For example, you no longer need someone who knows PHP/SQL/Linux and JS/HTML/CSS. You also have less vendor lock-ins because the front end and the back end are agnostic to each other, which means you can much easily ditch something from the one side without doing any work on the other side.
Drawing a circle artificially around a portion of your code and saying "look, now the circled part doesn't need to change!" feels like creative accounting to me as well. If you have multiple clients, the code for multiple clients still has to live somewhere, so it's not like the whole system that you need to build is getting simpler.
Pretty much the only actual difference I can see here is the ability to use more of client's CPU time to run your applications. I'm sure there's applications that could profit from that.
> For example, you no longer need someone who knows PHP/SQL/Linux and JS/HTML/CSS.
But if you don't do your logic in JS but do it in PHP on the server, you don't need a JS person. And if you were using Seaside, you wouldn't need an HTML/CSS person since everything would be just Smalltalk at that point. It's again just moving stuff around, but someone still has to do that.
I guess one situation where this argument might apply would be if one of the two language options was difficult to hire for.
> You also have less vendor lock-ins because the front end and the back end are agnostic to each other, which means you can much easily ditch something from the one side without doing any work on the other side.
Not even this argument seems any less artificial to me, since if you're ditching something, I'm not quite sure why it matters where you ditch it from -- unless you have no control over one of the sides. In that particular case, I could see this as an argument. If you're forced to do a client for an already existing server, you're obviously justified in doing a pure client-side solution for anything that doesn't exist on the server yet. If you're building your own server, this limitation is removed.
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.
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.
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?
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.
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?
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).
That's SPA fetching HTML instead of JSON or something. You are welcome.
> 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 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.
> 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.
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?
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.
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...
I’d argue it makes it more flexible, but not easier. It’s so much easier rendering html serverside than having it all done separately in React.
> Also makes it possible to separate the people who build the API and the people who build the UI which can have many advantages such as hiring more specialised people and decouple the releases
You now also have to worry about versioning and/or coordinating releases. Mobile clients demanding a different set of APIs than web client. use graphql? Rest?
> front end and the back end are agnostic to each other
This is good in theory but in practice when you have to replatform the backend for example, it is often for reasons such as separating out concerns, refactoring, rewrites, or moving the frontend over to a new system etc and that usually ends up with the frontend needing to change as well. The frontend is coupled with the API contract that the backend provides and is not entirely agnostic to each other.
This is pretty similar in nature to monoliths vs microservices where monoliths are by far a simpler architecture.
Rendering on the server-side requires transfer of state, so you know the context. For example did you expand the 3rd expander or not?