09 February 2013

The rise of front-end MV* frameworks

Since I first started hearing about client-side MV* frameworks, I’d been a bit weary and not entirely convinced of their role in web application development. I’d always thought ‘why it just let the server serve html like it’s good at?’ My opinion quickly changed, however, after using Backbone.js in a Real Life™ project.

Firstly, what are these MV* Frameworks? and why the* ?

MV patterns are architectural patterns used in software engineering. The most common MV pattern is MVC (Model, View, Controller) from which MVVM and MVP are derived (Model, View, ViewModel) and (Model, View, Presenter). These patterns allow developers to separate out concerns within their code into three distinct parts.

The Model: Models represent the specific data being stored in the application and notifies its observers when it has changed. A model is usually a type of thing that can be modelled - eg. a Note or an Event.

The View: The view is, more often than not, what the user will see or the outer face of your application such as a UI or a JSON response.

The Controller: Controllers handle and direct the input passed to it from the view. If an action from the controller has acted upon and changed something in the model layer, it is up to the model to tell the view that something has changed.

The ViewModel: As the name suggests, the ViewModel is a model of the view layer. It is an abstraction of the view and sits between the model and view acting as a semi-controller as it translates view actions and passes them to the model and vice versa.

The Presenter: A presenter’s role is to act as a layer between the view and model, similar to the ViewModel but different in practice. It retrieves data from the model to display in the view. Presenters usually abstract complex logic out of the view and into a method that is called in the view. For example rather than checking if your user has a profile picture (and using conditional logic in the view) you could write a method that did the check for you in the presenter layer and returned the user’s profile picture if they have one, or a default picture if they do not.

But, of course there’s an exception to the rule. Backbone.js includes the the controller within the ‘view’ layer which can be a bit confusing at first. It also splits up the model into ‘model’ and ‘collection’. A collection is just many of the model’s objects. So if you were modelling an Event, a collection would be an object containing many Events.

But how is this going to help me?

Firstly, I’d like to note that using a client-side framework may not always be the best approach to application development. But if you find that your UIs have complex interactions or you’re performing a whole bunch of AJAX with jQuery and showing and hiding content, you may want to consider a client-side framework.

Using a client-side framework will also free up the data being received from the server allowing you to respond with more generic JSON and then use a client side templating language (such as mustache) to structure that response, throwing away any un-needed data for that particular view rather than having multiple response templates for each view.

One of the most common examples of a well implemented single page application is GMail. Rich in complex UI interactions and rarely reloading the interface, it will download all the assets needed (.js, .css) in one go, only ever going back to the server for data, not UI templates.

The benefit lies in having a completely separate client side layer that only needs a backing API to function and with the emergence of technologies like localStorage, webSQL and the FileSystem API, some clever engineering can make your application even less reliant on a server by falling back to local data when a network connection is not present and then re-syncing with the server when a connection is established.

All in all, if your next project may be better off implemented with client side code or if you’ve thought about playing with a framework like backbone, angular or ember, but been a bit on the fence about the whole thing there are definitely advantages to front-end frameworks in certain circumstances that can sometimes be better than a hybrid client/server implementation.

If you do decide to give client side MVC a go, but don’t know which framework to start with, have a look at TodoMCV to get a breakdown of the pros/cons and features of each framework.