2 ms·

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

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

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