4 ms·

> But these days we have an entire front-end ecosystem of controllers, components, events, models, callbacks etc. with many of the above including numerous life

> But these days we have an entire front-end ecosystem of controllers, components, events, models, callbacks etc. with many of the above including numerous life-cycle states and actions themselves. Can you be more specific? Because to me this looks like essential complexity that's going to exist somewhere, regardless of what's on the client and what's on the server.

kingdomcome50 9y ago
While you are absolutely correct that many of the "pieces" of an application I list above are going to have to exist somewhere, "Essential complexity" is a loaded statement here. There are different contexts and use-cases for complexity. A traditional 3(or 4)-layer MVC web application will obviously contain quite a bit of complexity surrounding data persistence/access, enforcing business rules, and view semantics, but it likely won't have much complexity surrounding "adding an item to a list" on the client. In fact, up until the last 10 years or so, my simple example of how that might look in JS is probably how that would have been implemented on a client (a full page reload is a moot point here). With a SPA, we are adding another MVC (or MVVM) application on the client that is entirely focused on managing the view. That is the complexity to which I'm referring in the point I made above. I named it a "front-end ecosystem" as to not be opinionated on how it might work. I'm certainly not arguing against developing SPAs, rather, adding some context surrounding the OP about how/why bugs develop. To reiterate, I think it's an oversimplification to simply hand-wave the OPs example bug as sloppy engineering that has nothing to do with creating a SPA, because doing so glosses over "why" that bug may be occurring in the first place. The point that I am trying to make is that it may very well be the case that such a bug is occurring because of the added complexity an SPA tends to introduce into the view. Does that make sense?
- deleted 9y ago
  [deleted]
- brucephillips 9y ago
  It's a bit misleading to say we're adding another MVC app on the client. By adding that complexity, we reduce complexity on the backend. Views on the backend are no longer true views, but rather serializations of the models. And models on the frontend don't duplicate business logic. That's still all on the backend.
  - UweSchmidt 9y ago
    The real complexity is in the front-end frameworks like Angular and React. Sorry, someone had to spell it out. When you learn these frameworks you have to wrap your head around a lot of concepts that make the browser behave like a desktop application. And you may find yourself trying to do things that your framework doesn't like early in your project. Compared to that dealing with business logic or a straightforward server side MVC might be trivial in many projects.
    - brucephillips 9y ago
      I don't know Angular too well, but React is really just a templating system. It doesn't add much more complexity than any templating system, including those you would necessarily have on the backend in a multi-page app.
      - mattmanser 9y ago
        I didn't really get a chance to reply yesterday but u/kingdomcome50 perfectly expressed my thinking. While you think it's not more complex, I've done plenty of things like toggl's "add extra time" buttons many times outside of SPAs, but saved by a form POST. They worked flawlessly and never broke. Because you have to insert the "update the database ajax, [then refresh data]" step, which is abstracted away inside react/redux or angular or whatever, it suddenly becomes very hard to be in total control of what's going on. You say you've abstracted away MVC on the server, but you haven't really, the server is still there and it's still complex, it still has to run validation and business rules, etc. and it's still MVC, the view just happens to be a json object instead of a html page. You're still going to be stripping stuff off the object for security reasons or for performance reasons, so you still need an intermediate model. And worse you now have to decide, do I add all those business rules and validation to the client too so I can make it super-responsive, or do I rely on my server to enforce all this, but then after every update I have to refresh the data, adding a potentially 500ms+ delay to the UI that is well in the realms of human detection (which is what happens in the Toggl case).
jtolmar 9y ago
Using the traditional approach on a pure CRUD app, your server transforms form inputs to inserts, page requests to queries, and query results to HTML. Each of these transforms can be pure functions, and all the state updates can be handled by a boring database. With pure functional components being one of the few ways to make code actually less complex, and handing things off to boring libraries being another.
- brucephillips 9y ago
  Almost all of this is true with single page apps, though. The only added complexity is you have to maintain a frontend state cache (e.g. Redux).

kingdomcome50 9y ago

While you are absolutely correct that many of the "pieces" of an application I list above are going to have to exist somewhere, "Essential complexity" is a loaded statement here. There are different contexts and use-cases for complexity. A traditional 3(or 4)-layer MVC web application will obviously contain quite a bit of complexity surrounding data persistence/access, enforcing business rules, and view semantics, but it likely won't have much complexity surrounding "adding an item to a list" on the client. In fact, up until the last 10 years or so, my simple example of how that might look in JS is probably how that would have been implemented on a client (a full page reload is a moot point here). With a SPA, we are adding another MVC (or MVVM) application on the client that is entirely focused on managing the view. That is the complexity to which I'm referring in the point I made above. I named it a "front-end ecosystem" as to not be opinionated on how it might work. I'm certainly not arguing against developing SPAs, rather, adding some context surrounding the OP about how/why bugs develop. To reiterate, I think it's an oversimplification to simply hand-wave the OPs example bug as sloppy engineering that has nothing to do with creating a SPA, because doing so glosses over "why" that bug may be occurring in the first place. The point that I am trying to make is that it may very well be the case that such a bug is occurring because of the added complexity an SPA tends to introduce into the view. Does that make sense?

deleted 9y ago
[deleted]
brucephillips 9y ago
It's a bit misleading to say we're adding another MVC app on the client. By adding that complexity, we reduce complexity on the backend. Views on the backend are no longer true views, but rather serializations of the models. And models on the frontend don't duplicate business logic. That's still all on the backend.
- UweSchmidt 9y ago
  The real complexity is in the front-end frameworks like Angular and React. Sorry, someone had to spell it out. When you learn these frameworks you have to wrap your head around a lot of concepts that make the browser behave like a desktop application. And you may find yourself trying to do things that your framework doesn't like early in your project. Compared to that dealing with business logic or a straightforward server side MVC might be trivial in many projects.
  - brucephillips 9y ago
    I don't know Angular too well, but React is really just a templating system. It doesn't add much more complexity than any templating system, including those you would necessarily have on the backend in a multi-page app.
    - mattmanser 9y ago
      I didn't really get a chance to reply yesterday but u/kingdomcome50 perfectly expressed my thinking. While you think it's not more complex, I've done plenty of things like toggl's "add extra time" buttons many times outside of SPAs, but saved by a form POST. They worked flawlessly and never broke. Because you have to insert the "update the database ajax, [then refresh data]" step, which is abstracted away inside react/redux or angular or whatever, it suddenly becomes very hard to be in total control of what's going on. You say you've abstracted away MVC on the server, but you haven't really, the server is still there and it's still complex, it still has to run validation and business rules, etc. and it's still MVC, the view just happens to be a json object instead of a html page. You're still going to be stripping stuff off the object for security reasons or for performance reasons, so you still need an intermediate model. And worse you now have to decide, do I add all those business rules and validation to the client too so I can make it super-responsive, or do I rely on my server to enforce all this, but then after every update I have to refresh the data, adding a potentially 500ms+ delay to the UI that is well in the realms of human detection (which is what happens in the Toggl case).

jtolmar 9y ago

Using the traditional approach on a pure CRUD app, your server transforms form inputs to inserts, page requests to queries, and query results to HTML. Each of these transforms can be pure functions, and all the state updates can be handled by a boring database. With pure functional components being one of the few ways to make code actually less complex, and handing things off to boring libraries being another.

brucephillips 9y ago
Almost all of this is true with single page apps, though. The only added complexity is you have to maintain a frontend state cache (e.g. Redux).