The Shift Towards Client-Side MVC

A change is happening in the enterprise application development industry.  It's a change away from logic on the server side, and towards logic on the client side.  Specifically, logic in JavaScript in web-applications.  I'm going to call out two alternate technologies that mean to minimize the actual JavaScript you write while still making highly capable web applications: AngularJS and Knockout.  There are incumbent choices like Backbone.js that have enjoyed a lead position in this niche, but there's enough of a difference between Backbone and the other two, to suggest that these are different technologies rather than simple alternates.

All are vying to own the "MVC in the browser" space.  Except perhaps that Microsoft-world technologies call it MVVM rather than MVC and it is slightly different.  MVC is Model-View-Controller and MVVM is Model-View-View-Model, but the acronyms are ubiquitous now.  The MVC design pattern was defined in 1979, and has influenced UI application construction from C++, through Java and .Net to the dynamic efficiencies of Ruby on Rails and Python's Django.  For over a decade it's been common to develop your MVC application using a framework on the server side. Choices were Struts, SpringMVC, Rails or 500 other frameworks.  These technologies are not going away (sadly in some cases), but they are to become more geared towards the serving of JSON (Java Script Object Notation) documents to the client app, and the receiving of them back again on change. They'll still do validation, even it its been done in the browser already because you can't ensure that it was done as the browser is an eminently hackable platform.  So you see it is a shift in where web-apps are coded - slightly away from the server and into the browser.

Knockout and Angular 'pollute' your HTML.

Just relax about that though and enjoy the functional and productivity benefits.

HTML shipped to the browser for Knockout to process is adorned with extra attributes data-bind principally.  For AngularJS its there's a range of attributes prefixed with ng- (ng-show, ng-repeat, etc) but its the same.   Both Angular and Knockout act as a bootstrap for the page. They'll intercept the page load, parse the the HTML and carry out the directives indicated by the extra attributes, and essentially repaint the page. All other HTML and CSS is identical to the vanilla solution.  That bootstrap process is so quick you'll not see it in practice.  Only in situations where the page load is incomplete in a major way, or when the network is inordinately slow, will you see them do their business slowly, or not repaint the page.

Backbone by contrast does not pollute the HTML with non-standard attributes.  This means in the same failing situations the page will paint but without data in it, and without the designed functionality.  You could consider that to be a fallback.  For enterprise application development, though, I'd not worry about it, as you've a greater understanding about the types of devices attached to the network as well as the generally available connection.  For main-stream public internet apps, perhaps these technologies are too advanced for now, given then range of devices, bandwidth and browsers.  That last is worth calling out that AngularJS is best on IE8 or above (plus anything from the last three years from the other browsers including mobile ones).  Knockout says IE6 and onwards, but must be best on IE8+ (and the others as above).

The downside of Backbone's approach is there's not visual co-location of functionality/affordances with placement within the ultimate UI. I call this "design mode", and its a side effect of Angular and Knockout. I blogged positively about design mode and have discussed it with ThoughtWorks colleagues - we all agree its a great aid to new developers acclimating to a new project, or old developers acclimating to new parts of a project. Indeed I had also made an small whac-a-mole app that shows the same feature running and blogged about it.

Knockout versus AngularJS

Knockout comes with a full resource tracking capability.  Items in a model, if changed, immediately trigger a library function that routes the change through to the view that may be associated with that node.  Similarly, changes in the view, are fully monitored and routed through to the model immediately. 

Angular is different. It does not have a resource tracking capability that's based on direct change-listening on nodes in the model or the view.
Instead it does 'dirty checking' at opportune moments aiming to be faster than a human-perceptable 50ms after the model or the view changed. It will propagate changes as appropriate. This means that model objects can be plain JavaScript and not have to inherit from classes in the framework. 50ms is smaller than humans can perceive.  In practice I've not been able to detect a delay, and when I wrote a blog entry on Selenium2 testing of these technologies including automated tests I could only detect a 3ms difference between Knockout and Angular.  Admittedly that was a small test app. 

Who's going to use this stuff?

I'm thinking that typical intranet web-application development is ready to be flipped to Knockout or Angular.  If you're a Microsoft shop, you'll use the former without hesitation.  If you're Java, Ruby or Python based you'll as likely use the latter.