The point of Ember.js is to reduce the amount of boilerplate a developer needs to write to perform common tasks. I think Thomas did a good job of explaining how you can accomplish the same thing in Ember.js with fewer lines of code (and remember–less code, fewer bugs!)
I'm curious: what about the Backbone version feels "cleaner" to you?
My point was that the sample code didn't show Ember's strong features like computed properties and auto binding. The backbone version will be more or less the same size for this kind of demo.
as for the cleaner part, I didn't like the fact that I need to call _super().
On the other hand I really like .property and .observe in Ember.js :)
That's been my armchair analysis of this. I was set to go on vacation, but it looks like I may scrap that and write a new frontend for our application and I'm trying to narrow it down between Ember and Backbone. I'd found something yesterday that would give you the KO style observables in a light standalone library, though the name escapes me now. Maybe it+Backbone.js is the most versatile?
Synapse is an elegant API for data binding. Subjects and observers clarify many issues for data-flow interfaces.
The boilerplate in Backbone shrinks significantly when expressed with CoffeeScript. Synapse's source is expressive, well-documented and only ~200 lines.
Unfortunately, halayli's quite right here. You can, (and probably should) write the Backbone version of this in precisely the same way that Thomas does in his article.
There's a nice pattern here for checking ids for presence before adding new models, but nothing inherently Ember or Backbone about it.
I'm curious: what about the Backbone version feels "cleaner" to you?