Purpose of Javascript MVC frameworks [closed]

Answer 1

JavaScript MVC frameworks like Backbone.js are for adding structure to your front-end.

This is most useful when building [increasingly popular] single-page JavaScript apps (SPJA). If you're heavily using unobtrusive JavaScript, you're probably doing a fair amount of ajax for dynamic content to avoid refreshing the page on the user. SPJA's take this a step further by letting the user visit all areas of an app without ever refreshing the page. Without the structure provided by MVC frameworks, the client-side code can quickly get out of control.

Answer 2

The same as on any other tie, one needs for JavaScript code: * Abstractions (separation of concerns) * Implicit conventions and consistance * Code reusability

You can get it with Vanilla JS of course, but will have to write a sort of a framework by yourself. So you rather take an existing well-known and proven solution.

These are core requirements, any other depends on how much you allow the framework to restrict your development process.

Answer 3

Having a dual MVC is absolutely redundant if your web frontend is simply the presentational layer ie. a view and all your data as well as application logic resides on the server.

However many of the modern complex web apps try to maximize the user experience by creating highly interactive frontends that dynamically communicate with the server using Ajax or similar alternatives eg. Flash AMF. In such cases in the fontend of your application, separating out the script portions that handle actual communication with server, providing proper provisions for managing the local data that has been fetched/cached in the client's system, user interaction event handling and history management. Once you begin to think about it, it quickly becomes apparent that having a separate MVC layer in the javascript code is a good idea because it fits well with the scenario and makes the code manageable.

For instance, in an application like Facebook a user interaction event like pressing L when a picture is enlarged, or clicking on the Like button actually map to the same action and therefore this action should be decoupled from the part that constructs the view and attaches event handlers. Actual sending the updated metadata information to the server can be again separated out because this portion can be re-utilized for any action that updates the metadata which needs to be communicated back to the server. Similarly validation of metadata is reusable across different user actions which update the metadata.

Through this example I hope to have communicated the concept of how MVC design fits in with web frontends.

Answer 4

I think the framework is more towards building complex JS apps. Using ajax to update/save. For example, MVC framework would make it easier to build a js Calculator app. Just my 2cent.

Answer 5

Ever wear a suit to an interview? Same thing.

Nobdy's going to pay a front end developer $95K/year if they think he's coding stuff like this all day long:

form1.user_name.value = 'John Doe';
form1.user_name.onclick = function() { form1.user_name.value = ''; }

But if you start flapping your gums about MVC, node, Angular, backbone, AJAX, RESTful, or JSON...they think you're at the forefront of Computer Science.

It's the same with PHP frameworks. Any CRUD app coder earning $40K/year can write this all day long:

$user_name = trim(strtolower($user_name));
echo 'Your name: ' . $user_name . '<br/>';

But if you start mentioning MVC, Yii, Laravel, Symfony, or Zend...it's like putting on a tweed jacket with patches on the elbows and holding a coffee cup that says "Professor of the Year".

Answer 6

Some application architects only want data-layer functionality in the server with a thin web services interface. In such a situation, it is useful to have the MVC architecture in the client.

At the end of the day, it depends where you want to put your controller and view functionality. If you want it all in the server use Rails without any AJAX. Having a model layer in the server lets you encode complex relationships, views, and validation in the server. It lets your controller respond to different data formats (e.g. xml, html, json). And it lets you use ERB or HAML to control the views.

However in many situations, you may want to offload processing to the client. In such a case, you may want to move view processing to the client (such as with AJAX). Or you may want to have the client determine whether to render html, xhtml, html5, or whatever. Or you may want to use some local storage to cache data in the client. Or you may want to do data validation and view composition in the browser.

Some application architects only want data-layer functionality in the server with a thin web services interface. In such a situation, it is useful to have the MVC architecture in the client is prudent because you'll eventually have to deal with model-layer issues such as validation, complex views, data filtering, controller-layer issues such as view formatting decisions, and view-layer issues such as layout, rendering, and styling.