Нетрадиционный обзор AngularJS

http://www.letscodejavascript.com/v3/blog/2015/01/angular_review
  • Перевод
Привет, Хабр!

Наш прошлый перевод нетрадиционного обзора React многим понравился, и, конечно, люди стали сравнивать Реакт с популярным AngularJS. Сегодня мы публикуем перевод статьи «An Unconventional Review of AngularJS» от того же автора (Джеймса Шора, ведущего проекта Let’s Code: Test-Driven JavaScript). Поклонникам Angular просьба сохранять спокойствие.



AngularJS это все, что я ожидаю от фреймворка. И это не хорошо.

В ноябре, декабре и январе я обозревал AngularJS для серии «front-end frameworks» в рамках проекта Let’s Code JavaScript. Суммарно я провел 40 часов изучая, программируя и решая задачи. Как обычно, моей целью было изучить AngularJS создавая приложение.

Angular это, наверное, самый популярный фронт-энд фреймворк сейчас. Его разрабатывает команда из Google, что сразу внушает доверие. Он настолько популярен, что входит в акроним. Angular это часть так называемого стека «MEAN»: MongoDB, Express, AngularJS, Node.JS. Самая что ни на есть передовая технология.

Angular описывает себя как инструмент для улучшения ХТМЛ. Он позволяет расширить ХТМЛ новыми определениями — директивами — которые превращают статичный ХТМЛ-документ в динамический шаблон. Директивы могут быть атрибутами или тегами (или даже комментариями или классами, но это уже не совсем обычная история), и они превращают статичный ХТМЛ-документ во что-то живое и дышащее, на первый взгляд без добавления JavaScript.

Лучший пример это знаменитая двухсторонняя привязка данных (two-way binding). ХТМЛ-шаблон может содержать переменные, как большинство языков шаблонирования, но в случае с Angular ваша страница автоматически обновляется при каждом обновлении переменной.

Например, в приложении, которое я писал для обзора, есть таблица, которая изменяется при изменении полей конфигурации. Вот фрагмент кода, который рендерит строку таблицы. Заметьте, тут нет никакой работы с событиями или мониторинга состояния… Просто шаблон, который описывает ячейки в строке. Angular делает все автоматически.

// Copyright (c) 2014-2015 Titanium I.T. LLC. All rights reserved. For license, see "README" or "LICENSE" file.
(function() {
  "use strict";

  var StockMarketCell = require("./stock_market_cell.js");

  var stockMarketRow = module.exports = angular.module("stockMarketRow", [StockMarketCell.name]);

  stockMarketRow.directive("stockMarketRow", function() {
    return {
      restrict: "A",
      transclude: false,
      scope: {
        value: "="
      },
      template:
        '<tr>' +
          '<td stock-market-cell value="value.year()"></td>' +
          '<td stock-market-cell value="value.startingBalance()"></td>' +
          '<td stock-market-cell value="value.startingCostBasis()"></td>' +
          '<td stock-market-cell value="value.totalSellOrders().flipSign()"></td>' +
          '<td stock-market-cell value="value.capitalGainsTaxIncurred().flipSign()"></td>' +
          '<td stock-market-cell value="value.growth()"></td>' +
          '<td stock-market-cell value="value.endingBalance()"></td>' +
        '</tr>',
      replace: true
    };
  });
})();

Магия.

С такими примерами легко понять, почему Angular стал таким популярным. С ним тяжелые проблемы кажутся тривиальными. Но выдержит ли он проверку временем?

Нетрадиционный обзор


Слишком много фреймворков заманивают в ловушку: с ними легко начать, что очень круто, но в последствии очень сложно поддерживать и расширять свой код. Это уже не очень круто.

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

В течение следующих 5-10+ лет, когда я буду поддерживать свой продукт, этот код принесет больше пользы или страданий?

Большинство фреймворков сделаны таким образом, что они экономят время на первичное создание продукта. Но эти затраты тривиальны по сравнению со стоимостью поддержки вашего приложения  на протяжении нескольких лет. Перед тем как рекомендовать фреймворк, я должен знать, что он выдержит проверку временем. Будет ли он расти и изменяться вместе со мной? Или я окажусь в оковах еле-пригодного для работы легаси через три года?

Я смотрю на пять распространенных опасностей.

1. Замкнутость (Lock-in). Когда я решу перейти на новый или более лучший фреймворк (или библиотеку), насколько сложно будет переключиться?

2. Жёсткая архитектура (Opinionated Architecture). Могу ли я решать задачи так, как нужно моему приложению, или я должен повиноваться неким идеям, разработанным авторами фреймворка?

3. Побочная сложность (Accidental Complexity). Я трачу время на решение своей проблемы или борюсь с фреймворком?

4. Тестирование (Testability). Могу ли я просто тестировать свой код, используя стандартные инструменты и без лишней мороки с mock-объектами?

5. Рендер на сервере (Server-Side Rendering). Будут ли люди ждать выполнения JavaScript чтобы увидеть что-нибудь полезное? Придется ли танцевать с бубном чтобы заставить поисковики индексировать мой сайт?

Я оценил Angular в каждой категории с помощью a (уиии!), (буэээ!), or ⚇ (ни туда, ни сюда).

1. Замкнутость — (буэээ!)


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

Это обычная практика. Настолько обычная, что она обычно дает повод поставить meh-рожицу «ни туда ни сюда». Но Angular постарался заработать именно «буэээ».

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

Во-вторых, команда Angular дает нам понять, что стоимость поддержки для них не приоритет. В Angular 1.3 пропала поддержка IE 8. Angular 2 сильно переписали, забыв про несколько ключевых концепций текущей версии. Это скорее всего будет причиной переписать все приложение.

Повторюсь: весь ваш фронт-энд заперт, и даже если ничего не менять, то скорее всего придется переписывать что-нибудь. Переписывать это ужасная идея. Вы потратите кучу денег и времени чтобы повторить то, что у вас уже есть. Фреймворк, в roadmap которого входит идея «переписать приложение» — неприемлем.

2. Жёсткая архитектура — ⚇ (ни туда, ни сюда)


Angular хочет чтобы вы строили свое приложение в определенном формате, но делает это не очень явно. Это скорее «пассивно-агрессивная архитектура».

Жёсткая архитектура это хорошая идея в краткосрочной перспективе, плохая в долгосрочной. В краткосрочной перспективе жесткий фреймворк позволяет начать быстро, не задумываясь о структуре приложения. Но в долгосрочной перспективе слишком жесткая архитектура ограничивает возможности. С ростом ваших требований, стандарты фреймворка начинают мешать вам все больше и больше.

