Javascript application frameworks

Back in 2009, Avi Bryant said that Django is obsolete (He also said the the same thing about Rails in 2010).

His argument is that with the release by Google of Gmail in 2004 (which initially loads HTML and then it’s JSON all the way), and then of the V8 javascript VM in 2008 (which made it feasible to develop other applications in the same way), the old server-side MVC model died. In the future, web applications will be built like Gmail with essentially a single URL visible to the user and a backend that just sends structured data to the browser. As a consequence templates will die and so will controllers and the kind of routing model used by Rails.

Two or three years later and there is now an explosion of javascript application frameworks that are moving us in this direction.

So, which one do I go for?

There is a repository on Github that includes implementations of a simple todo app in dozens of different Javascript frameworks (I count 35). TodoMVC now has around 3,000 followers, which is more than all but a couple of the frameworks it features.

This is my shoddy and ill-informed summary of the implementations:

AngularJS. Has very readable HTML source, consisting of normal HTML tags with ng attributes, like ng-show, ng-click, ng-model ng-repeat and so on, and user-defined attributes (in this case, like todo-blur and todo-focus), which together determine behaviour (in other words, they do the data binding). The javascript is divided up into different files under folders that include controllers, directives, libs and services. I sort of prefer my javascript all in one place, but on larger projects this looks like it could keep things tidy. And the source of this application is very tidy indeed. Most of the application-specific code is in controllers/todoCtrl.js and there are only 40 or so lines of it. It’s all pretty obvious where the behaviour in the HTML attributes comes from and the code is very readable. I quite like it, as do some other people. AngularJS has been written by a team at Google.

Backbone.js. There is less going on in the HTML source. It is not very clear what is going on in the background. The source contains separate template markup. The JavaScript is split up into several folders. Most of the code is in views/app.js and views/todos.js . It’s readable code, but not as terse as AngularJS, nor is the connexion as clear between the markup and the behaviour of the application. For Backbone.js + RequireJS the template fragments are moved out of the HTML markup and into separate template files. Backbone has been around a little longer than most of the other frameworks, is more widely used and was developed as part of the DocumentCloud project by, among others, Jeremy Ashkenas, creator of CoffeeScript.

Ember. There is a wonderful simplicity to the Ember application. Just one HTML page and one app.js file. The HTML content is made up almost entirely of { {#view} } and { {#collection} } handlers with no embedded HTML markup at all (I expect Avi would approve). It is not quite as terse as AngularJS, but it is not far off. Very nice. Written by a team at Tilde, including Yehuda Katz of Merb and Ruby on Rails fame.

Spine. It’s CoffeeScript. And very neat, too. src/app.coffee, src/controllers/todos.coffee and src/models/todo.coffee are all short and readable. And some people prefer Spine over AngularJS. Written by Alex MacCaw to accompany his O’Reilly book on JavaScript web applications.

Knockout. Data binding is done in the HTML markup, rather like AngularJS, with data-bind attributes. Also, like Ember.js, the source is all contained in a single file. But with function calls like ko.bindingHandlers.hasfocus.init it gives the appearance of being a bit more low-level than some other frameworks, at least to a simple-minded amateur like me. On the other hand, someone recently commented that it’s quite similar to AngularJS and Ember, but feels more mature than either, and has great documentation. Written by Steven Sanderson at Microsoft.

Of the others, Dojo possibly asks too much of the developer, Closure looks like it requires a fair bit of development overhead, but as it is used for Gmail and other Google applications it is likely to be a good choice for serious applications (nothing I am likely to build, then). YUILibrary is not terribly readable. Knockback.js might have made sense if I liked the Knockout way of doing things, already used Backbone.js and wanted to develop in CoffeeScript. Agility.js looks simple and readable. Google Web Toolkit is Java: forget it. And jQuery on its own is actually not too verbose. It is still worth considering if I am not doing anything too fancy.

Finally, there are frameworks like Meteor, for full-stack development on both the client and server sides. Similar frameworks include Derby, SocketStream and Opa. Built on top of Node.js, one or other of these frameworks is likely to be the future of Web development for real-time, collaborative applications.

But for now, I have decided that I prefer HTML source that actually looks like HTML, I like the idea of implementing data bindings via tag attributes and I want to stick with JavaScript (at least for now), so I am going to have a play with AngularJS and see how I get on.