Комментарии 34
Зачем мешать код с разметкой? Цена вопроса лишь в строчке кода привязки.
парсер лох!
Вырезает код примера, в общем, я про все эти ng-submit, ng-controller и прочие ng в html коде.
Вырезает код примера, в общем, я про все эти ng-submit, ng-controller и прочие ng в html коде.
Disclaimer: я не считаю, что всем надо взять и начать юзать AngularJS. Каждый выбирает по себе.
Но, много кода в разметку Вы не намешаете, т.к. expression там весьма облегченные — никаких конструкций, управляющих потоком исполнения.
И, если Вам несложно, неплохо бы было увидеть альтернативы, которые Вы предлагаете. Т.к. всягие ng — это не просто привязки. Или я Вас просто неправильно понимаю.
Но, много кода в разметку Вы не намешаете, т.к. expression там весьма облегченные — никаких конструкций, управляющих потоком исполнения.
И, если Вам несложно, неплохо бы было увидеть альтернативы, которые Вы предлагаете. Т.к. всягие ng — это не просто привязки. Или я Вас просто неправильно понимаю.
Вопрос не в том много ли мало ли, вопрос в том зачем вообще так делать. Альтернатива, соответственно, — не смешивать их. В этом как минимум все выгоды loosely coupling по цене строчки кода на привязку к элементу. Если нужны фреймворки, то тут от backbone и дальше.
Disclamer: Об остальных плюсах я вовсе ничего не понял, но раз это перевод, то глупо их обсуждать тут.
Disclamer: Об остальных плюсах я вовсе ничего не понял, но раз это перевод, то глупо их обсуждать тут.
Сравнивая тот же ToDo из ToDoMVC для Backbone и AngularJS, для меня AngularJS лаконичнее, нагляднее, читабельнее, удобнее в разработке.
Пример я попросил, в том числе потому что Вы в аргументации все время используете слово «привязка». ng* директивы — это не только привязки.
В целом, разработчики считают, что для описания интерфейса лучше подходит декларативный стиль, а для написания бизнес-логики — императивный.
Я вот подумал, что, наверное, не эту статью надо было перевести, а Overview из Developer Guide.
Пример я попросил, в том числе потому что Вы в аргументации все время используете слово «привязка». ng* директивы — это не только привязки.
В целом, разработчики считают, что для описания интерфейса лучше подходит декларативный стиль, а для написания бизнес-логики — императивный.
Я вот подумал, что, наверное, не эту статью надо было перевести, а Overview из Developer Guide.
подход мне напомнил любимый мной в свое время spry от Adobe. Классная, быстрая и удобная штука для своего времени была.
angularjs by google — это когда google успел купить angularjs? раньше подобного баннера там не замечал.
«AngularJS is a Google project. Google is using it internally and Google has been funding it for 2 years already.» пруф
И у Igor Minar, и у Miško Hevery, и у Brad Green, и у Vojta Jína (наверное я не всех разработчиков перечислил) в профилях местом работы указан Google.
И у Igor Minar, и у Miško Hevery, и у Brad Green, и у Vojta Jína (наверное я не всех разработчиков перечислил) в профилях местом работы указан Google.
Расскажите историю про вредность MVC ;)
Вставьте в статью побольше примеров
Я не знаю, стоит ли. У них на главной примеры очень хорошо выложены.
Я надеялся этим переводом больше заинтересовать, а так — у них и документация хорошая и примеры.
Я надеялся этим переводом больше заинтересовать, а так — у них и документация хорошая и примеры.
может быть я задам сейчас очень глупый вопрос, но все же.
чем он лучше того же jquery например?
чем он лучше того же jquery например?
У них цели разные. Jquery, грубо говоря, — для манипулиции с DOMом. И, если я не ошибаюсь, AngularJS его для манипуляций с DOMом и использует.
Если же Вам нужно писать одностраничные приложения, либо приложения с активно взаимодействующими друг с другом и с сервером элементами управления, то примерно для этого AngularJS и создавался.
Если же Вам нужно писать одностраничные приложения, либо приложения с активно взаимодействующими друг с другом и с сервером элементами управления, то примерно для этого AngularJS и создавался.
Это что-то очень похожее на KnockoutJS или я ошибаюсь?
да, только KnockoutJS развивается дико медленно, версия 2 наверное год выходила.
Это смотря с чем сравнивать. Ember (SC2) в разработке больше двух лет был, а на выходе получили монстра, не предлагающего ничего нового по сравнению с BB и KO.
Angular выглядел очень плачевно, когда я выбирал между ним и Knockout год назад. Сегодня это что-то навороченное, но есть пару моментов:
— Knockout явно не стоял на месте — релиз 2.0 может и содержит немного фич, но ими всеми начинаешь пользоваться постоянно. Очень и очень удачный набор получился.
— куча крафта, который существовал в angular, так там и остается. Я смотрю на него и понимаю, что мне совсем-совсем не хочется иметь с ним дело.
— дружелюбность к REST — это хорошо. Еще б было хорошо, если б сервер писался так, чтобы оставаться дружелюбным к REST. На практике подобное случается редко. Что до конкретного примера, jQuery getJSON в связке с destructurring assignment из ES6/CoffeeScript дают похожий результат.
По пунктам, перечисленным в статье:
— DI. Не знаю, нужно ли это. Автор называет причины: модульность, архитектура, зависимости — тут поможет AMD и динамическая типизация.
— Unit Tests. Никто не мешает писать тесты для того же Ko. Хочешь Jasmine, хочешь — Mocha — пожалуйста.
— e2e. Mockjax спасет отца русской демократии
— сообщество. В гуглогруппе Нокаута тоже полно энтузиастов, чуть что сразу фиддл в студию и решают проблему.
— декларативность. Синтаксис байндитгов и атрибутов Нокаута имо чище и читабельней. Кроме того, data-атрибуты проходят валидацию.
— scopes и watches — в Нокауте есть и работать с ними очень и очень удобно.
В общем, дело обстоит так:
— выбрали Нокаут — оставайтесь, все в порядке.
— еще ничего не выбрали? — попробуйте одно и другое, посмотрите, что вам лично нравится.
Angular выглядел очень плачевно, когда я выбирал между ним и Knockout год назад. Сегодня это что-то навороченное, но есть пару моментов:
— Knockout явно не стоял на месте — релиз 2.0 может и содержит немного фич, но ими всеми начинаешь пользоваться постоянно. Очень и очень удачный набор получился.
— куча крафта, который существовал в angular, так там и остается. Я смотрю на него и понимаю, что мне совсем-совсем не хочется иметь с ним дело.
— дружелюбность к REST — это хорошо. Еще б было хорошо, если б сервер писался так, чтобы оставаться дружелюбным к REST. На практике подобное случается редко. Что до конкретного примера, jQuery getJSON в связке с destructurring assignment из ES6/CoffeeScript дают похожий результат.
По пунктам, перечисленным в статье:
— DI. Не знаю, нужно ли это. Автор называет причины: модульность, архитектура, зависимости — тут поможет AMD и динамическая типизация.
— Unit Tests. Никто не мешает писать тесты для того же Ko. Хочешь Jasmine, хочешь — Mocha — пожалуйста.
— e2e. Mockjax спасет отца русской демократии
— сообщество. В гуглогруппе Нокаута тоже полно энтузиастов, чуть что сразу фиддл в студию и решают проблему.
— декларативность. Синтаксис байндитгов и атрибутов Нокаута имо чище и читабельней. Кроме того, data-атрибуты проходят валидацию.
— scopes и watches — в Нокауте есть и работать с ними очень и очень удобно.
В общем, дело обстоит так:
— выбрали Нокаут — оставайтесь, все в порядке.
— еще ничего не выбрали? — попробуйте одно и другое, посмотрите, что вам лично нравится.
А что Вы подразумеваете под кучей крафта?
В целом, если собрать вместе Knockout+ jQuery getJSON вместе с destructurring assignment из ES6/CoffeeScript + Jasmine/Mocha + Mockjax, то получим что-то типа AngularJS. Я правильно понял? Правда у AngularJS при этом будет цельная архитектура, философия, подходы к созданию приложения. С другой стороны — для кого-то это плюс, кому-то может чем-то мешать.
Кстати, синтаксис байдингов и атрибутов — это, похоже, действительно, очень субъективный момент, т.к. мне чище и проще AngularJS ;-) Ну и опять же, если смотреть ToDo из ToDoMVC, то, на мой взгляд, AngularJS лаконичнее, особенно в js.
В целом, если собрать вместе Knockout+ jQuery getJSON вместе с destructurring assignment из ES6/CoffeeScript + Jasmine/Mocha + Mockjax, то получим что-то типа AngularJS. Я правильно понял? Правда у AngularJS при этом будет цельная архитектура, философия, подходы к созданию приложения. С другой стороны — для кого-то это плюс, кому-то может чем-то мешать.
Кстати, синтаксис байдингов и атрибутов — это, похоже, действительно, очень субъективный момент, т.к. мне чище и проще AngularJS ;-) Ну и опять же, если смотреть ToDo из ToDoMVC, то, на мой взгляд, AngularJS лаконичнее, особенно в js.
> Я правильно понял?
Да, и мне нравится работать с небольшими библиотеками, которые делают что-то немногое, но очень хорошо. Цельная архитектура — это хорошо, когда она к тому же еще и отличная. Но в отношении практики JS в Google я такого сказать не могу — их Closure Library, например, на момент выхода поигрывала с точки зрения модульного подхода YUI, да и работа с DOM очень и очень отставала от jQuery. В результате библиотека не взлетела, не смотря на то, что на ней написаны одни из лучших веб-приложений: Gmail и Google Docs.
Здесь у меня такое же недоверие. Те же теги: все эти ng- не соответствуют духу HTML — там для кастом данных предполагается использование data-атрибутов. Или темплейтинг, который вводит лишний синтаксический мусор. Хотя тут обе библиотеки впереди планеты всей: ни Ember, ни Underscore, ни Mustache и близко не подошли.
Все потому, что Angular и в большей степени Knockout позволяют вводить темплейтинг, не нарушая структуру самого HTML-документа. Тем самым мы можем дать нашу верстку на откуп дизайнеру, потом добавить темплейт-атрибуты, но дизайнер сможет продолжать работу с документом так, как если бы это был статический HTML. Т.е. если он хочет, он может использовать инструменты для верстки, или верстать на «рыбе» — мы его никак не ограничиваем. Это жирный плюс, особенно, если хочется распараллелить работу над UI, и мы в моей команде применяем данный подход на практике. Один человек верстает на рыбе, второй вводит байндинги с мок-данными, третий привязывает вьюмодель к бекенду. И в большинстве случаев мы можем работать параллельно.
Насчет JS. Мне понравился KO своей работой с атрибутами модели. С одной стороны да, запись вида
несколько длиннее, чем
Но зато потом, когда мы обращаемся к свойству, мы получим следующее
И вроде бы разница небольшая, но при использовании Нокаута у меня в среде разработки или в текстовом редакторе срабатывает автокомплит. Мне самому может и мелочь, а вот ребятам, которые только-только пересаживаются с C# или Java на JavaScript это очень помогает.
К angular мой пример меньше относится, но он тоже не очень дружит с автокомплитом из-за того, что свойства описываются в $scope.
Отличия минимальны и я в общем-то полагался на чутье, когда выбирал Нокаут, но после десятков тысяч строк кода на JS за последний год я все больше убеждаюсь в правильности выбора. В моих глазах преимущества Нокаута следующие:
Для новичка:
— минимум магии (за исключением байндингов, но там у всех она есть)
— минимум концепций для изучения
— простота API
Для середнячка:
— возможность построения сложных цепей зависимостей без особых проблем
— легкость интеграции с UI библиотеками через кастом байндинги
Для команды:
— параллельная работа над разными участками приложения
— возможность одновременной работы над проектом нескольких участников с совершенно разным уровнем подготовки
— низкий порог вхождения для людей, плохо знакомым с JavaScript
Да, и мне нравится работать с небольшими библиотеками, которые делают что-то немногое, но очень хорошо. Цельная архитектура — это хорошо, когда она к тому же еще и отличная. Но в отношении практики JS в Google я такого сказать не могу — их Closure Library, например, на момент выхода поигрывала с точки зрения модульного подхода YUI, да и работа с DOM очень и очень отставала от jQuery. В результате библиотека не взлетела, не смотря на то, что на ней написаны одни из лучших веб-приложений: Gmail и Google Docs.
Здесь у меня такое же недоверие. Те же теги: все эти ng- не соответствуют духу HTML — там для кастом данных предполагается использование data-атрибутов. Или темплейтинг, который вводит лишний синтаксический мусор. Хотя тут обе библиотеки впереди планеты всей: ни Ember, ни Underscore, ни Mustache и близко не подошли.
Все потому, что Angular и в большей степени Knockout позволяют вводить темплейтинг, не нарушая структуру самого HTML-документа. Тем самым мы можем дать нашу верстку на откуп дизайнеру, потом добавить темплейт-атрибуты, но дизайнер сможет продолжать работу с документом так, как если бы это был статический HTML. Т.е. если он хочет, он может использовать инструменты для верстки, или верстать на «рыбе» — мы его никак не ограничиваем. Это жирный плюс, особенно, если хочется распараллелить работу над UI, и мы в моей команде применяем данный подход на практике. Один человек верстает на рыбе, второй вводит байндинги с мок-данными, третий привязывает вьюмодель к бекенду. И в большинстве случаев мы можем работать параллельно.
Насчет JS. Мне понравился KO своей работой с атрибутами модели. С одной стороны да, запись вида
var viewModel = { // KO
property: ko.observable(value)
}
несколько длиннее, чем
model.set({property: value}); // BB
Но зато потом, когда мы обращаемся к свойству, мы получим следующее
viewModel.property(); // KO
model.get('property'); // BB
И вроде бы разница небольшая, но при использовании Нокаута у меня в среде разработки или в текстовом редакторе срабатывает автокомплит. Мне самому может и мелочь, а вот ребятам, которые только-только пересаживаются с C# или Java на JavaScript это очень помогает.
К angular мой пример меньше относится, но он тоже не очень дружит с автокомплитом из-за того, что свойства описываются в $scope.
Отличия минимальны и я в общем-то полагался на чутье, когда выбирал Нокаут, но после десятков тысяч строк кода на JS за последний год я все больше убеждаюсь в правильности выбора. В моих глазах преимущества Нокаута следующие:
Для новичка:
— минимум магии (за исключением байндингов, но там у всех она есть)
— минимум концепций для изучения
— простота API
Для середнячка:
— возможность построения сложных цепей зависимостей без особых проблем
— легкость интеграции с UI библиотеками через кастом байндинги
Для команды:
— параллельная работа над разными участками приложения
— возможность одновременной работы над проектом нескольких участников с совершенно разным уровнем подготовки
— низкий порог вхождения для людей, плохо знакомым с JavaScript
Надо статью писать :)
Еще раз скажу, что angular очень хорош, и для меня лично он кажется предпочтительнее и Bacdkbone, и Ember.
Еще раз скажу, что angular очень хорош, и для меня лично он кажется предпочтительнее и Bacdkbone, и Ember.
Спасибо.
А Вы у себя тестируете интерфейс, разрабатываемый с помощью Knockout?
А Вы у себя тестируете интерфейс, разрабатываемый с помощью Knockout?
Львиная доля тестинга — Selenium, делает скриншоты, выполняется как по сценариям, так и в fuzzy-режиме.
Если говорить о компонентах, с помощью Mockjax и Jasmine тестим логику без привязки к конкретному HTML. Байндинги не тестим — обычно получается так, что их раз настроил и они работают. В редких случаях байндинги сложновато дебажить, но особых проблем нет: главное — приноровиться.
Тесты запускаются каждый раз во время билда, билд на каждый коммит — команда небольшая и идет всего несколько коммитов в день, так что не напряжно.
Если говорить о компонентах, с помощью Mockjax и Jasmine тестим логику без привязки к конкретному HTML. Байндинги не тестим — обычно получается так, что их раз настроил и они работают. В редких случаях байндинги сложновато дебажить, но особых проблем нет: главное — приноровиться.
Тесты запускаются каждый раз во время билда, билд на каждый коммит — команда небольшая и идет всего несколько коммитов в день, так что не напряжно.
Хм, можно и так сказать.
Вот пара ссылок, где ключевые разработчики выссказываются по сходным вопросам:
Angular.js vs Backbone.js
angular seems like knockout + backbone?
Вкратце: он содержит возможности и Backbone, и Knockout + инструментарий для тестирования, но при этом имеет свою философию, которая может подойти не всем разработчикам и не всем приложениям.
Вот пара ссылок, где ключевые разработчики выссказываются по сходным вопросам:
Angular.js vs Backbone.js
angular seems like knockout + backbone?
Вкратце: он содержит возможности и Backbone, и Knockout + инструментарий для тестирования, но при этом имеет свою философию, которая может подойти не всем разработчикам и не всем приложениям.
На мой взгляд, читать код очень трудно.
Синтаксис далеко не очевиден, без мануала и хорошей памяти не обойтись.
Особенно удивила дикая смесь prototype, clojure и chain подходов.
На мой взгляд, это — очередной велосипед от заскучавших разработчиков из крупных компаний.
Такое часто случается, когда амбиции прут наружу, а за плечами годы скучного enterprise-кода.
Синтаксис далеко не очевиден, без мануала и хорошей памяти не обойтись.
Особенно удивила дикая смесь prototype, clojure и chain подходов.
На мой взгляд, это — очередной велосипед от заскучавших разработчиков из крупных компаний.
Такое часто случается, когда амбиции прут наружу, а за плечами годы скучного enterprise-кода.
Поддерживаю, человеку с таким ником нельзя не доверять :)
Синтаксис декларативной части (директивы ng*) неочевиден? Или императивной (контроллеры и т.п.)? Или и то и то?
Пожалуй, обе части.
В шаблонах очень много кастомных тегов, а директивы раскиданы и как теги, и как аттрибуты html-тегов.
Я много лет работал с XSLT и соблюдение неймспейса облегчает понимание шаблона.
Про контроллеры я уже написал, что там намешаны подходы и много не очевидных моментов.
А код шаблона в коде контроллера говорит о неаккуратности даже в показательном коде.
Я бы стал с этим работать за рабочее место в Гугле со всеми их плюшками.
Наверное…
В шаблонах очень много кастомных тегов, а директивы раскиданы и как теги, и как аттрибуты html-тегов.
Я много лет работал с XSLT и соблюдение неймспейса облегчает понимание шаблона.
Про контроллеры я уже написал, что там намешаны подходы и много не очевидных моментов.
А код шаблона в коде контроллера говорит о неаккуратности даже в показательном коде.
Я бы стал с этим работать за рабочее место в Гугле со всеми их плюшками.
Наверное…
Спасибо.
> В шаблонах очень много кастомных тегов
За счет кастомных тегов и декларативного описания интерфейса — получаем краткость. Само собой надо в определенном объеме разобраться, но директив немного и система в названиях определенная есть. Да и редко какой новый фреймворк не требует вдумчивого прочтения документации.
> а директивы раскиданы и как теги, и как аттрибуты html-тегов.
Просто есть несколько вариантов использования директив. Выбор для каждой команды будет зависеть от их предпочтений по стилю кодирования и необходимости поддержки старых браузеров (в основном по ветке IE).
> А код шаблона в коде контроллера говорит о неаккуратности даже в показательном коде.
Это Вы про пример создания собственной директивы с визуальной частью? Это, судя по всему, не самая часто используемая и достаточно специфическая фича. А разметку, я думаю, туда впилили для демонстрации и краткости. Честно говоря, не испытывал пока необходимости создания собственных директив. Но сейчас посмотрел в документацию: шаблон можно и асинхронно подтянуть через templateUrl.
P.S. Надеюсь, blockquote только в предпросмотре не пашет.
> В шаблонах очень много кастомных тегов
За счет кастомных тегов и декларативного описания интерфейса — получаем краткость. Само собой надо в определенном объеме разобраться, но директив немного и система в названиях определенная есть. Да и редко какой новый фреймворк не требует вдумчивого прочтения документации.
> а директивы раскиданы и как теги, и как аттрибуты html-тегов.
Просто есть несколько вариантов использования директив. Выбор для каждой команды будет зависеть от их предпочтений по стилю кодирования и необходимости поддержки старых браузеров (в основном по ветке IE).
> А код шаблона в коде контроллера говорит о неаккуратности даже в показательном коде.
Это Вы про пример создания собственной директивы с визуальной частью? Это, судя по всему, не самая часто используемая и достаточно специфическая фича. А разметку, я думаю, туда впилили для демонстрации и краткости. Честно говоря, не испытывал пока необходимости создания собственных директив. Но сейчас посмотрел в документацию: шаблон можно и асинхронно подтянуть через templateUrl.
P.S. Надеюсь, blockquote только в предпросмотре не пашет.
Извиняюсь за дубли, сначала думал, что Опера глючила, добавил коммент черех Хром, потом дошло, почему нифига теги не работают, подождал 5 минут, чтобы добавить ссылку на документацию и по запарке ткнул опубликовать на старый коммент в Опере :)
Ссылка на документацию: docs-next.angularjs.org/api/angular.module.ng.$compileProvider.directive
Ссылка на документацию: docs-next.angularjs.org/api/angular.module.ng.$compileProvider.directive
> В шаблонах очень много кастомных тегов
За счет кастомных тегов и декларативного описания интерфейса — получаем краткость. Само собой надо в определенном объеме разобраться, но директив немного и система в названиях определенная есть. Да и редко какой новый фреймворк не требует вдумчивого прочтения документации.
> а директивы раскиданы и как теги, и как аттрибуты html-тегов.
Просто есть несколько вариантов использования директив. Выбор для каждой команды будет зависеть от их предпочтений по стилю кодирования и необходимости поддержки старых браузеров (в основном по ветке IE).
> А код шаблона в коде контроллера говорит о неаккуратности даже в показательном коде.
Это Вы про пример создания собственной директивы с визуальной частью? Это, судя по всему, не самая часто используемая и достаточно специфическая фича. А разметку, я думаю, туда впилили для демонстрации и краткости. Честно говоря, не испытывал пока необходимости создания собственных директив. Но сейчас посмотрел в документацию: шаблон можно и асинхронно подтянуть через templateUrl.
За счет кастомных тегов и декларативного описания интерфейса — получаем краткость. Само собой надо в определенном объеме разобраться, но директив немного и система в названиях определенная есть. Да и редко какой новый фреймворк не требует вдумчивого прочтения документации.
> а директивы раскиданы и как теги, и как аттрибуты html-тегов.
Просто есть несколько вариантов использования директив. Выбор для каждой команды будет зависеть от их предпочтений по стилю кодирования и необходимости поддержки старых браузеров (в основном по ветке IE).
> А код шаблона в коде контроллера говорит о неаккуратности даже в показательном коде.
Это Вы про пример создания собственной директивы с визуальной частью? Это, судя по всему, не самая часто используемая и достаточно специфическая фича. А разметку, я думаю, туда впилили для демонстрации и краткости. Честно говоря, не испытывал пока необходимости создания собственных директив. Но сейчас посмотрел в документацию: шаблон можно и асинхронно подтянуть через templateUrl.
И для завершения картины, если не сложно, за какую альтернативу голосуете Вы?
На работе мы используем MVC и clojure-подход для создания классов.
Выходит что mvc-фреймворка нет и разобраться в коде очень просто.
А ведь наша работа заключается не в том, чтобы долго разбираться в коде, а чтобы делать больше нового и полезного, правда? :-)
В своих экспериментах я использую Backbone, но в последнее время присматриваюсь к Ember.js
Мне симпатичны фреймворки, код которых можно понять не закапываясь в документацию.
Выходит что mvc-фреймворка нет и разобраться в коде очень просто.
А ведь наша работа заключается не в том, чтобы долго разбираться в коде, а чтобы делать больше нового и полезного, правда? :-)
В своих экспериментах я использую Backbone, но в последнее время присматриваюсь к Ember.js
Мне симпатичны фреймворки, код которых можно понять не закапываясь в документацию.
В порядке обмена мнениями :)
Backbone: если посмотреть на тот же ToDoMVC, то получается интерфейс размазан на 3 части — общая схема интерфейса, пониже шаблоны двух частей интерфейса, в js — описание view и как это все собрать вместе. Имхо, у AngularJS — нагляднее, компактненько в одном месте. И кода меньше, особенно в js.
Ember.js: для шаблонизации там Handlebars, и вобщем-то от кастомных директив мы никуда не ушли: view, collection, contentBinding, itemClassBinding, classNameBindings. И кода JS больше. Он то, конечно, понятен. Но его много надо и написать и потом прочитать. А ведь наша работа заключается не в том, чтобы много писать и долго читать, а чтобы делать больше нового и полезного, правда?" ;-)
Backbone: если посмотреть на тот же ToDoMVC, то получается интерфейс размазан на 3 части — общая схема интерфейса, пониже шаблоны двух частей интерфейса, в js — описание view и как это все собрать вместе. Имхо, у AngularJS — нагляднее, компактненько в одном месте. И кода меньше, особенно в js.
Ember.js: для шаблонизации там Handlebars, и вобщем-то от кастомных директив мы никуда не ушли: view, collection, contentBinding, itemClassBinding, classNameBindings. И кода JS больше. Он то, конечно, понятен. Но его много надо и написать и потом прочитать. А ведь наша работа заключается не в том, чтобы много писать и долго читать, а чтобы делать больше нового и полезного, правда?" ;-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
7 причин, почему AngularJS крут