Here is a breakdown of the alternate technologies in the Client-Side MVC space. What I’m showing, in graph form, is “lines of code” analysis of the well-known reference Todo list app implemented in each of the competing technologies:

The left-to-right order of the frameworks is based on the count JavaScript lines (or CoffeeScript or some other type of functional/procedural ‘source’). That’s the blue bar. The stacked red bar, is the HTML (including template code that’s in HTML style) for the same reference implementation. The left-most bar is for ‘plain HTML’ (no functionality, no JavaScript). It is actually one Todo less than the ‘template’ example on TodoMVC My version is actually a snapshot of one of the “Vanilla-JS” one running, and saved back to HTML. That shows the smallest amount of HTML needed to craft a Todo list with one item in it.

The Vanilla-JS one (half way from left to right), is how to do a functioning app with a pure JavaScript. Ones to the left of that, are less JavaScript than the pure-JavaScript application. They perhaps prove the worth of the framework. Ones to the right, are more JavaScript, and there are most likely other reasons for using them beyond “lines of code”.

Breaking the examples down into groups.

Turing-Complete HTML

In order of terseness, all of Batman, AngularJs, Knockout, Olives, o_O, Dermis, Agility, Knockback and Montage all extend HTML with turing-completeness. That is the equivalent of if/else conditionals, and looping structures. The HTML is non-standard as a result, and is it’s own template. Batman, AngularJs, Knockout are the ones with recognition.

None of that kicks in without JavaScript turned on, and the framework loaded. Some say this “pollutes HTML”. Others complain that it’s logic that can’t be tested easily. Here are the two general styles:

<ul id="todo-list">
    <li some_extra_attribute="some looping expression">
        <!-- # more HTML logic incl template stuff. -->
<ul id="todo-list" some_extra_attribute="some looping expression that's about the 'li' inner...">
        <!-- more HTML logic incl template stuff. -->

This group is my preference.

In one case, the templating is in the HTML, but there’s no directives around turing completeness.

Part HTML, part separate ‘html’ template

There are large communities around Backbone, Ember, and Spine, YUI. Larger communities than for the turing-complete HTML ones above. Backbone is half way up the terseness leader-board (as you can see). Lesser known are the others in the space are Sammy, SocketStream, Staples, SomaJS, Epitome, Dijon, Plastronic, TroopJS, Google’s Closure, PureMVC. Those last, in terseness order again of course.

This group has templates hived off into script tags …

<script type="text/x-handlebars">
   // template stuff here, incl HTML and turing-complete logic
<script type="text/x-handlebars-template">
  // template stuff here, incl HTML and turing-complete logic
<script type="text/template">
  // template stuff here, incl HTML and turing-complete logic

… or totally separate .html files. Thus they do not “pollute HTML”. It also means that the though that would repeat, or would be conditional is missing from the intended ‘place’ in the source code (or the DOM depending on your point of view).

Reminiscent of HTML, but not HTML ‘source’

Meteor cross compiles to an extensive minified JavaScript thing that completely builds out the DOM. The HTML source, honors some of the HTML tags, but does not contain <HTML> and <BODY> tags etc. CanJS Similarly uses a template technology that is reminiscent of HTML - Mustache.

Dart is either in this category, or the last one. At least, I say that after inspecting the TodoMVC example source. There’s a HTML page that contains the ‘outer’ application, but Dart is composing HTML fragments for Todos in code and injecting them where appropriate. Sure the language is easy to read, but it is questionable to tape strings together to make HTML in procedural code.

Any technologies I didn’t mention in the first two categories, are in here (except GWT, which is it’s own thing).

Even better if …


Addy Osmani’s and Sindre Sorhus’s TodoMVC site is fantastic. It allows people who care to compare implementations. It could be better though - branches for each implementation, with greater consistency between examples. Also, I’m not sure how much patronage it gets from the makers of each framework. Is each example canonical? Are they all exactly the same functionality.

Server Interaction

There’s also the question of server side interaction. All but a couple of these example apps have no server-side persistence. A GET of the Todo-list and PUT/POST of it going back to the server for posterity, would help complete the terse/elegant vs. verbose/confusing picture for people wanting to make a choice.

Method and Accuracy

There’s a couple of shell scripts in the root of There could also be different functionality or idiomatic correctness for each of the frameworks. Thus Batman vs Angular (the left-most two frameworks), or any others, could change position were the experts to review the source, and contribute to the TodoMVC project on GitHub.


Jan 18, 2013: This article was syndicated by DZone

Jan 19, 2013: JavaScript line counts for PlastronJS and Duel are too high in the graph above - sorry!

Sep 1, 2014: Colleague Pete Hodgson is pushing TodoMVC into the compare backends territory. Refer “Even Better If / Server Interaction” above.


January 18th, 2013