Javascript MV* frameworks

Building a web application today isn’t nearly as hard as it was couple of years ago. Back then creating a rich client application using HTML and JS was possible but the number of options you had is a fraction of what is available today. The first SPA I helped building was relatively simple project –built with ExtJs library when it was still in version 2. There were of course other options like dojo but with our team’s little experience in web technology ExtJs seemed like a better choice solely because of its superior support. Shortly after I worked on another web application built with Web Forms and jQuery.  We finished both projects, they worked on most browsers but we didn’t avoid creating a mess in JavaScript. Presentation logic was mixed with business rules scattered through event handlers inside unstructured components source code. Just to be fair it definitely was not caused by the frameworks we used but because of our lack of knowledge and experience. 
I guess that happened to lots of developers and wise people soon enough realized that there has to be a better way of doing things. I think that this was the main reason of the explosion of JS libraries/frameworks options that aim to help structuring client side code.

MVC, MVP, MVVM or …

The number of libraries and frameworks available is overwhelming. AngularJS, Backbone.js, Ember, JavaScriptMVC, Knockout or Sammy.js are just a few I had a chance to look at from the outstanding list. You can even compare how to built simple TODO application with them. Addy Osmani wrote an excellent article that really helps making your choice sane. Most if not all of those frameworks utilize one or more of MV* patterns. An important thing to remember though is that Model View Controller is more an architectural pattern for presentation than an code design pattern like Builder. It means it does not provide very concrete implementation template but rather a guidance for objects/modules/roles relationships.
Similar observations apply to MVC cousins namely Model View ViewModel or Presentation Model and Model View Presenter. This can cause some confusion for someone already familiar with MVC pattern in Asp.net mvc, Fubu or Rails. I always try to find a framework/library author’s explanation of how they applied above patterns – it really helps understanding core concepts of their work.

Library or Framework

Some of the tools are called frameworks while other libraries. But what’s the difference anyway? A very common and brief explanation is the one provided by Martin Fowler inside Inversion of Control article:

Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.
A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.There are various ways you can plug your code in to be called.

Of course the distinction is not always firm and clear. Still, it is important to keep in mind while choosing the right tool for a job. A library will usually give you more control inside infrastructure code but it often requires more work to unify boilerplate gluing code and requires some degree of experience. A framework on the other hand will typically provide you with a setup where you can hook your code hopefully focused mostly on the valuable functional stuff. A framework will limit your freedom to some extent in turn it will eliminate some part of work that you presumably would have to do in order to keep your design clean.

Productivity

For me the biggest advantage of using a modern MV* JavaScript framework is productivity. After some time I realized that the amount of boring, repetitive code focused only on filling DOM with data and giving it behaviour is substantial. Sure I am able to separate presentation concerns rather cleanly without aid from any tool. However what’s the point if so many great libraries and frameworks, created by way more experienced people, is out there. It gets even more valid point when working on a big project. Even if all the team members are experienced and closely collaborating it will be hard to have and maintain a common, well understood structure among different parts of JavaScript code base just because understanding and preferences about MVC and related patterns will vary.
In my next blog posts I’ll try to review 3 tools that caught my eye. Namely AngularJS, Backbone.js and Knockout that seem to be most popular these days. They all show some signs of maturity and have vibrant community around them. It will by no means be a comparison as they really are different beasts built with different goals in mind. The only comparison I may be tempted to do is about productivity. Still I already know it will not be comprehensive as there will be only one person working on the codebase and the micro product will be focused mostly on a rich data visualization – which is what I do mostly now.
Maybe it will help to the framework/library that we’ll use in our current project.