Пассивно-агрессивная архитектура Angular включает худшее из обоих миров. Она делает допущения о дизайне вашего приложения, но она не помогает вам понять эти допущения. Я не уверен что понимаю это даже сейчас, но вот что мне удалось выудить:

«На фундаментальном уровне, Angular считает, что вы используете stateless „сервис“-объекты для логики и простые объекты для структур данных (объекты без методов) для сохранения состояния. Сервисы по сути — глобальные переменные; большинство функций могут использовать любой сервис, обращаясь к ним по особому имени. Структуры данных хранятся в $scope, они связаны с шаблонами и директивами. Объекты структур данных управляются „контроллерами“ („клей“, связанный с шаблонами и директивами) и сервисами.»

Я не фанат такой архитектуры. Отделяя состояние от логики, Angular ломает инкапсуляцию и разделяет тесно связанные концепции. Вместо того, чтобы поместить логику рядом с данными, с которыми она и работает, Angular хочет чтобы вы разнесли логику по всему приложению. Появляется риск «оперирования жертвы дробовика»: любое изменение выливается в кучу мелких исправлений.

Приложение из туториала демонстрирует эту проблему. Приложение выводит на экран список смартфонов, и объекты «телефон» являются ключевой концепцией. В идеале, изменение внутренней структуры объекта-телефона не должно ни на что влиять. Но они просто объекты с данными, так что их изменение повлечет за собой изменения в других частях приложения: шаблон вывода списка телефонов, шаблон вывода информации о телефоне, и оба контроллера для этих шаблонов.

Я предпочитаю rich domain объекты, которые содержат в себе состояние и бизнес-логику. Так я могу делать изменения ничего не ломая. Для моего приложения-примера я использовал rich domain слой, который полагается на неизменяемый объект со значением. Пассивно-агрессивная архитектура Angular не поддерживает этот подход — иногда приходилось деформировать мой код чтобы удовлетворить допущения Angular’а, но это не было совсем уж невозможной задачей. Могло бы быть хуже.

3. Побочная сложность — (буэээ!)


Angular знаменит своей крутой кривой обучения и плохой документацией. Мне кажется это симптомы более крупной проблемы. Это не проблема документации, это проблема Angular. У него просто плохой дизайн. Вот лишь несколько недостатков что я заметил:

Дырявые абстракции. Чтобы использовать Angular в нетривиальном проекте, вам придется влезть глубоко и понять как он работает под капотом. Вам придется понять области видимости и как они работают в рамках прототипного наследования: digest loop; $watch, $watchCollection, и $apply; и еще кучу других штук.

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

Непонятные символы везде. В Angular есть несколько крохотных языков, которые придется вставлять в строки в своем приложении. Готовьтесь изучать разницу между «=», «&», «=*», и «@»; «E», «A», и «EA»; оператором «|»; и другими иероглифами.

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

Склонность к тихому фейлу. Легко ошибиться, сделать что-то не так и не получить никакой индикации причины. Написал «Е» там, где стоило написать «А»? Приложение просто перестало работать.

Когда я писал такое же приложение в первые раз на Реакте, мне понадобилось 28¾ часов. То же самое приложение на Angular я писал 39½ часа, не смотря на то, что я мог использовать часть кода из первой попытки на Реакте. Десять часов сверху. Причина — излишняя сложность Angular.

4. Тестирование — ⚇ (ни туда, ни сюда)


Angular считает тестирование очень важным. Одна из его главных фич — внедрение зависимостей (dependency injection) сделана специально для упрощения тестирования.

Учитывая этот фокус, я был удивлен тем, как все плохо с тестированием в Angular. Оно акцентирует внимание на логике тестирования в контроллерах и сервисах, но не дает почти ничего для тестирования поведения пользовательского интерфейса. Нет поддержки симуляции событий браузера и нет никакой возможности юнит-тестировать ХТМЛ-шаблоны. Кастомные директивы можно тестировать, но тестировать директиву, внутри которой есть другая директива — страшно.

Angular сфокусирован на возможности юнит-тестирования бизнес-логики. Но причина лишь в том, что сама архитектура провоцирует помещать бизнес-логику в UI (в частности, в контроллеры и сервисы). Хорошая архитектура помещала бы бизнес-логику в независимые от UI объекты.

Многие аспекты Angular ощущаются как пластыри поверх нанесенных самому себе порезов.

Убрав бизнес-логику, как это было в случае с моим приложением, остается лишь тестировать как Angular рендерит ХТМЛ и реагирует на события, и Angular не поддержал моего желания сделать это. Команда Angular советует использовать специально сделанный ими end-to-end фреймворк для тестирования Protractor.

End-to-end тесты медленные и хрупкие. Их количество нужно минимизировать, а не рассчитывать на них как на центральную идею стратегии тестирования. К счастью, поместив UI моего приложения в кастомные директивы, я получил возможность юнит-тестировать Angular. Так что он тут заработал нейтральную морду «ни туда ни сюда», но если приглядеться, то можно увидеть на ней одну маленькую слезу.

5. Рендер на сервере — (буэээ!)


AngularJS не рассчитан на работу на сервере. Никаких сюрпризов, но стоит это учесть.

Итог: избегайте его.

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

