Boris Smus wrote a post about Backbone and Ember. Which is related to a podcast on Javascript Jabber. Which talks about:
Ember and Backbone are both promising JavaScript frameworks but have completely different philosophies. In this post, I’ll compare the two, both from a practical and philosophical perspective.
I post a reply there, and I copy the content here. I’m thinking the variations on javascript MVC recently, but I didn’t get the answer yet.
Bi-directional data binding and the view-model idea is fancy, but it still sounds like a overkill. The MVC has lots of variations, the presenter style (as Martin Fowler defined) is really good for complicated single page applications, when the state of application is hard to maintain.
Event driven UI should not bound to framework level, it should integrate into developer’s brain. So you do have the freedom to composite your whole UI in backbone by loose-coupled event protocol.
Scale the application has nothing to do with MVC framework, guess how a framework fits a project scale is not smart. I think which interaction style you choose is a key factor. When we want a sophisticated Desktop like web app we may prefer Ember’s style, that solves it in smart way. But for a Web like web app, backbone.js is enough, we should keep our own code as simple as backbone.js.
Work with a micro framework like Backbone, we can enjoy the refactory to patterns process. Since we own the flexibility, that’s awesome. I think the most dangerous result of adopting patterns is that you will not evaluate the value and trade-off of adopting patterns. YAGNI make sense here.