Начинаем работать с Ember.js

Тут подробно расписаны отличия (и не только между ember и backbone) – coding.smashingmagazine.com/2012/07/27/journey-through-the-javascript-mvc-jungle/

Судя по статье, в Ember нет бОльшей части функционала Backbone. В Backbone хорошо реализованы модели, наследование, коллекции. Есть синхронизация модели с сервером из коробки. При этом они никак не завязаны на отображение. Это именно средства для описания предметной области — модели данных. С другой стороны отображения (Views) в Backbone многим кажутся громоздкими. Я думаю им стоило бы изобразительную часть сделать опциональной.

Я использую сейчас связку: Backbone + Knockout через надстройку Knockback. При этом есть еще одна надстройка над Backbone — Backbone-Relational. Более того серверная часть на NodeJS, так что модель данных для сервера и клиента у меня описывают одни и тот же файлы. Для сервера модели дополнительно расширяются. A Backbone-Relational в автомате помогает поддерживать связи между моделями. Пока что все красиво, но и не без особенностей. Knockback используется на клиенте — он просто позволяет облегчить конвертирование моделей Backbone в ViewModels Knockouta.

Как заявляют разработчки, ember стремится уменьшить кол-во «шаблонного кода», т.е. в нем сразу выбраны решения для типичных задач.
Основное преимущество и видимо одновременно и недостаток — это байндинги данных к Handlebars шаблонам. Что позволяет очень удобно автоматически обновлять страницу при изменениях. А с другой стороны это же накладывает некоторые ограничения на генерируемый по умолчанию html и он немного «замусоревается» служебными тегами, которые нужны ember для поддержки этой автоматики.
Ну и есть вопрос насколько гибко и быстро это будет работать в случае большого и/или сложного приложения. Хотя разработчики, вроде бы, обещают, что с этим все хорошо.

Также хорошо выглядит возможнось создавать вложенные view (пример из документации):

App.UserView = Ember.View.extend({
	templateName: 'user',
	// ...

	infoView: Ember.View.extend({
		templateName: 'info'
		// ...
	})
});

Это позволяет управлять довольно маленькими блоками страницы и повторно их использовать в других view.

Не могу сказать, что у меня сильно большой опыт работы с backbone и ember, но поигравшись с ними в небольших проектах, мне ember кажется удобнее и производит хорошее впечатление.

Ember = Sproutcore -> у Sproutcore есть dataStore и это круто

Ты и тут можешь использовать жиквери.
Если пишешь приложение, в котором есть крудо-подобные операции (а они почти всегда есть), то очень сложно следить за data consistency в нескольких местах одновременно (появляется много говнокода, жестких зависимостей в коде), здесь помогает эмбер, и еще он помогает сериализовать данные из хтмл в js-объекты (в случае использования биндингов на инпуты), ну и еще много с чем помогает

> Не проще ли писать на JQuery более очевидные конструкции?
На клиенте сейчас растет количестко кода и в больших приложениях jQuery просто не достаточно. jQuery это DOM обертка, которая никак не поможет вам организовать кодовую базу.

> А то получается и на стороне сервера у нас MVC и на клиенте MVC. Количество кода вырастает в разы!
Если честно то сейчас в некоторых случаях MVC(и модификации) более необходим оказывается на клиенте чем на сервере. Да и MVC архитектура пришла с десктопных аппликаций, а нынешний веб в ряде случаев все больше и больше напоминает десктоп.

на стороне серваре не MVC, а REST API. Ember.js это фреймворк для одностраничных приложение прежде всего.

блин, форматирование пропало :(

Там есть свой DataStore https://github.com/emberjs/data, который как раз и позволяет делать приблизительно то, что Вы хотите

var people = App.store.findAll(App.Person);

Вроде выглядит не плохо, да еще и от гугла, вопрос только — как жить с тем, что иде будут ругаться на невалидные атрибуты

Хорошая библиотечка, только я слабо понимаю, как ее совместить со статичным контентом, на случай выключенного жс у пользователя.