И в этом отношении все плохо. Angular это сложный фреймворк, и он вырос во что-то странное. Он популярен, но не хорош, и я подозреваю, что он быстро забудется когда появятся более хорошие альтернативы. Angular 2 уже на горизонте, так что принимая Angular сегодня, вы приговариваете себя (скорее всего) к переписыванию приложения через пару лет. И хотя будущие версии могут исправить эти недостатки, сегодняшний Angular это плохой выбор. Избегайте его.
Hexlet 52,04
Практические уроки по программированию
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Похожие публикации
Комментарии 114
  • –6
    … а караван идет.
    • +8
      караван дико форсится, а кому нужно, тот уже давно доехал, пока он идет.
      • 0
        кОрован скорее
        • 0
          Вам, безусловно, виднее.
      • –4
        Непонятные символы везде. В Angular есть несколько крохотных языков, которые придется вставлять в строки в своем приложении. Готовьтесь изучать разницу между «=», «&», «=*», и «@»; «E», «A», и «EA»; оператором «|»; и другими иероглифами.
        Ну это несерьезно… понимание приходит после прочтения документации и ничего в этом сложного нет…
        • +22
          Понимание смысла * в С++ тоже в какой-то момент после прочтения документации приходит, но это не делает процесс понимания простым.
          • +1
            И поэтому С++ не надо использовать?) Как я понял автор статьи ругает ангуляр за «непонятные» символы, а с С++ тогда все ок? или в чем проблема?
            • +1
              В главе с пляшушими человечками обсуждалась сложность изучения фреймворка, а не его практическая польза.
        • +16
          К сожалению со многим вынужден согласиться. Особенно с пунктом 3 — бороться с фреймворком приходится много, даже слишком. Когда только осваивал его, думал, что это просто с непривычки (парадигма-то другая), но опыт (и многочисленные публикации в интернете) показал, что нет — борются с ним все и недовольства много.
          • 0
            С чем конкретно вы боретесь, что вызывает недовольство? Хотя бы пункта три.
            • +11
              God-object в виде angular.
              Совершенно уродский синтаксис директив, с чем связан высокий порог входа для написания директив.
              Фабрики, сервисы — нет единого стиля описания зависимостей в контейнер, опять таки неоправданная сложность. А еще и не все понимают сам DI, так тут еще и запутанная реализация.

              • –10
                God-object в виде angular

                God-object в виде Yii, Rails «впишите тут свой фреймвора» вас также не устраивает?
                Совершенно уродский синтаксис директив, с чем связан высокий порог входа для написания директив

                В чем он уродский? Или вы не разобравшись с compile, pre-link, post-link, scope transclusion, directive controller, controller require решили забить и обозвать его уродским?
                А еще и не все понимают сам DI

                Что там можно «не понять»?! Это дело одной недели.

                Вам надо было просто написать «Ой, все», всего два слова, а смысла столько же.
                • +11
                  Yii? Отвратительный фреймворк. Когда я писал на PHP — использовал Symfony, вот там все в этом смысле сделано прекрасно.
                  В чем уродский? Ну вот вы сами перечислили все эти магические вещи, в которых я достаточно долго и упорно разбирался и уже разобравшись говорю — да, это уродско.
                  Я-то понимаю DI, благодяря использованию Symfony, но я говорю про порог входа. Когда тебе показывают знаменитую вау-и-ах демку, где инпут и h1 связывают прямо в html — думаешь, как же все просто, это то, что я искал. А на деле при попытке написать что-то более серьезное — встречаешь стену из того что я описал и из того, что описано ниже.
                  И да, сбавьте высокомерие, я работаю с ангуляр прямо сейчас и прекрасно вижу его минусы и плюсы.
                  • 0
                    Совершенно уродский синтаксис директив
                    В чем он уродский?
                    Я считаю, что создание директив должно быть ближе к vanilla JS который уже «все» знают, например в Angular Light, чтобы добавить директиву al-test, достаточно написать:
                    alight.directives.al.test = function(element) {};
                    
                    Т.е. просто устанавливаем ф-ию в нужное место, куда будет передан element, с которым можно будет что-нибудь сделать.
                    И для этого не нужно создавать никаких модулей и т.п. А директиву можно установить/удалить в любой момент из любого места.
                  • 0
                    Все так, разработчики это осознают. В angular 2 все иначе делается (но это по сути уже совсем другой фреймворк).

                    Но, тем не менее, серьезных альтернатив пока что нет.
                    • –1
                      Все перечисленное надуманное.
                      • +8
                        Ваша аргументация бесподобна.
                        • 0
                          А что аргументировать, возможно вам просто практики не хватает раз говорите о сложности и не понимании, ну и теории может быть, вам виднее как вы продуктивнее обучаетесь. То есть вы описали не проблемы инструмента, а свои.
                          • 0
                            Многие из перечисленных hell0w0rd проблем активно обсуждались в гугл-группе разработчиков angular при разработке архитектуры angular2. Так что не надуманные. Не настолько критичные, чтобы кричать «angular — дерьмо», как некоторые <irony>фанаты вывернутого наизнанку php</irony> — с ними прекрасно можно жить. Но не надуманные вовсе.
                            • 0
                              Ок, надеюсь любителю обсуждать получат то о чем мечтали в 2.0.
                    • +11
                      1. Фильтры. Совершенно убогий набор фильтров в стандартной поставке, на каждый чих надо писать свой новый фильтр.
                      2. Интероперабельность. Нельзя взять и заиспользовать готовое js-решение (почти на любую задачу оно есть). Надо или искать ангуляр-порт (не всегда хороший) или вдумчиво его оборачивать в ангулярные директивы и страдать.
                      3. Отладка. Где-то что-то поломалось — рухнуло всё приложение и в консоли чистота (если ошибка где-то в шаблоне).

                      В целом мы уже привыкли, набили шишек и вполне неплохо справляемся, но… Разработка идёт жутко медленно.
                      • +1
                        Жутко медленно — по сравнению с чем?
                        Перефразируя вопрос: а на чём разработка шла бы заметно быстрее?
                        • +4
                          По сравнению с «по старинке» — без js фреймворков (и практически без js вообще). Рендеринг на сервере, перезагрузка страницы на каждый чих, вот это всё.
                          • +1
                            Хех, я думал сейчас подискутируем о js фреймворках (vs js-библиотеки может)… а так, да, «по старинке» спору нет. Но эта страница истории уже перевёрнута.
                            • +7
                              Я думаю, что нет, не перевёрнута. Для информационных сайтов фреймворк типа Ангуляра не нужен. Потому что индексация поисковиками и вообще оверкилл. В веб-приложениях для всяких CRUDов это тоже оверкилл (хотя там-то проблем с ангуляром не возникает). И только на некоторых страницах с очень сложной логикой (типа GUI-редактора чего-нибудь, где надо двигать плашки по пространству) он себя оправдывает.

                              Мне кажется, что таких монстров надо держать в «клетках», т.е. внутри веб-компонент каких нибудь изолированных и не давать им властвовать над всем документом. Как-то так.
                              • 0
                                Вот мы делаем редактор hexlet-ide, он полностью построен на reactjs/flux и мы довольны как слоны). Кстати, atom гитхаба, насколько мне известно, тоже мигрирует на reactjs.
                                • 0
                                  Забавно. На чем он был написан, на ангуляре?
                  • +27
                    Angular сложноват. Я уже почти год использую его в небольшом проекте, но понимания все равно нет. Взять фабрики и сервисы. Читаешь доки, вроде делают одно и то же, отличаются самую малость. Зачем плодить сущности? Так и живу — пишу код на Angular, вроде все работает, но ни хрена не понимаю.
                    React не использую, но когда-то прочитал небольшой обзор и все было понятно.
                    • +1
                      согласен. Непонятно, слишком много сущностей, избыточно много. И непонятно, что брать
                      • –2
                        Как можно за год его не понять??? Пусть я буду заминусован, но что-то с вами не так…
                        • +7
                          Вижу юношеский максимализм.
                          Я нигде не сказал, что я его изучал год. Периодически использовать и постоянно с чем-то работать — разные вещи.
                          В силу возраста какие-то вещи схватываются хуже, поэтому хочется простого и понятного инструмента, а Angular, по моей шкале, к таким инструментам не относится. Я изучил его ровно настолько, чтобы использовать его в нужных мне объемах, а ковыряться в нем дальше у меня желания нет.
                          • –1
                            А что Вы считаете простым и понятным инструментом? парочку примеров
                            • +1
                              MeteorJS например. Периодически что-то делаю на AngularJS, но каждый раз получаются какие-то костыли, как по мне. Ковыряться тоже желания нет
                              • 0
                                У меня такая же ситуация с Angular. Полгод разрабатываю на Angular и до сих пор есть проблемы с service — factory — provider, со скопом директив, с банальным реюзом методов моделей. Да и с производительностью у него не ахти, я не нашел ни одного хорошего примера бесконечного списка, уже на 1000-1500 позиций большинство начинает безбожно тормозить. Тот же ng-repeat для больших таблиц с часто меняющимися данными не вариант. А когда приходится разбирать чужой код, там вообще финиш потому, что одни и те же вещи можно сделать очень разными способами и если не следить за псевдо глобальными переменным в rootscope получается страшная лапша.
                                • +2
                                  оффтоп

                                  не нашел ни одного хорошего примера бесконечного списка, уже на 1000-1500 позиций большинство начинает безбожно тормозить


                                  Посмотрите как это реализовано в Ionicframework ionicframework.com/blog/collection-repeat/
                              • +1
                                jQuery например.
                                Я с новыми технологиями не работаю, но интересуюсь. Аналогичная ситуация складывается во многих сферах. Возьмем языки программирования. Где-то я понимаю практически всё не зная языка (например, Go), а если смотрю на современный С++, то мне становится страшно, хотя в 90-х активно писал на нем. Мне кажется развитие должно идти в сторону упрощения и понижения порога входа, а получается как-то наоборот.
                                • –2
                                  Как можно сравнивать «либу-расширение» (jQuery) и полноценный фреймворк?

                                  Я в ангуляре разобрался за неделю. Может вы не там ищете? Я не спорю что сидя над одной документацией с офф сайта вы станете гуру быстро, но взять даже codeschool или Egghead с youtube
                                  • +2
                                    Просто мне хочется от фреймворка такой же простоты, как в jQuery. Ну ладно, накладывается связь данных с DOM, асинхронность, но почему это настолько всё усложняет?
                                    У нас спор с вами ни о чем, так как разговариваем немного о разных вещах.
                                    • +5
                                      Так jQuery это простой набор методов и эвентов и ВСЕ. Я и спрашиваю как можно сравнивать 2 разных вещи? Это тоже самое что сказать Paint такой легкий — взял тыкнул карандаш и рисуешь, а Photoshop — там еще слои какие-то создавать надо и перемещать их можно — очень сложно.

                                      Я не понимаю что такого сложного в Ангуляре? Минимум понимания для нормальной работы с ним это:
                                      — в контроллерах храним чистые данные и обработчики
                                      — в директивы выносим работу с DOM элементами и навешивание тех же jQuery плагинов
                                      — сервисы как хранилища или конструкторы

                                      Самый простой вид SPA:
                                      — в конфиге полотно роутов
                                      — для каждой страницы свой контроллер
                                      — в контроллерах запрос данных через рест
                                      — в хтмл вывод данных через директивы встроенные

                                      Возможно сложно понять ангуляр тем кто не фронтендер? потому что кто его понимает — это рай для быстрой разработки.
                                      • 0
                                        — в контроллерах храним чистые данные и обработчики

                                        Что подразумевается под обработчиками? Если речь о бизнес логике, то это не очень хорошее решение.

                                        — в директивы выносим работу с DOM элементами и навешивание тех же jQuery плагинов

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

                                        — сервисы как хранилища или конструкторы

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

                                        Самый простой вид SPA:

                                        Статья как раз о том, чтобы делать и поддерживать сложные SPA. С простыми проблем нет, и автор специально подчеркивает этот момент.
                                        • 0
                                          Иногда jQuery плагин удобнее навешивать после загрузчки данных, когда уже произошла линковка директив и отработал контроллер. Тут надо исхитряться.
                                          Приведите пример. Очень интересно что за случай такой где плагин не может навеситься раньше чем отработает контроллер (если я правильно понял что в это проблема)

                                          Статья как раз о том, чтобы делать и поддерживать сложные SPA. С простыми проблем нет, и автор специально подчеркивает этот момент.
                                          В данной ветке сообщений обсуждается непонимания ангуляра вцелом, я привел пример самого просто СПА как вопрос «что тут понимать?»
                                          • 0
                                            Пример плагина: github.com/fengyuanchen/cropper

                                            Если изображения нет, то он неправильно инициализируется, поэтому удобно навешивать его после того, как ангулар загрузит данные об изображении.

                                            В данной ветке сообщений обсуждается непонимания ангуляра вцелом, я привел пример самого просто СПА как вопрос «что тут понимать?»


                                            В простом случае все понятно, но это не опровергает того, что ангуляр сложный, непонятный, запутанный фреймворк.
                                            • 0
                                              Что мешает сделать так с плагином: jsfiddle.net/U3pVM/12840/
                                              • 0
                                                Это хороший пример.
                                                Но ломается, когда сначала задать дефолтовое изображение для которого не нужен кроппер, а потом поменять. В итоге я должен учитывать, когда выполняется директива и на что реагирует. Все это решаемо, но создает сложности.
                                                • –1
                                                  Простите, но, имхо, вы только и говорите «это создает сложности» постоянно, а не ищете решение. Опишите конкретную задачу, которая вам кажется нерешаемой — я и ее решу…
                                                  • +1
                                                    Я ищу решения, но иногда проще поменять фреймворк, чем постоянно искать решения. Хорошо, что пока я не видел нерешаемых с помощью angular проблем, поэтому и использую.
                                              • 0
                                                ЗЫ сам невнимательный забыл $('img') заменить — вот верный вариант jsfiddle.net/U3pVM/12842/
                          • +26
                            Его разрабатывает команда из Google, что сразу внушает доверие.


                            Лично у меня это вызывает опасение, что его бросят при очередном сезонном обострении.
                            Я один такой?
                            • 0
                              Скорее всего не бросят, пока альтернативу не родят.
                              • 0
                                Сделали и активно продвигают как «фреймворк будущего» www.polymer-project.org/
                                • –1
                                  Polymer — это их реализация реакта, тк реакт, полимер, директивы ангуляра — это все недо-вебкомпоненты, которые уже будут вот-вот и останется кусок пирога у тех, кто будет иметь возможность компилировать текущий код в веб-компоненты.
                                  • +3
                                    Эмм, нет.
                                    Полимер работает поверх «честных» компонентов, это что-то типа lodash для компонентов — удобная обертка, дата-биндинг и еще пара прелестей жизни.
                                    И еще полифиллы.
                              • +11
                                Почитайте тему AngularJs 1.3 vs 2.0 и поймете всю боль ситуации. Повод задуматься:
                                * Ушел создатель Ang из Google и вернулся в Durandal
                                * 2.0 будет полностью переписан и ничего общего с 1.3 иметь не будет, как мигрировать неизвестно
                                * Будут распылять свои силы между поддержкой AngularDart, 1.3 и 2.0…
                                • +1
                                  AngularJs 1.3 vs 2.0 — действительно боль, но не всё так страшно
                                  * Ушел Роб Эйзинберг, вернувшись к своему старому начинанию — ещё ничего не значит. Может он просто устал, есть свои идеи, хочется чего-то свежего. Команда Ангуляра от этого не исчезает и там много сильных профессионалов.

                                  * 2.0 полностью переписан и не понятно как мигрировать с 1.3 — действительно так. Но представим себе, что это просто новый фреймворк! Мы же не жалуемся, что мигрировать между Angular и React тяжело — разные фреймворки, каждый со своими фишками. Вопрос в том, на сколько эти фишки заманчивы, чтобы начать новый проект на Angular 2.0 или даже взять и переписать старый с нуля? Посмотрим. Верим, надеямся, ждём…

                                  * Будут распылять свои силы между поддержкой AngularDart, 1.3 и 2.0…
                                  AngularDart существовал и во времена 1.x и это «распыление» не мешала двигаться от 1.1 к 1.2 и к 1.3. Напротив, как писали разработчики в своём блоге, опыт с AngularDart их многому научил и какие-то идеи они портировали обратно в AngularJs.

                                  Что действительно пугает: поддержка 1.3 может станет минимальной (например, гугловцы захотят форсировать этим повсеместное использование 2.0) и тогда миллионы проектов написанных на Angular 1.2 и 1.3 окажутся в неприятной ситуации. В а в заголовках описаниях вакансий мы увидим «Требуется разработчик Angular 1.3» или "… Angular 2.0". В итоге всё может получиться как с Python 3 или Perl 6.

                                  Ещё не понятно как гуглить вопросы/ответы/обсуждения касающиеся какой-то определённой версии Angular, если будут два активных коммунити с разными фреймворками, но одинаковым ключевым словом «Angular».
                                  • 0
                                    Эйзенберг не устал, просто решил своё делать, так, как он хочет, только недавно выпустил новый фреймворк Aurelia — eisenbergeffect.bluespire.com/introducing-aurelia/
                                    • +3
                                      * 2.0 полностью переписан и не понятно как мигрировать с 1.3 — действительно так. Но представим себе, что это просто новый фреймворк! Мы же не жалуемся, что мигрировать между Angular и React тяжело — разные фреймворки, каждый со своими фишками. Вопрос в том, на сколько эти фишки заманчивы, чтобы начать новый проект на Angular 2.0 или даже взять и переписать старый с нуля? Посмотрим. Верим, надеямся, ждём…


                                      Так и получается, если мыслить категориями 5-10 летней разработки(поддержки) сложного проекта, то риски переписывания всего приложения с нуля (например, с выходом нового фреймворка новой версии Angular) подтверждают резюме автора :)
                                      • +3
                                        Но представим себе, что это просто новый фреймворк! Мы же не жалуемся, что мигрировать между Angular и React тяжело — разные фреймворки, каждый со своими фишками.


                                        Что автоматически означает, что вы работаете с продуктом, который развиваться уже не будет и так или иначе нужно переписывать все заново — бизнес, зачастую, такого не понимает. Это никак нельзя сравнивать с миграцией на новую версию фреймворка XYZ. А актуализация инструментов, как мне кажется, жизненно необходима для поддержания приложения, эксплуатация которого планируется более-менее долгое время.
                                        • 0
                                          > Будут распылять свои силы между поддержкой AngularDart и 2.0

                                          Angular2 поддерживает и ES6 и Dart. Уже можно посмотреть: github.com/angular/angular/
                                          • +1
                                            1.3 может станет минимальной

                                            Вряд ли. Судя по трекеру на гитхабе — будет как минимум 1.4 и 1.5.
                                      • +7
                                        40 часов на изучение Angular-а — это очень мало, имхо. И не согласен с тем, что жесткая архитектура — это зло. Мне вот кажется, что Angular недостаточно жесткий. Сколько было статей на тему «самая правильная структура проекта Angular». Вообще текст в стиле «не читал, но осуждаю».
                                        • +15
                                          40 часов на изучение Angular-а — это очень мало, имхо.

                                          Кажется, это само по себе минус ангуляра.
                                          • +2
                                            На мой взгляд, в javascript-мире царил хаос до появления Angular. Любой мало-мальски крупный проект вырождался в тонны лапши. И ни один фреймворк до Angular-а этой проблемы не решал. Вы скажете, а как же Backbone? Backbone — это просто поделка по сравнению с Angular-ом. Если вы когда-нибудь писали что-нибудь крупное на Backbone, то, конечно, знаете о том, что не очень-то он подходит для этого. 40 часов — это много? Ну тогда продолжайте варить лапшу.
                                            • +2
                                              Вы скажете, а как же Backbone? Backbone — это просто поделка по сравнению с Angular-ом.

                                              Извините, кажется, я не готов поддерживать заданный уровень дискуссии ;-)
                                              • +1
                                                > Если вы когда-нибудь писали что-нибудь крупное на Backbone, то, конечно, знаете о том
                                                … что на базе Backbone сделан фреймворк Marionette как раз для этих целей.
                                                • 0
                                                  Ну да, Chaplin туда же… а может еще что-то выдумали. Это говорит лишь о том, что сам по себе Backbone слабоват.
                                                  • 0
                                                    Backbone не слабоват, это всего лишь библиотека. Поэтому некорректно сравнивать его с фреймворками типа Angular. Точно также можно сказать, что jQuery как фреймворк никакой. Все верно — потому что это не фреймворк. Marionette — уже фреймворк, весьма зрелый и мощный.
                                                    • 0
                                                      Ну как это Backbone не фреймворк? ОК) Пусть будет библиотека, реализующая паттерн MVC. Но не фреймворк!)
                                                • 0
                                                  Яндекс использует Backbone во многих своих проектах со сложным фронтендом. Не сказал бы что эти проекты не крупные и насколько я понял когда был на их последнем митапе, они им очень довольны.
                                                • –1
                                                  Очевидно, что эта статья — часть пиара ReactJS.
                                                • +1
                                                  40 часов для человека, который хорошо владеет js и современными паттернами фронтенд-разработки мало? Тогда наверное ангуляр действительно сделан неоправдано сложно.
                                                  • 0
                                                    Человек, владеющий «современными паттернами фронтенд-разработки», но который не знает Angular)
                                                    • +5
                                                      Вполне нормальная ситуация, по-моему
                                                • +11
                                                  В статье много здравых мыслей. Но некоторые суждения явно следуют лишь из того, что автор работал с ним всего 40 часов.
                                                  Например:
                                                  Когда я писал такое же приложение в первые раз на Реакте, мне понадобилось 28¾ часов. То же самое приложение на Angular я писал 39½ часа, не смотря на то, что я мог использовать часть кода из первой попытки на Реакте. Десять часов сверху. Причина — излишняя сложность Angular.
                                                  Ангуляр действительно сложнее, чем Реакт. Но попробуйте написать не первое приложение, а десятое, и окажется, что на Реакте вам всё ещё требуются условно 20 часов, а на Ангуляре справитесь за 5!

                                                  Тупо разница в объёме кода: на Реакте кучу всего придётся написать ручками (опять и опять и опять, если только не начнёте использовать какую-то высокоуровневую абстракцию поверх Реакта), а в Ангуляре достаточно будет воспользоваться магическими иероглифами «=», «&», «=*», и «@»; «E», «A», и «EA», так критикуемые автором, которые к десятому проекту вы уже выучили.
                                                  • +4
                                                    Полностью согласен. Решил попробовать React для простой формочки. Пришлось такую портянку для валидации написать, что мама не горюй. А в Ангуляре это делалось бы парой строк, только потому что там уже много чего встроено.
                                                  • +1
                                                    Отлично, всё в точку!

                                                    А такого же про Ember.js нету случайно?
                                                    • 0
                                                      В блоге Джеймса Шора аналогичной статьи про Ember пока нет, но в комментариях его просили он обещал!
                                                    • +1
                                                      Статья слабенькая. Все фреймворки по определению обладают этими недостатками.
                                                      • 0
                                                        Backbone?.. ах да, он же не фреймворк, он либа…
                                                        • 0
                                                          какая же backbone либа? есть роутер, вью. либа это underscore, jquery. backbone — скелет, в вольном переводе. и он обязывает к определённому дизайну кода.
                                                          • 0
                                                            Не «скелет» а «хребет». И не обязывает а предлагает. В нём можно как быстренько наговнокодить html-ом и попапами в моделе, так и задать аттрибуты для вью. Кроме того — другой код спокойно интегрируется в проект на backbone, например тот же $.ajaxPrefilter для глобальной обработки ошибок. Я уж не говорю о том что можно спокойно переписать любой метод под нужды конкретного проекта.

                                                            А роутер — что роутер? Всё что он делает это вызывает инициализацию конкретных кусков кода или делает конкретные вещи. RequireJS и тот больше работы делает.

                                                            От «дизайна» кода останется только специфичный вариант работы с данными через сеттеры/геттеры да надстройка над ajax-запросами. Но эти вещи всёравно будут в любой современной фронтовой либе или фреймворке.
                                                            • +1
                                                              Согласен. И на освоение Backbone нужно часа 2 — за это время он уже становится понятным.
                                                              Ну, а возможность переопределить поведение любого метода да и вообще чего угодно — это несомненно здорово. Например меня не устраивала логика работы модели и того, что она возвращала через previousAttributes(), переписал нужное, и переопределил прототип модели глобально.
                                                              Так же и с добавлением WebSocket в качестве транспорта — не сказать, что совсем без проблем, но ничего сложного.
                                                            • 0
                                                              > есть роутер, вью

                                                              Это отдельные компоненты. Из них как из легко можно сложить каркас приложения, состыковав. А можно не складывать, использовать по отдельности. Например, router может быть не нужен. Или можно отдельно взять модель.

                                                              > и он обязывает к определённому дизайну кода

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

                                                              Может быть вы приведете пример дизайна кода, к которому обязывает backbone по вашему мнению?
                                                        • 0
                                                          «На фундаментальном уровне, Angular считает, что вы используете stateless „сервис“-объекты для логики и простые объекты для структур данных (объекты без методов) для сохранения состояния. Сервисы по сути — глобальные переменные; большинство функций могут использовать любой сервис, обращаясь к ним по особому имени. Структуры данных хранятся в $scope, они связаны с шаблонами и директивами. Объекты структур данных управляются „контроллерами“ („клей“, связанный с шаблонами и директивами) и сервисами.»


                                                          Вы зачем это в дополнительные кавычки взяли? Я уж испугался, что автор обзора это откуда-то цитирует и что это из документации AngularJS.
                                                          • 0
                                                            Легко бы перешёл на другой фреймворк, в котором есть двойной дата-биндинг, валидация форм, роутер. В котором поддержка больших приложений не превращается в боль и более аккуратная архитектура. И можно прикрутить webvisor.
                                                            • +1
                                                              Как насчет Kendo Framework?
                                                            • +3
                                                              Использовал ангуял в 6 проектах разной степени сложности. В последних перешал на angularjs + coffeescript. Все модели, вся бизнес логика, сервисы и т.д. описывается обычными классами на кофе, которые, при использовании nodejs, могут также использоваться на сервере.

                                                              class Resizer
                                                                constructor: (@$q)->
                                                                createImg: (urlData)->
                                                                resize: (doc, img, width, height)->
                                                                makeBlob: (doc, canvas, width, height)->
                                                                putImageToCanvas: (doc, img, width, height)->
                                                                resample_hermite: (canvas, W, H, W2, H2) ->
                                                              


                                                              После чего, при необходиости врапим, или используем на прямую.
                                                              services.service 'Resizer', ['$q', Resizer]
                                                              


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

                                                              Если нет страха перед перездом можно использовать ng-classify с ним код еще чище.
                                                              • 0
                                                                Точно так же, обычными классами, можно писать и без кофескрипта (если кто, как и я, недолюбливает его синтаксис). Любая «классическая» реализация «классов на прототипах» подойдет.
                                                                • 0
                                                                  Зависимости для внедрения можно определять прямо в классе сервера:

                                                                  class sys.Service
                                                                  
                                                                    @$inject: ['$log', '$http', '$q']
                                                                  
                                                                    constructor: (@log, @http, @q) -> 
                                                                      @log.debug("sys.Service - ok")
                                                                  
                                                                • +2
                                                                  Перешел на ангулар чуть больше, чем пол года назад с ванилла жс на классах + requirejs + jquery. За неделю чтения официальных доков и просмотра видео от egghead стало всё ясно-понятно. Проблемы или вопросы безусловно возникали, но быстро решались на стэковерфлоу.

                                                                  Занимательный факт, что я заметил. Ангулар обычно хают люди, которые:
                                                                  * не имеют большого опыта программирования на чистом js и ждут какой-то магии или супер-простоты от инструмента, что он, видимо, должен решать проблемы и архитектуры и языка и вообще, я просто сейчас нафигачу по-быстрому, а как оно дальше будет жить потом разберемся
                                                                  * не дочитав до конца доки и не поняв ключевые аспекты начинают городить костыли/лапшу/говнокод
                                                                  * те, кто привык к лапше на джиквери, пишут лапшу на ангуляре, ни какой фреймворк или библиотека не решит проблему личного отношения к коду, не закладывая сразу пути для его более легкого масштабирования и поддержке

                                                                  image
                                                                  • +5
                                                                    если честно, то учитывая высокоуровневость сегодняшних технологий, то да, я ожидаю, что фреймворк будет за меня решать какие-то проблемы и архитектуры языка. тот же React сам следит за DOM, как пример. он же умеет рендериться на сервере, что решает одну из проблем клиентсайда — доступность инфы поисковикам. так что да, на сегодняшний момент сообщество имеет возможность из всех инструментов выбирать лучшие.

                                                                    позиция «вы ещё на чистом js не писали» никуда не годится. давайте серверные приложения писать на ассемблере? а потом такие придём в современный .net, например и будем не понимать, чего это кто-то вообще возмущается, тут же вона одну функцию пишешь и не надо работать с регистрами. и опять же: да, я ожидаю от инструмента супер простоты и магии. для примера возьмите тот же React. virtual dom — чем не магия?
                                                                    • +2
                                                                      Ух ты, дожил! js назвали ассемблером!
                                                                      • 0
                                                                        Разные фреймворки для разных целей. Вы не думали что рендеринг на клиенте в некоторых случаях это преимущество? Что мешает от сервера получать «голые» данные, а статику рендерить из $templateCache? Это можно также сказать «ложкой можно суп есть, а вот вилка почему-то не отвечает моим требованиям»…
                                                                      • +2
                                                                        Занимательный факт, что я заметил. Ангулар обычно хают люди, которые

                                                                        Безапелляционненько как-то. Есть люди которые просто нашли более _эффективный_ (результат\время) фреймворк для своих задач. И с высоты своего опыта, прошу прощения за высокий штиль, недоумевают почему ангулар присвоил себе звание «серебряной пули».

                                                                        Я, например, считаю что в фундаменте ангулара(1.х) лежит серьёзный компромисс. Давайте у нас всё будет работать не так быстро как могло бы ( а иногда и откровенно умирать, признаемся честно), но это ничего — зато мы всё круто зарегулируем и стандартизуем. Это пахнет «программизмом для программистов», а не для конечных пользователей. Процессом ради процесса. Да, для каких-то задач ангулар — отличный инструмент. Но не для всех. И даже не для 90%. Это один инструмент из многих — есть молоток, а есть шуруповёрт.

                                                                        Теперь можете рассказать мне что я не имею большого опыта программирования на vanillajs и далее по тексту. Только перед этим расскажите с какими фреймворками(кроме ангулара) вы реально работали, щупали руками и применяли на практике.
                                                                        • 0
                                                                          Я не восхваляю ангулар до небес :) Он хорош для большинства SPA/REST приложений, не так сложен, запутан и непоследователен, как тут плачутся многие. Да, конечно это инструмент и каждый вправе выбирать себе свой молоток и это хорошо.

                                                                          По поводу производительности, тоже проблем не замечал, если не пихать кучу бесполезного хлама в скоуп и юзать милиард вотчеров. Даже на самом быстром фреймворке всегда можно написать тормознутое говно.
                                                                          • 0
                                                                            Я считаю что angular абсолютно последователен и совершенно логичен в рамках выбранной дата-драйвин концепции.
                                                                            Но это не отменяет проблем его реализации — вербозность и «тоталитарность», если вы понимаете о чём я.
                                                                            Фиг с ней с вербозностью — хотя это вполне себе бессмысленные временные затраты, но вот «тоталитарность» гораздо злее. Высшим злом любого фреймворка я считаю ситуацию, когда его внутренние проблемы с формулировкой «вам это не надо», всплывают наверх через весь продукт, к конечному пользователю. И «вам это не надо» приходится говорить уже пользователю («все равно его не брошу потому что он хороший»). Или отказываться от такого фреймворка :)
                                                                      • +3
                                                                        Вставлю несколько слов о «жестких рамках» в которые нас вставляет Ангуляр. Когда-то одна команда встала перед выбором — что взять для нового проекта? Потенциально большого. Решили — в интернете полно решений для всего:
                                                                        • нужны модули? require.js
                                                                        • нужны роуты? Crossroads.js
                                                                        • нужны темплейты? underscore.templates
                                                                        • нужны тесты? mocha+chai


                                                                        И всё шло хорошо. Пока в команде было 2 разработчика. Было много code review, всё писалось в едином стиле. Но вот появляется новый разработчик. Он пишет немного по другому. Потом четвертый. Теперь все пишут по-своему.
                                                                        Это первая проблема — когда рамки в проекте держатся только на code review и уровне программиста.

                                                                        А вот вторая проблема — появляется новый программист. Совершенно новый. Теперь ему надо въезжать во все эти велосипеды. В случае, если б это был Ангуляр, HR отдел бы искал js-angular программиста и он бы въехал в проект гораздо быстрее.
                                                                        • 0
                                                                          С этой точки зрения еще интересен и перспективен ember.js
                                                                          • +1
                                                                            Рассматривайте мой комментарий как комментарий в защиту полноценных фреймворков. Ember сюда так же подходит, но, как мне кажется, у него рамки «слабее» и наработанное комьюнити поменьше.

                                                                            P.S. Кстати, framework — рамка-работа. Всё сходится :)
                                                                        • –1
                                                                          Не согласен с 3м пунктом статьи полностью. Во все времена какой бы фреймворк не юзал, если ты не имеешь представления как оно устроено и работает внутри, кашу не сваришь. Однотипные задачи научишься писать и всё. А вещи оптимизация приложения, и прочие просто отправляются на свалку с таким подходом. Раньше народ который писал на первобытных сях и прочем имея казалось бы хороший высокоуровневый язык, всё равно задумывался о выравнивании структур компилятором, и том сколько байт считывает за раз контроллер диска и тд и тп. Так что «побочаня сложность» в данном случае равна «мне лень это понять». Наверно в наши дни это одна из причин почему железяки становятся всё мощнее, а приложения под них как медленно работали, так и продолжают.
                                                                          • +1
                                                                            По сути минус только один, могут забросить поддержку 1.х после входа 2.х, а мигрировать будет не реально тк 2.х по сути будет новый фреймворк. Остальное надуманное.
                                                                            • +1
                                                                              Обещают же 2 года после выхода версии 2 продолжать поддержку версии один. Это учитывая еще, что до релиза второй версии минимум год. Итого — три года развития текущей ветки. Вполне хватит. Что было три года назад?
                                                                              • 0
                                                                                Вполне хватит на то, что бы съехать на что-то, что не умрет по истечении этих трех лет?
                                                                            • 0
                                                                              Почитал… подумал… Авто пишет — избегать по возможности. Но встаёт вопрос — а что тогда использовать?
                                                                              Я сейчас использую js + Knockout js в проектах. Но knockout'a стало не хватать. Кто подскажет, куда теперь посмотреть? Выбирал между AngularJS и BackBoneJS… Теперь и не знаю…
                                                                              • +1
                                                                                Так react же (в начале поста ссылка на такой же обзор про реакт). Его многие недооценивают и самое главное не понимают. Он работает принципиально не так как остальные фреймворки. Вместо 2-way data binding (без которого многие не представляют как вообще можно работать), reaсt предлагает 1-way data flow. Этот подход надо прочувствовать. Вот тут все рассказано github.com/facebook/flux.

                                                                                Я уже выше писал в комментариях, у нас в hexlet.io на react/flux написана облачная IDE и простым это приложение не назовешь. Можно посмотреть: github.com/Hexlet/hexlet-ide.
                                                                                • 0
                                                                                  Пытался я к нему присматриваться… " раза пытался на него серьёзно посмотреть, но не могу, не нравится мне он. Как увижу возвращение кусков вёрстки в нём… Он нарушает моё чувство прекрасного ) Не нравится мне этот подход.
                                                                                  • +2
                                                                                    Как я уже говорил, реакт это совершенно другая идеология. JSX это не верстка, это всего лишь обертка для более простого визуального восприятия. На самом деле оно компилируется в js код, если уж так хочется то можно сразу в js коде писать. Все дело в том что реакт работает с виртуальным домом, и вот это не просто прекрасно это революция в вебе. Посмотрите вот эту статью habrahabr.ru/post/217295/
                                                                                    • 0
                                                                                      Если по простому, то в реакте приложение генерируется полностью заного на каждое изменение. Основной смысл каждого компонента вернуть новый virtual dom. Дальше реакт делает diff с предыдущим состоянием и очень хитро производит изменения в реальном доме, таким образом чтобы сократить количество обращений до минимума. Эта техника приводит к очень серьезному ускорению, потому что virtual dom это всего лишь структуры данных на js которые работают чертовски быстро, а обращения к реальному дому это самое медленнное в работе js фреймворков. Так вот реакт не просто быстр, он фантастически быстр и еще он совсем другой. Его нельзя оценивать через призму обычных подходов, потому что его подходы революционны, а не эволюционны.
                                                                                      • 0
                                                                                        Спасибо за ссылку. Посмотрел.
                                                                                        Как я понял React — это всё равно не фулстэк фреймворк, как я понял, он только для UI. Поправьте, если я ошибаюсь. А проблем со скоростью я пока и на knockout не встречал.
                                                                                        • 0
                                                                                          Я не очень понимаю когда говорят «не фулстек», вот мы на нем делаем сложные приложения и фактически ничего дополнительного не используем. Только бекенд дописываем, но в таком случае ни ангуляр ни кнокаут тоже не фулстек, потому что у них тоже нет бекенда ;), в отличие от, скажем meteor.

                                                                                          Единственное это роутер, в реакте он идет не из коробки пока, но есть очень клевое популярное решение. И насколько я понял разработчики фейсбука уже общаются с теми кто делает этот роутер и возможно его включат.
                                                                                  • +2
                                                                                    Чего вам стало не хватать в нокауте?
                                                                                    • 0
                                                                                      По большому счёту всё устраивает… Не совсем корректно выразился. На Angular позарился из-за модульности из коробки, директив…
                                                                                      • 0
                                                                                        Просто лично я уперся в отсутствие «асинхронных шаблонов» изкоробки и возможности сгенерировать viewport где мне надо и как мне надо.
                                                                                        Но это в принципе решилось построением архитектуры приложения и парочкой bindingHandler
                                                                                      • 0
                                                                                        Я в свое время перешел с Knockout.js на Angular.js, тут описал некоторые преимущества второго.
                                                                                    • +2
                                                                                      Да уж, прям таки обнажена вся боль ангуляра :)
                                                                                      Но вот с чем действительно трудно спорить, так это с концептуальными заслугами этого фреймворка.
                                                                                      Новые парадигмы front-end разработки, привнесенные этим шедевром сложно недооценить.
                                                                                      Бесспорно, у того же polymer.js есть все шансы прийти на смену ангуляровским директивам, двустороннее связывание сейчас тоже много где внедрено, шаблонизаторов разных валом на любой вкус и в принципе каждый волен определиться с наиболее удобной для себя подборкой инструментов, но я все равно благодарен ангуляру за то, что он все же приоткрыл мне глаза на новые для меня концепции в программинге.

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

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