The Shift Towards Client-Side MVC
The Web Dev Zone is brought to you in partnership with Mendix. Discover how IT departments looking for ways to keep up with demand for business apps has caused a new breed of developers to surface - the Rapid Application Developer.
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.
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.