7 причин, почему AngularJS крут

Достаточно вольный перевод заметки 7 reasons why angularJS rocks.

AngularJS
Я backend-разработчик и мир Javascript фреймворков для меня достаточно нов, хотя в последние полгода мой интерес к ним сильно растет. Причина проста: я считаю, что стек технологий REST + JSON + Rich JS все больше подходит для широкого круга веб-приложений. Такой подход помогает победить дерьмовую сомнительную концепцию MVC в серверных приложениях. Почему MVC можно считать вредным — это отдельная история, сейчас лучше поговорим об AngularJS.

Что в AngularJS особенного?

Dependency injection в стандартной поставке

Что дает вам более “чистые” интерфейсы, прозрачные зависимости и держит вашу архитектуру в хорошей форме.

Возможности модульного тестирования в стандартной поставке

И это не просто бросание слов на ветер, т.к. Miško Hevery является одним из ключевых разработчиков, который известен (по крайней мере, мне) своей пропагандой тестирования.

e2e тесты позволяют легко мокать запросы

Ваши тесты не зависят от сервисов на стороне сервера. Вы можете полностью изолировать свои тесты:
$httpBackend.whenGET("http://api.example.com/data").respond({'data': 123});


Декларативность

Вы по максимуму используете HTML атрибуты, сохраняя тем самым сотни строчек javascript кода.

Отличное open source сообщество

Практически мгновенные (обычно пара часов) ответы в списке рассылки. Быстрые решения по pull request-ам. Ключевые разработчики открыты для обсуждений.

Дружелюбность к REST

AngularJS действительно дружелюбен к REST. Вот так вы можете получить список коммитов репозитория на Github:
var commits = $resource('https://api.github.com/repos/:user/:project/commits').get({user: 'mkotsur', project: 'gitoscop'})


Scopes, bindings и watches

У вас есть scope-ы, изменения которых отслеживаются и модели которых могут быть привязаны к HTML элементам. Все обновления работают автомагически с помощью $scope.$watch.

Для того чтобы глубже познакомиться с Angular, я создал «игрушечное» приложение, которое использует API Github для представления интерфейса работы с последними коммитами и diff-ами выбранного репозитория. Демо: http://mkotsur.github.com/gitoscop, код: https://github.com/mkotsur/gitoscop.

Конец перевода.

Небольшое добавление для джангистов:
  • конфликт template тегов — stackoverflow.com/questions/8302928/angularjs-with-django-conflicting-template-tags. Верхний ответ — для 0.9.x, второй ответ для 1.0.x.
  • для csrf я сейчас использую что-то типа этого:
            var module = angular.module('Cabinet', [], function ($interpolateProvider) {
                $interpolateProvider.startSymbol('[[');
                $interpolateProvider.endSymbol(']]');
            }).
            config(function($httpProvider){
                $httpProvider.defaults.headers.common['X-CSRFToken'] = '{{ csrf_token }}';
            });
    



Несколько интересных ссылок:
Поделиться публикацией

