[jcampbell1]

I have nothing but praise for both Ember and Angular. Both give you real data binding, and delegation rather than events. Compared to Backbone, both are like being in heaven rather than the 4th level of "event" hell.

There are a lot of differences, but if I had to pick, it would depend on the application. If I was building something with complex front-end requirements where the vocabulary was mostly tabs/panes/switches/filter-dropdowns/etc., then I would go with Angular. If I were building something where the data domain was more important, e.g. the vocabulary is more about authors/titles/posts/tags/etc. then I'd go with Ember.

With Ember, persisting a complex model to a backend is a priority for the framework developers. With Angular, it is left as an exercise for the reader.

With Angular, extending the DOM to create new web components is a central focus, but with Ember, it is totally an after thought. Ember Components are a joke compared to Angular directives...

I was about to link to the Ember component source code showing how pointless they are. (A week ago they were useless) The devs have been furiously fixing Ember Components to have the power of Angular JS directives. I am so happy to see the good parts of Anular making their way into Ember. For those that hate Angular terminology, it appears 'isolate' has made its way to Ember. I hope 'transclusion' does as well. Need more than one way to {{yield}}

[djacobs]

I think it's important to remember that Backbone is not one library but a modular ecosystem. I am a huge fan of Backbone Marionette + Relational + ModelBinder as a very valid alternative to Ember and Angular.

[padolsey]

Even comparing Backbone (by itself) to these two is futile. It's thin, doesn't prescribe much, and doesn't even promise to offer what Emb/Ang do, so to compare them is unfair to all involved IMHO.

I'm reluctant to try something big with Angular because of its insistence on dirty checking, which just ends up being an annoyingly leaky abstraction half the time (see $timeout, for example).

[Nitramp]

I've written large applications in AngularJS, the dirty checking is generally not a problem. If you write complex directives that need to pass non-trivial data structures around, you have to know what you're doing, but it still works fine.

I don't get your reference to $timeout - $timeout is Angular's more testable wrapper around setTimeout for an asynchronous operation. AFAICT it's entirely unrelated to dirty checking - sometimes you just want something to happen later. Am I missing something?

[minznerjosh]

I think that one of the most important features of $timout is that it runs a digest cycle after the timeout completes. That's why bindings get updated when you modify data in a $timout callback. So it is related to dirty checking.

[cheapsteak]

You sound like you know your way around both frameworks.

How long would it take to learn both of them, if you're already familiar with Backbone?

Are there yet any comprehensive resources to learn either one, similar to Addy Osmani's Developing Backbone.js Applications book? The videos like Ember 101 and Egghead are nice, but I worry that they don't go deep enough.

[hackula1]

Couple weeks each to get to the point where you can make a good decision. You could probably just choose one and go with it for low risk projects.

[agilebyte]

Once a project gets big I switch to the Publisher/Subscriber pattern through a main Mediator rather than using the default Model/Collection change events.

That is to say that I cannot relate to your 4th/any hell level.

[hackerboos]

Can you elaborate on this?

[agilebyte]

I would create a global mediator:

    export var mediator = _.extend({}, Backbone.Events);

And then use it to listen to messages in Views:

    m.mediator.on('change:page change:sort change:tags', this.renderTable, this);

And fire them from Models/Collections:

    m.mediator.trigger('change:sort', sortOrder);

Instead of listening to changes on them:

    this.paginator.bind('change', fn, this);

So I can plug & play different parts of the system together.

Edit: A link from Addy Osmani: http://addyosmani.com/largescalejavascript/#mediatorpattern

[steveklabnik]

Have you tried out functional reactive programming? How does it compare to the mediator?

[agilebyte]

You mean like Bacon.js? I have not, yet. Looking at it now it seems that it is used for filtering/mapping/combining values?

The messages I send are more light weight and usually say "this has happened" to which a View would respond by re-rendering itself or its part rather then me directly passing whole Models and Collections around.

[steveklabnik]

Yup! It sounds quite a bit like your mediator: make a stream, send events in the stream, certain things respond to the stream.

Check out this talk: http://vimeo.com/68987289