What are the reasons I would need an MVC model on the browser client for a server based application?

Question

Assumptions:

• I have a banking app with a Java-style web server.
• The Client side is written in JS with backbone and some other plugins. (The developers are fans of Angular, but they're not using that).

My JavaScript developers have come to me and said "X is impossible because of the way we do the MVC in the browser."

Now I'm fine with an MVC on the server side, and we already have that. But when the JavaScript guys want to have an MVC on the client, then it feels like we're keeping state about the customer's experience in two different places. I think its simpler to keep in one place.

I'm familiar with the 'three tier' architectures of the 90s - with a database tier, a tier for transaction management, and another tier for customer interaction. We moved away from that because it was horrible.

I'm also familiar with running server side apps in Node.js. To me - it makes sense to have a server-side MVC in this scenario.

My question is: What are the reasons I would need an MVC model on the browser client for a server based application?

Answer 1

I don't get your comment about not keeping state on the client since you keep one on the server.

It's the difference between then-current Hotmail and Gmail. Gmail obviously was not implemented in AngularJs, but the forward-and-backward navigation, undo, etc... without a round-trip to the server is what one gets from keeping some relevant state on the client.

Both serve different purposes, in my mind. One facilitates user interaction. Another deals with persistent / protected state.

Answer 2

Seems like you are retreating to the good old days (not!) when every click required a round trip to the server to work. It somehow seems to contradict with the Ajax /REST model. It may suit for your application, specifically, but this model works pretty good for a lot of others.

As for your question: client MVC allows you to build rich UI applications with a code that can be maintained.

And jsut to add a quote from wikipedia: Early web MVC frameworks took a thin client approach that placed almost the entire model, view and controller logic on the server. In this approach, the client sends either hyperlink requests or form input to the controller and then receives a complete and updated web page (or other document) from the view; the model exists entirely on the server.[8] As client technologies have matured, frameworks such as AngularJS, Ember.js, JavaScriptMVC and Backbone have been created that allow the MVC components to execute partly on the client (see also AJAX).

Answer 3

I fought for a long time to avoid Javascript simply because it was not strongly typed. I've since retreated on that point because of the simple fact that Javascript is the most strong DOM language anywhere, plus it also has thousands of open source framweworks out there (just look at JQuery, or even Typescript).

Prior to the "everybody needs a browser" era, server side was king. I remember the era of dumb terminals. Since then, when we have mainframe like computing power on every desktop these days, and it makes sense to utilize client PC power. If we really look at MVC we see a controller which only does routing (doesn't really matter if it's client side does it?), The models are always going to be closest to the DB, but... these days client side data binding is king, and you need models the client can bind to. The model itself, then doesn't have to even be server side anymore and with protocols like JSON, it's simple to create dynamic models on client side, just parse the Name/Value pairs and show it. We see validation moving to client side (which makes sense for user input, but the client side can validate data from DB too just to show the user errors. This leads to client side state machines for the view. So what's left for the server to do? Answer: get things started, and get data and save data.

When we saw Silverlight and even Flash start tanking, it was because the RIA thing (Server side) era was being displaced by client side frameworks. HTML 5 hastened the death of server side RIA because now the browser can have persistent 2 way communications based on a standard. All of a sudden, moving much of MVC to the client makes sense. It's just that it's foreign to server side traditionalists, like myself (for now)...

You can see frameworks like Durandal, Angular, Knockout, Node and others are simply re-inventing MVC and Binding except this time it's client side. It's really a good time right now to learn this stuff because it's relatively new. It's only going to grow because all of the infrastructure is already in place. The new system we are targeting is no long a big huge server, but it is the exploitation of the big huge "Browser". We have to look at Web browsers a the new big huge system because they represent everything to the user and e-commerce. The more we know about manipulating and supplying the DOM the better off we are... Server side will always be there but it is no longer the center of the universe.

They predict that the popularity of mobile devices and the desire for more applications (client side) is so strong in the next 10 years that there will be shortage of developers to keep up the pace. For me that's reason for switching gears to client side.

Answer 4

Totally agree with New Dev answer.

In the server, you handle state in the form of current logged user, data, and so on.

In the client, your state will be the application state (which "page" or screen they're on, which is the currently selected item in a list, and so on).

Think of the server (if it's implemented using a REST API) as your database+authentication, and your client as a desktop app (the UI state is what you're handling). This way of thinking really helped me initially with Backbone. Translate your SELECT to a collection.fetch, INSERT/UPDATE to a model.save() and DELETE to a model.destroy(). In a SPA, your API is your database and your SQL is HTTP and JSON -and probably more, but it may help to think it that way.