Комментарии 34

    +2
    Зачем мешать код с разметкой? Цена вопроса лишь в строчке кода привязки.
      0
      парсер лох!
      Вырезает код примера, в общем, я про все эти ng-submit, ng-controller и прочие ng в html коде.
        0
        Чтобы экранировать исходный код от парсера Хабрахабра, следует использовать <source></source>, для чего предусмотрен специальный выпадающий список над формою комментария на Хабрахабре.
        0
        Disclaimer: я не считаю, что всем надо взять и начать юзать AngularJS. Каждый выбирает по себе.

        Но, много кода в разметку Вы не намешаете, т.к. expression там весьма облегченные — никаких конструкций, управляющих потоком исполнения.

        И, если Вам несложно, неплохо бы было увидеть альтернативы, которые Вы предлагаете. Т.к. всягие ng — это не просто привязки. Или я Вас просто неправильно понимаю.
          0
          Вопрос не в том много ли мало ли, вопрос в том зачем вообще так делать. Альтернатива, соответственно, — не смешивать их. В этом как минимум все выгоды loosely coupling по цене строчки кода на привязку к элементу. Если нужны фреймворки, то тут от backbone и дальше.

          Disclamer: Об остальных плюсах я вовсе ничего не понял, но раз это перевод, то глупо их обсуждать тут.
            0
            Сравнивая тот же ToDo из ToDoMVC для Backbone и AngularJS, для меня AngularJS лаконичнее, нагляднее, читабельнее, удобнее в разработке.

            Пример я попросил, в том числе потому что Вы в аргументации все время используете слово «привязка». ng* директивы — это не только привязки.

            В целом, разработчики считают, что для описания интерфейса лучше подходит декларативный стиль, а для написания бизнес-логики — императивный.

            Я вот подумал, что, наверное, не эту статью надо было перевести, а Overview из Developer Guide.
        0
        подход мне напомнил любимый мной в свое время spry от Adobe. Классная, быстрая и удобная штука для своего времени была.
          0
          angularjs by google — это когда google успел купить angularjs? раньше подобного баннера там не замечал.
            +2
            «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.
            +3
            Расскажите историю про вредность MVC ;)
              0
              К автору. Я только перевел. Сам сходу не шибко уловил, о чем речь.
              +1
              Вставьте в статью побольше примеров
                0
                Я не знаю, стоит ли. У них на главной примеры очень хорошо выложены.
                Я надеялся этим переводом больше заинтересовать, а так — у них и документация хорошая и примеры.
                  –1
                  может быть я задам сейчас очень глупый вопрос, но все же.

                  чем он лучше того же jquery например?
                    0
                    У них цели разные. Jquery, грубо говоря, — для манипулиции с DOMом. И, если я не ошибаюсь, AngularJS его для манипуляций с DOMом и использует.
                    Если же Вам нужно писать одностраничные приложения, либо приложения с активно взаимодействующими друг с другом и с сервером элементами управления, то примерно для этого AngularJS и создавался.
                0
                Это что-то очень похожее на KnockoutJS или я ошибаюсь?
                  0
                  да, только KnockoutJS развивается дико медленно, версия 2 наверное год выходила.
                    0
                    Это смотря с чем сравнивать. 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 — в Нокауте есть и работать с ними очень и очень удобно.

                    В общем, дело обстоит так:
                    — выбрали Нокаут — оставайтесь, все в порядке.
                    — еще ничего не выбрали? — попробуйте одно и другое, посмотрите, что вам лично нравится.
                      0
                      А что Вы подразумеваете под кучей крафта?

                      В целом, если собрать вместе Knockout+ jQuery getJSON вместе с destructurring assignment из ES6/CoffeeScript + Jasmine/Mocha + Mockjax, то получим что-то типа AngularJS. Я правильно понял? Правда у AngularJS при этом будет цельная архитектура, философия, подходы к созданию приложения. С другой стороны — для кого-то это плюс, кому-то может чем-то мешать.

                      Кстати, синтаксис байдингов и атрибутов — это, похоже, действительно, очень субъективный момент, т.к. мне чище и проще AngularJS ;-) Ну и опять же, если смотреть ToDo из ToDoMVC, то, на мой взгляд, AngularJS лаконичнее, особенно в js.
                        0
                        > Я правильно понял?

                        Да, и мне нравится работать с небольшими библиотеками, которые делают что-то немногое, но очень хорошо. Цельная архитектура — это хорошо, когда она к тому же еще и отличная. Но в отношении практики 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
                          0
                          Надо статью писать :)

                          Еще раз скажу, что angular очень хорош, и для меня лично он кажется предпочтительнее и Bacdkbone, и Ember.
                            0
                            Спасибо.

                            А Вы у себя тестируете интерфейс, разрабатываемый с помощью Knockout?
                              0
                              Львиная доля тестинга — Selenium, делает скриншоты, выполняется как по сценариям, так и в fuzzy-режиме.

                              Если говорить о компонентах, с помощью Mockjax и Jasmine тестим логику без привязки к конкретному HTML. Байндинги не тестим — обычно получается так, что их раз настроил и они работают. В редких случаях байндинги сложновато дебажить, но особых проблем нет: главное — приноровиться.

                              Тесты запускаются каждый раз во время билда, билд на каждый коммит — команда небольшая и идет всего несколько коммитов в день, так что не напряжно.
                      +1
                      Хм, можно и так сказать.
                      Вот пара ссылок, где ключевые разработчики выссказываются по сходным вопросам:
                      Angular.js vs Backbone.js
                      angular seems like knockout + backbone?

                      Вкратце: он содержит возможности и Backbone, и Knockout + инструментарий для тестирования, но при этом имеет свою философию, которая может подойти не всем разработчикам и не всем приложениям.
                      +2
                      На мой взгляд, читать код очень трудно.
                      Синтаксис далеко не очевиден, без мануала и хорошей памяти не обойтись.
                      Особенно удивила дикая смесь prototype, clojure и chain подходов.

                      На мой взгляд, это — очередной велосипед от заскучавших разработчиков из крупных компаний.
                      Такое часто случается, когда амбиции прут наружу, а за плечами годы скучного enterprise-кода.
                        +3
                        Поддерживаю, человеку с таким ником нельзя не доверять :)
                          0
                          Синтаксис декларативной части (директивы ng*) неочевиден? Или императивной (контроллеры и т.п.)? Или и то и то?
                            0
                            Пожалуй, обе части.

                            В шаблонах очень много кастомных тегов, а директивы раскиданы и как теги, и как аттрибуты html-тегов.
                            Я много лет работал с XSLT и соблюдение неймспейса облегчает понимание шаблона.

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

                            Я бы стал с этим работать за рабочее место в Гугле со всеми их плюшками.
                            Наверное…
                              0
                              Спасибо.

                              > В шаблонах очень много кастомных тегов

                              За счет кастомных тегов и декларативного описания интерфейса — получаем краткость. Само собой надо в определенном объеме разобраться, но директив немного и система в названиях определенная есть. Да и редко какой новый фреймворк не требует вдумчивого прочтения документации.

                              > а директивы раскиданы и как теги, и как аттрибуты html-тегов.

                              Просто есть несколько вариантов использования директив. Выбор для каждой команды будет зависеть от их предпочтений по стилю кодирования и необходимости поддержки старых браузеров (в основном по ветке IE).

                              > А код шаблона в коде контроллера говорит о неаккуратности даже в показательном коде.

                              Это Вы про пример создания собственной директивы с визуальной частью? Это, судя по всему, не самая часто используемая и достаточно специфическая фича. А разметку, я думаю, туда впилили для демонстрации и краткости. Честно говоря, не испытывал пока необходимости создания собственных директив. Но сейчас посмотрел в документацию: шаблон можно и асинхронно подтянуть через templateUrl.

                              P.S. Надеюсь, blockquote только в предпросмотре не пашет.
                                0
                                Извиняюсь за дубли, сначала думал, что Опера глючила, добавил коммент черех Хром, потом дошло, почему нифига теги не работают, подождал 5 минут, чтобы добавить ссылку на документацию и по запарке ткнул опубликовать на старый коммент в Опере :)

                                Ссылка на документацию: docs-next.angularjs.org/api/angular.module.ng.$compileProvider.directive
                                0
                                > В шаблонах очень много кастомных тегов
                                За счет кастомных тегов и декларативного описания интерфейса — получаем краткость. Само собой надо в определенном объеме разобраться, но директив немного и система в названиях определенная есть. Да и редко какой новый фреймворк не требует вдумчивого прочтения документации.

                                > а директивы раскиданы и как теги, и как аттрибуты html-тегов.

                                Просто есть несколько вариантов использования директив. Выбор для каждой команды будет зависеть от их предпочтений по стилю кодирования и необходимости поддержки старых браузеров (в основном по ветке IE).

                                > А код шаблона в коде контроллера говорит о неаккуратности даже в показательном коде.

                                Это Вы про пример создания собственной директивы с визуальной частью? Это, судя по всему, не самая часто используемая и достаточно специфическая фича. А разметку, я думаю, туда впилили для демонстрации и краткости. Честно говоря, не испытывал пока необходимости создания собственных директив. Но сейчас посмотрел в документацию: шаблон можно и асинхронно подтянуть через templateUrl.
                              0
                              И для завершения картины, если не сложно, за какую альтернативу голосуете Вы?
                                0
                                На работе мы используем MVC и clojure-подход для создания классов.
                                Выходит что mvc-фреймворка нет и разобраться в коде очень просто.
                                А ведь наша работа заключается не в том, чтобы долго разбираться в коде, а чтобы делать больше нового и полезного, правда? :-)

                                В своих экспериментах я использую Backbone, но в последнее время присматриваюсь к Ember.js
                                Мне симпатичны фреймворки, код которых можно понять не закапываясь в документацию.
                                  0
                                  В порядке обмена мнениями :)

                                  Backbone: если посмотреть на тот же ToDoMVC, то получается интерфейс размазан на 3 части — общая схема интерфейса, пониже шаблоны двух частей интерфейса, в js — описание view и как это все собрать вместе. Имхо, у AngularJS — нагляднее, компактненько в одном месте. И кода меньше, особенно в js.

                                  Ember.js: для шаблонизации там Handlebars, и вобщем-то от кастомных директив мы никуда не ушли: view, collection, contentBinding, itemClassBinding, classNameBindings. И кода JS больше. Он то, конечно, понятен. Но его много надо и написать и потом прочитать. А ведь наша работа заключается не в том, чтобы много писать и долго читать, а чтобы делать больше нового и полезного, правда?" ;-)

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое