Да там хрен уйдеш от грязной проверки.

Авторам ангуляра можно было поиграться с сеттерами defineProperty. Но Watcher непосредственно из сеттера defineProperty дергать не вариант. Так как в случае присваивания свойств в цикле, сеттеры дернут watcher столько раз сколько будет итераций в цикле. К слову set() в extJs аналогично будет генерить события для каждого вызова set. Сейчас благодаря отсутствию сеттеров можно вытворять со скопом все что угодно, а потом опубликовать изменения одним махом при помощи digest.

Второй вариант использования сеттеров defineProperty заключается в регистрирации сеттерами в каком нибудь массиве изменившихся свойств. Затем в момент вызова digest можно бы было публиковать только рекомендованные сеттерами свойства. Однако похоже что быстрее просто сравнить новое значение свойства со старым значением, чем тратить время на работу геттеров/сеттеров. Только представьте сколько времени сожрут геттеры/сеттеры вызываемые при использовании скопа внутри цикла.

На мой взгляд сравнение нового значения со старым это самый оптимальный подход.

а вот watchСollection это медленная штука.
Изменение большого массива который еще и наблюдается целиком это пиздец, ангуляр каждый элемент в массиве при публикации проверит чтобы найти измения.
из исходников

// copy the items to oldValue and look for changes.
            for (var i = 0; i < newLength; i++) {
              if (oldValue[i] !== newValue[i]) {
                changeDetected++;
                oldValue[i] = newValue[i];
              }
            }

1й) не прятный момент это перебор массива но без него ни как. Если мы наблюдаем весь массив целиком то нам важно любое изменение.
2й) неприятный момент это то что watchcollection всегда имеет копию наблюдаемого массива oldValue со старыми значениями, что было с чем сравнивать. Тобиш расходуется память в двойном размере.

Ище одна жопа в том что цикл нельзя прервать при первом обнаруженном изменении так как нужно скопировать все значения в oldvalue. Получается в любом случае массив придется перебрать целиком.

к слову обьекты наблюдаемые целиком он тоже перебирает.

За исключение watchcollection все реализовано потрясно, что касается watchcollection то не уверен что можно придумать что то лучше.

Полностью на Ангуляре не стал бы делать интернет-магазин. По-крайней мере еще пол года - год, пока не запилят генерацию html на сервере и с SEO чуть понятней не станет.

Но отдельно на страничках, особенно в админке, ему самое место.

Как относитесь к этой статье? https://moot.it/blog/technology/fram...avascript.html Человек не понял где стоит использовать Angular-подобные, а где нет? Или это и правда мода с сомнительной ценностью для большинства приложений?

Умные люди начинают пользоваться фреймворками когда перестают устраивать стандартные средства.

Сначала jQuery помогает в простейших операциях избегать кучи кода и учит организовывать код (плагины).

Потом jQuery становиться мало, потому что код превращается в пухлый ком, в котором очень сложно разобраться. На помощь приходят AMD, require.js и подобные фреймворки, которые помогают структурировать код. Разбить его на отдельные логические (и функциональные) модули.

Потом человек привыкает к фреймворку и то, что раньше делалось простым js начинает делаться с помощью "любимого" фреймворка.
Об этом и статья. Что всегда нужно смотреть, где необходим фреймворк (типа Angular), где достаточно библиотеки (типа jQuery), а где можно писать на чистом js.

Однако вся эта демагогия хорошо работает до поры до времени. Если есть команда, если команда работает с конкретным фремворком, то лучше его использовать во всех проектах, чем в каждом проекте иметь свой фреймворк, свою структуру и т.п. Так как всё это влияет на стиль кода (соответственно и на качество).

Прочитал https://moot.it/blog/technology/fram...avascript.html
Watch и так автоматом вызывает digest, тоже касается и функций прописанных в ngclick. Использовают Apply как правило вне подобных методов. Полностью магию можно реализовать только геттерами и сеттерами, за которые придется дорого платить производительностью (я писал выше об этом).

Простое решение выглядит простым только если оно существует само по себе. Чем взаимодействие этих простых решений сложнее между собой, тем сложнее проект в совокупности. То есть в какой то момент взаимодействие компонентов между собой оказывается сложнее самих компонентов. И вот чтобы решить проблему взаимодействия нам как раз нужны фреймворки вроде Backbone или Angular или Ember и т.п. В фреймворках есть готовые решения позволяющие связать компоненты приложения воедино. А в нативном JS вы с голой жопой перед этой проблемой. Любое красивое решение на JS которое вы изобретете для связывания окажется похожим на один из существующих фреймворков.

Ситуация такова что в большом приложении либо вы используете готовый фреймворк, либо пишете его сами :)

Насчет контролеров на jQuery я согласен, это неплохой инструмент но не панацея. В Ajax приложениях управление такими контролами превращается в проблему. Тобишь приложению нужно запускать разные контролы в зависимости от загруженного при помощи ajax контента. Это можно решить либо через инициализацию контролов каким то подобием роутера, либо декларативной инициализацией контролов в самом подгруженном контенте. Но в последнем случае есть неудобство со связыванием контрола с внешними данными. К примеру в ангуляре эту проблему решает вложенность scope;

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

Приятные впечатления
https://github.com/melanke/Watch.JS

Ну и от этих неплохие:)
http://rivetsjs.com/
http://witch.io/

Спасибо за аргументированные ответы.
Кстати, выкроил время и решил глянуть что и с чем едят эти инструменты - сказать что я был ошеломлен - ничего не сказать. Для себя сделал вывод что я знатный велосипедист и временами трачу кучу времени на написание новых великов для разработки одностраничного приложения. Когда я начал писать, думал что не так сложно, но сейчас просто топлюсь в усложнении логики. Фреймворк дает мне мощные инструменты прямо из коробки + документация. Если следующий схожий проект я и буду писать своими силами, так точно при помощи Angular/Ember/Backbone. Пускай тот же Angular и содержит 15000(?) строк и не держит IE6, но мне мои нервы и время дороже. Нахрен перфекционизм с pure js для таких проектов :( Меня уже прокрастинация начинает потихоньку жрать.

Мне кажется тут забыли ещё упомянуть YUI наравне с Angular/Ember/Backbone.

какие пути решения проблемы / оптимизации производительности предложите? Кроме того, что не использовать ангуляр :)

сюда переехало http://javascript.ru/forum/angular/4...itelnosti.html