This is very nice. I had to pick an MVC framework for a project early this year, and was compelled to spend untold amounts of time to do the same research this author just posted.
Another good resource for choosing a framework is TodoMVC (http://todomvc.com/). It doesn't give you the philosophy and history behind each framework, but it does show you an end-to-end example (however constrained) of what it's like to use the framework in day-to-day work.
As a developer, deciding on a [framework|library|language] is one of my least favorite things to do. Naturally I want to make the right long-term decision based on my idiosyncratic needs, which results in countless hours of research, so I really appreciate posts like these. Huge time saver.
This was quite helpful in outlining the differences between the options as well as the key differences in specific features. I also like the philosophy approach.
As an aside, some have argued (see previous Angular / Ember deck posted to HN) that Angular is something for building frameworks rather than a framework itself. I would also say that the documentation for Angular is comprehensive but not good (as a newbie). With the version change to 1.2 a number of issues crop up that invalidate old solutions like $sce content escaping and other bindings, and often times the documentation on the AngularJS site goes a bit beyond comprehension that have yet to pass the appropriate "abstracto-cline" of understanding.
A lot of people I hear say they don't choose backbone because of the amount of stuff you have to write to get started, but they never mention backbone+marionette, which imo fixes a lot of the boilerplate code you have to write.
We've been using Backbone+Marionette at my company, and in general I like it, and it's much cleaner than just vanilla Backbone, but I still feel like it falls short for medium-to-large sized apps, and requires you to write a substantial amount of additional code, or include additional Backbone plugins. This might include things like "nested/deep" model support, two-way data-binding, etc. The main problem with the lightweight plugin model is that a lot of the plugins aren't necessarily compatible with others, or are not up-to-date on the latest Backbone changes, not to mention the varying degree in quality and maintenance of plugins, and the problem of choosing which data binding plugin you want, out of the 10+ available.
I think maybe we have just crossed the line from small, focused UI/interactions to large-scale single-page apps, and we would be better off with a more substantial/fully-featured framework like AngularJS or Ember.js.
http://chaplinjs.org/ is also another great full featured framework on top of Backbone. Vanilla Backbone is more of a framework starter kit. I don't think it makes sense to compare it directly to frameworks like Ember or Angular.
Yeah, the author addresses some of this in the "Apples to Apples" section but doesn't get into details. I'd be interested to see which combination of smaller packages works well to achieve similar capabilities.
I'll definitely do a future post on this topic. I've been thinking about doing it with the analogy of a food/wine pairing and going into which server side frameworks play well with client side frameworks in addition to the client side libraries that work well together. For example, emberjs and rails or knockout, sammyjs, durandaljs and .net web api on the server etc...
This was just what I was looking for. We are researching various MVC frameworks and discussing single page applications. This will give us some good insight on weather we use Angular, Backbone, or other frameworks. Great job!
Another good resource for choosing a framework is TodoMVC (http://todomvc.com/). It doesn't give you the philosophy and history behind each framework, but it does show you an end-to-end example (however constrained) of what it's like to use the framework in day-to-day work.