So how is Ember.js different from the others?
While Backbone.js, for example, is a very small and unopinionated foundation upon which you are expected to build your own conventions and additions, Ember.js provides strong conventions and helpful tools for the problems that we think most developers will face when building large-scale applications.
A good way to summarize this is that Ember.js wants to eliminate trivial choices. Good developers love to argue, so when there is no official solution to a problem, every team has to spend time deciding how they should tackle it. Because everyone is doing things a little bit differently, shared knowledge is reduced, help is difficult to obtain, and time is wasted training new developers in your particular dialect.
Some examples of trivial choices that Ember.js decides for you:
What templating language should we use?
Who is responsible for memory management?
How should the application be structured?
How should classes and instances be named?
To be clear, these are all things that can be changed. For example, Ember.js can be used with a different templating language than Handlebars (the default), or none at all. But because there is a default, people tend to stick with it, and there is serious value in having the entire community on the same path.