Погружение в Angular

Сухим текстом представляю мои впечатления от знакомства с Angular.
До этого работал с Backbone и обратить на него внимания меня вынудили разговоры с командами которые его используют.
Чтобы лучше понять на каких принципах построен Angular реализовал небольшое приложение, которое разместил на github-е.

Что сразу бросилось в глаза.
Динамика интерфейса приложения скорее всего будет в верстке. Если же, разработчик не испытывает отвращение к "декларативному подходу".
Благодаря использованию директив обычная верстка перейдет в разряд шаблонов. Встроенная логика - дополнительный синтаксис, на подобии  SQL, LINQ. В таком примере
ng-options="key as value for (key, value) in categories"
часть после for относится к источнику, выражение до for определяет, какое значение использовать в качестве атрибута value опции, а какое в качестве текста опции.
Параметризация шаблонов с возможностью двунаправленного биндинга поддерживается изначально.
<h3>{{[«Добавление»,«Изменение»][(item.id>0)+0]}} записи</h3>
По слухам, в шаблоне не работает тернарный оператор, поэтому в этом примере он был заменен такой конструкцией.

Достоинства:

• Не требует зависимостей. В Backbone, для примера, потребуется jquery и underscore;
• Встроенная реализация привязки данных. В Backbone для аналогичного функционала придется создать удобный подсобный инструментарий или использовать стороннее решение (epoxy.js, ribs);
• Приемлемая архитектура построенная на патернах.

Недостатки :

• Не  имеет 100% эквивалентной замены функционала jquery для работы с DOM. К примеру, метод $element.find() работает только с названиями тегов и не работает с селекторами атрибутов (elem.find('[type=submit]'));
• Из личного, не так просто взять и вставить в нужное место вьюшку как в Backbone. Надо все обставить в специально "приготовленные" для этого директивы.

Сравнение с Backbone
Backbone по содержанию напоминает фреймворк кастомных MV* фреймворков. Необходимо самому реализовать вывод представления (метод render()). Можно использовать любой другой шаблонизатор по мимо underscore.template и т. п. Как связать атрибуты модели к вьюшке кодер решает сам. Т.е. то что будет использовано под "вывеской бекбона" будет удовлетворять вкусу и взглядам на правильный подход конечного разработчика. Поэтому необходимо, что бы у разработчика были представления о best practise и способах их достижений:

• Декларативное описания логики в шаблоне или перенос их в js код представления;
• Отдельное представление для каждой коллекции или коллекции будет вставлятся в DOM представления;
• Одна модель - одно представление или у одной модели может быть много представлений.

Разные слои абстракции. 
Backbone: Backbone.Events, Backbone.Model, Backbone.Collection, Backbone.View
под девизом "расширяй и наследуй".
Angular: service, fabric, module, controller, directive, filters Внедрение зависимостей.
В Angular роль бэкбоновской модели выполняют scope и сервисы, коллекции так же размыты.

Оффтоп
В Backbone для представления списка однотипных элементов имеется абстракция - Backbone.Collection (коллекции). Когда мне приходилось реализовывать коллекцию связанную с моделью представления в котором она размещается, всегда терзался вопросом правильной реализации. Вплоть до того, что стал коллекции выносить в отдельные дочерние представления. Ситуация осложнялась, тем что нет в Backbone механики для взаимодействия модели представления с моделями коллекции.

В последнее время у меня появилась мысль, что коллекции в Backbone (Backbone.Collection) получили ход, благодаря тому что в модели поддерживаются только plain объекты (без доступа к дочерним под объектам). Но пока эта мысль у меня развивается.