4 ms·

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

by jhgb 4y ago

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

mrtksn 4y ago
Happening in a different place makes it simpler because the backend no longer needs to take into consideration the various clients. For example, the same API can serve a SPA and a Mobile app and some other interactions with other systems(integrations with multiple services becomes so easy). 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.
- jhgb 4y ago
  > the backend no longer needs to take into consideration the various clients. For example, the same API can serve a SPA and a Mobile app and some other interactions with other systems(integrations with multiple services becomes so easy). 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.
  - 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.
- hw 4y ago
  > Happening in a different place makes it simpler because the backend no longer needs to take into consideration the various clients 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.
hombre_fatal 4y ago
Well, they did say it made the server code simpler, not server+client code.
quickthrower2 4y ago
It happens in one place, where state can just be a JavaScript object, which is what makes it simpler. Rendering on the server-side requires transfer of state, so you know the context. For example did you expand the 3rd expander or not?
- deleted 4y ago
  [deleted]

by jhgb 4y ago

mrtksn 4y ago

Happening in a different place makes it simpler because the backend no longer needs to take into consideration the various clients. For example, the same API can serve a SPA and a Mobile app and some other interactions with other systems(integrations with multiple services becomes so easy). 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.

jhgb 4y ago
> the backend no longer needs to take into consideration the various clients. For example, the same API can serve a SPA and a Mobile app and some other interactions with other systems(integrations with multiple services becomes so easy). 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.
- 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.
hw 4y ago
> Happening in a different place makes it simpler because the backend no longer needs to take into consideration the various clients 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.

hombre_fatal 4y ago

Well, they did say it made the server code simpler, not server+client code.

quickthrower2 4y ago

It happens in one place, where state can just be a JavaScript object, which is what makes it simpler. Rendering on the server-side requires transfer of state, so you know the context. For example did you expand the 3rd expander or not?

deleted 4y ago
[deleted]