Here is another story: I was working for a competitor of EditGrid and built a Microsoft Excel clone with dozens of features in 6 months, using no framework, no library, 5 years ago. We were two guys at frontend and two other guys in at backend. And our source code was almost pure object orient, mixable, reusable and relying on MVC, event-driven programming.
I've been shipping rich web apps for more than 6 years and recently had the chance of working with both Backbone and Ember. Here is my feedback:
The size of Ember library is bigger than total source code (including an AI library) of the last multiplayer game I built.
Ember.js and other frameworks exist to provide a basic structure for heavy client-side applications. Namely, a way to separate your "models" from your "views", if that's something you think is worth doing in your application.
If you don't like the way the Ember framework is structured, that's fine! But you probably have a personal style that you use in your applications that could be distilled into some kind of framework, and there's more to it than "CPS".
This is going to sound unfair, and maybe it is, but here goes:
The biggest difference between Ember and Knockout is that Knockout has excellent documentation and tutorials, and is very easy to pick up. The tooling and knowledge needed to get a basic proof of concept app up and running from scratch is trivial with Knockout. It fits into whatever toolchain or build process you already have; as a result it's easy to add Knockout to an existing Django or Node project.
By contrast, Ember has poor documentation and tutorials. This was especially bad at launch, but even today it's very limited, and significant chunks still refer to Sproutcore. Some of that documentation is apparently still relevant, refers to the Sproutcore v2 project, and just haven't been updated with the new name. Other bits are apparently referring to the Sproutcore v1 project, and aren't relevant. Good luck figuring out which ones are which. Ember also has very idiosyncratic ideas about how projects should be built; again this isn't really documented. It's hard to build an Ember app from scratch, and it probably will not work with your current build process. It feels, in some difficult to define fashion, more like what I'd expect from the Java ecosystem. I'm not a fan.
As I said, I'm sure that sound unfair, and it may well be. Ember fans will no doubt be able to explain that it's much easier than that, that my problems were all my own fault, that the documentation is already much improved, and that any quirks that do exist do so for very good historical reasons. And they're probably right! But I came at Ember cold a month or two ago, tried very hard to figure it out, and bounced. As a result, I have no idea how Ember really compares to Knockout, because I figured out how to write my app in Knockout, but I couldn't figure out how to write it in Ember despite a very concerted effort. Take that for what it's worth. :)
(My impression, incidentally, is that Knockout is sort of what the Ember project wants to be, but they're still struggling to strip out the cruft they inherited from Sproutcore. Both projects have a focus on magical "it just works" dynamic bindings, which means you have incredible awesome power but have to be a little careful not to blow your leg off via some behind-the-scenes magic you didn't even realize existed. Backbone, on the other hand, is a very barebones framework; it's almost more like a toolkit you can use to build your own MVC framework. That's valuable too, depending on your needs.)
It links to a much longer IRC argument between their respective evangelists -- the whole thing is an interesting read if you like that sort of thing. But the takeaway is that Ember is pretty opinionated about how to connect views to subviews to templates to models to controllers to data stores, and backbone pretty much lets you/makes you do it yourself. So backbone might mean you're writing a lot of boilerplate, and ember might mean you're locked into decisions you don't like and slowed down by cruft you don't need -- same old tradeoff.
I'm excited to give ember a try, because my initial response to backbone was "wait, where's the rest?" I was expecting the level of handholding of, like, Django. So it'll be interesting to see what that's actually like in practice.
I've been extremely impressed with Knockout; just the right amount of "opinion" to make things easy without being too imposing. Its data binding interface is exactly what I was looking for to connect my models to views.
Ember is more of a fully featured framework than Backbone: it has bindings, computed properties and does some nice auto-updating stuff with handlebars templates — Backbone is more lightweight. Backbone is more popular and has been around for longer so it is arguably more battle-tested and there are more community resources.
This is almost the best article I have read about Ember.js which is not a compliment in this case because there are so few of them. I dont even mind images for code parts, because of rarity of this content type. I like Ember a lot but it still has a long road ahead, until community matures around it and helps out with more blog posts, examples, tutorials. Best of luck because its cool stuff.