This article was last updated January 14, 2012. Since then, a number of real-time JavaScript frameworks have been released, like Meteor, Derby, and Firebase. You can't have a complete picture of the JS framework landscape without these newcomers.
It's pretty weird that this piece goes over 12 frameworks and barely describes its declared winner, or the reasons why it's declared Ember.js the winner.
This is common with people that don't know anything else. So they build biased metrics to put one framework in the spotlight and satisfy their want for using the framework vs learning more about others or building the knowledge to roll their own.
Sure, use a framework, let's not reinvent the wheel. But my biggest peev is when I look at a project with every framework imaginable, using a small portion of it's functionality. I guess this is where the "plays nicely with others" metric is important for these individuals. "It doesn't matter if we load 10 frameworks in the DOM as long as everything works" -Retarded Developer
Used this article before and he completely misrepresents SpineJS. Asynchronous UIs do not need an algorithm such as operation transform (the technology behind Google Wave). OT is about collaboration in a federated network. SpineJS does not, in a typical case, deal with such scenarios and thus the asynchronous UI can and is handled by a simple queuing system.
The categories here are vague, without much explanation of what they mean or how they were evaluated. For example, I would argue that Backbone has both "UI Bindings" and "Composed Views", and in fact wouldn't be very useful otherwise.
The criticism of AngularJS is a little vague to me - "codebase appears to be fairly sprawling and not very modular. Views are not modular enough (will address this in more detail in the cons of Batman.js)." I'm not sure how it isn't "modular" or how views/components aren't reusable.
AngularJS is possibly best-of-breed in the engineering aspect in my unqualified opinion, and I expect to properly use and deploy it once its documentation and cookbook are fully beefed up.
So what performance issues were encountered when converting backbone.js to ember.js? Why isn't that an important factor? How difficult is it to overcome the inherit drawbacks of a simple framework?
I'd say personally that behind simplicity, performance is the most important factor for an app (JS-enhanced sites may benefit far less). The challenges that I've seen while using backbone mostly consist of unifying the views, models, collections, and helper objects (or for lack of a better term "Services") together. So far some of that overhead involves adding a "_super" function and abstracting out instantiation so that it is sane. I'll write up about the experience afterwards, but backbone.js is a pleasant treat after leaving JMVC.
The views in Batman is the only reason I am using it.
I advocate logic-less views.
Edit; will probably move over to http://guides.joosy.ws/ as it's better documented and isn't broken like Batman.js
I can't believe in this day and age, master branches are undocumented and broken. Seriously, if you're pushing code to Master, at least have it documented. If not, let it be in dev branch.
http://meteor.com/ http://derbyjs.com/ http://firebase.com/