Я думаю было бы классно, чтобы фреймворк позволял мне описывать связи между состояниями без оверхеда в рантайме на их поддержание.
Вместо dirty checking? Нет, спасибо. Кому охота иметь всякие ko.observable(), ko.computed для всех задач вместо POJO, могут спокойно Knockout и выбрать. Вроде никто не мешает. Кому охота flux-style со всеми listeners, dispatchers и т.п. — тому в React. Есть выбор и это хорошо.
В дополнение? А что мешает подключить библиотеку не от создателей AngularJS?
И не заставляйте меня подбирать разные решения для одной и той же задачи синхронизации состояний :-)
Прозвучало как «не заставляйте меня подбирать способы хранения графа и алгоритмы по работе с ним». Есть разные способы, у всех свои преимущества и недостатки. Каждый выбирает, какой лучше подходит под задачу и больше нравится в использовании. Мой выбор — для большинства задач писать чистый (POJO) модульный тестируемый код с использованием AngularJS, там где упрусь в ограничения — применю локально альтернативные подходы, предварительно изучив как подобную задачу уже до меня решали.
Вы оригинально выбрали ветку :) По-моему, ваше видео только подтвердило, что AngularJS вполне спокойно «прожевывал» адекватные параметры. Обновление с нулевой задержкой прожевал тоже, но похуже react. Но в общем-то, вряд ли кто-то сомневается, что у dirty checking предельные параметры хуже, чем у change listeners. Свои плюсы, свои минусы.
О, вы прогрессируете, не только повесили deep-watch на большой объект, но и в listenerFn положили полный пересчет. В принципе, с одной стороны было бы классно, если бы фреймворки самостоятельно выбирали оптимальные алгоритмы, самооптимизировались и т.п., щелкнул пальцем «По щучьему велению» и получил результат. Правда, тогда бы и ЗП пониже были, как думаете?
Как-то так получилось, что все последнее обсуждение хоть и содержит постоянно слово AngularJS, но по сути сводится к обсуждению dirty checking и его использованию не к месту. А когда вы говорите про Knockout, я так понял, вы подразумеваете change listeners. Это два альтернативных подхода к отслеживанию изменений. И самое хорошее, что никто не мешает применить change listeners или что-нибудь другое в AngularJS под нужную задачу.
Еще раз — если вы грузите все данные, чтобы можно было делать на клиенте сортировку и фильтрацию, то ничего типичного в этом нет. Либо какая-то ваша специфика, что данных вряд ли будет больше и они редко добавляются. Либо как-то это все страньше и страньше звучит. Сегодня у вас 5000 элементов, завтра 100000. И я все меньше начинаю понимать, зачем там в контроллере нужен deep-watch (watch(..., ..., true)) на один объект/массив со всеми этими данными.
По Excel-ю — если это отдельное приложение, в котором ничего кроме непосредственного табличного процессора нет, то AngularJS там и не сильно нужен. Выше уже несколько раз писал, что выбор инструмента под задачу никто не отменял. Если это небольшая часть большого приложения, и табличный процессор там нужен в очень ограниченном виде, то почему бы и нет. Но это не значит, что надо сделать один большой объект — модель документа и повесть на него deep-watch. Но садиться и писать сейчас мини-Excel с использованием AngularJS я точно не буду в силу отсутствия времени. Хотите, выкладывайте свой тормозящий вариант, думаю, и помимо меня найдутся люди пооптимизировать/поправить.
При чем тут написание контроллеров в Angular? Просто на определенных задачах нет смысла применять dirty-checking. Но Angular — это не только dirty-checking.
Типичная задача — загрузить все данные, чтобы их потом можно было сортировать/фильтровать/группировать на клиентской стороне? Ведь, если не все загружены, то при сортировке/фильтрации будут затронуты и те, что с сервера не подтянули. Это не выглядит типичной задачей.
Такой «ерундой» я тоже редко занимаюсь, т.к. мне не приходит в голову делать deep-watch на объект/массив с 50000 значениями.
По экселю — зависит от масштабов, требований к масштабированию и т.п., может и в лоб бы нормально работало, может, модель бы документа сделал графовой или что-нить типа того. Такие вещи фреймворк за тебя не сделает. Я вообще далек от мысли, что фреймворк должен за программиста что-то делать.
Убить производительность? Ну можно не только количеством или размером наблюдаемого объекта, но и тяжелыми операциями в watchExpression или listenerFn. Да мало ли способов можно придумать.
Потому что необходимо 50000 watch-ей или же 1 watch на структуру из 50000 значений. Особой разницы нет, разве что второй вариант куда экономней.
Но раз уж пошли в сторону уточнений, то $digest еще зависит от сложности вычисляемых условий каждого $watch-а. Потому рекомендуется иметь «легкие» (быстро-вычисляемые) условия для $watch.
Сам же тест фактически дает оценку сверху — максимальная производительность в текущей среде (браузер, ОС) при максимально легких (но в тоже время весьма типичных для шаблонов) $watch-ей.
Начал бы решать с выяснения, что именно тормозит. Если $digest не укладывается в 50мс, то профилировал бы, за счет чего не укладывается.
С подобным описанием, сложно понять, что там и в какой момент тормозило. Где и как делается группировка и сортировка, выводится ли там все сразу на экран, сколько при этом там DOMа, и т.п.
А, мда, просто я это воспринял, как аргумент бестолковости теста. Тест как тест. Вполне себе дает общее представление о производительности. В частности, при 50000 watch-ей и 10 проходах на $digest приближаемся к критическим 50мс.
Хотя все равно непонятно, зачем такие задачи в лоб через $watch решать.
В реальном приложении $digest будет пропорционален объёму наблюдаемых данных
Да, и в AngularJS единица наблюдаемых данных и есть $watch. Так что ваши арифметические операции не очень понятны. Ладно бы на 2-10 поделили. Но зачем вы поделили на 100К?
А давайте UX всё же будут заниматься специально обученные UX-еры, а не создатели JS-фреймворка?
UX конкретного проекта будут проектировать не создатели фреймворка по определению. А вот почему создатели фронтенд-фреймворка не должны задумываться о принципах построения UI, я не понимаю. Кроме того, UX — это только часть того, о чем я говорил.
Вы тут шутки шутите, а каждый второй проект сейчас начинается на AngularJS отнюдь не по причине его технологического совершенства.
Я особых шуток тут не шутил, уровень аргументации просто на уровне популистких агиток, что с этим сделать можно?..
Кроме того, я не знаю, что такое «технологическое совершенство». Я знаю, что у каждого инструмента есть своя область применения. Если при выборе инструмента никак не учитываются его ограничения, то при чем тут фреймворк?
Со временем архитектурные просчёты выбранного фреймворка начинают все сильнее и сильнее бить по рукам. Но к тому моменту уже поздно что-то менять — написано куча кода, не отделимого от фреймворка.
Даже уперевшись в 2000 биндингов (кстати, не факт, что эта цифра на данный момент именно такая, все же AngularJS развивается и оптимизируется), в небольшом количестве мест — это решается, причем изменения легко локализуются, тестируются и т.п. Если оно по-всему приложению так, то тут уж как ни крути, либо надо признать, что инструмент выбран неправильно и переписать. Либо вариант с кривыми руками тоже никто не отменял. С абстрактными рассказами про проблемы с производительностью никогда не поймешь, а точно ли причина там, где описывают.
В календаре далеко не один месяц. А в дне, далеко не один час.
И это тут случай, когда мы возвращаемся к проектированию UX. А также к вопросу «крайний случай» vs «обыкновенный случай». Никто не спорит, что на страницу можно вывести очень много, только зачем? Чтобы у пользователя глаза в кучку собрались? Или чтобы показать «архитектурные просчеты» фреймворка, которые на самом деле являются осознанным выбором и не скрываются ни от кого?
С большой вероятностью AngularJS будет выбран потому, что миллион обезьян не может ошибаться
Ничего глупее нельзя представить. Тем более, что еще неизвестно, у каких фреймворков армии обезьян больше :)
Угу, и если большая часть вашего приложения такая, то надо грамотно выбрать инструмент, и в этом случае это, с большой вероятностью, будет не AngularJS. Если это одно состояние из сотен, а в остальном сильно хочется AngularJS, то с одной такой страничкой вы без проблем справитесь. Никто же не имеет ничего против того, что есть разные подходы и у каждого есть свои преимущества и недостатки. Но сравнение подходов — это не про эту статью.
И чтобы в одном месяце календаря получилось 2000 живых элементов, надо не менее 60 в каждой ячейке. Поэтому по поводу легкости преодолевания у меня пока все же некоторые сомнения.
Вместо dirty checking? Нет, спасибо. Кому охота иметь всякие ko.observable(), ko.computed для всех задач вместо POJO, могут спокойно Knockout и выбрать. Вроде никто не мешает. Кому охота flux-style со всеми listeners, dispatchers и т.п. — тому в React. Есть выбор и это хорошо.
В дополнение? А что мешает подключить библиотеку не от создателей AngularJS?
Прозвучало как «не заставляйте меня подбирать способы хранения графа и алгоритмы по работе с ним». Есть разные способы, у всех свои преимущества и недостатки. Каждый выбирает, какой лучше подходит под задачу и больше нравится в использовании. Мой выбор — для большинства задач писать чистый (POJO) модульный тестируемый код с использованием AngularJS, там где упрусь в ограничения — применю локально альтернативные подходы, предварительно изучив как подобную задачу уже до меня решали.
Как-то так получилось, что все последнее обсуждение хоть и содержит постоянно слово AngularJS, но по сути сводится к обсуждению dirty checking и его использованию не к месту. А когда вы говорите про Knockout, я так понял, вы подразумеваете change listeners. Это два альтернативных подхода к отслеживанию изменений. И самое хорошее, что никто не мешает применить change listeners или что-нибудь другое в AngularJS под нужную задачу.
Вис на обновлении? 700 запросов к серверу единомоментно слали? Отвисал в конце концов?
По Excel-ю — если это отдельное приложение, в котором ничего кроме непосредственного табличного процессора нет, то AngularJS там и не сильно нужен. Выше уже несколько раз писал, что выбор инструмента под задачу никто не отменял. Если это небольшая часть большого приложения, и табличный процессор там нужен в очень ограниченном виде, то почему бы и нет. Но это не значит, что надо сделать один большой объект — модель документа и повесть на него deep-watch. Но садиться и писать сейчас мини-Excel с использованием AngularJS я точно не буду в силу отсутствия времени. Хотите, выкладывайте свой тормозящий вариант, думаю, и помимо меня найдутся люди пооптимизировать/поправить.
Такой «ерундой» я тоже редко занимаюсь, т.к. мне не приходит в голову делать deep-watch на объект/массив с 50000 значениями.
По экселю — зависит от масштабов, требований к масштабированию и т.п., может и в лоб бы нормально работало, может, модель бы документа сделал графовой или что-нить типа того. Такие вещи фреймворк за тебя не сделает. Я вообще далек от мысли, что фреймворк должен за программиста что-то делать.
jsfiddle.net/49d84pjq/
Как и с какой периодичностью изменения моделей происходили?
Вы вообще определили, где затык то был?
Но раз уж пошли в сторону уточнений, то $digest еще зависит от сложности вычисляемых условий каждого $watch-а. Потому рекомендуется иметь «легкие» (быстро-вычисляемые) условия для $watch.
Сам же тест фактически дает оценку сверху — максимальная производительность в текущей среде (браузер, ОС) при максимально легких (но в тоже время весьма типичных для шаблонов) $watch-ей.
У вас $watch(..., ..., true) в контроллере на огромный объект или массив?
Начал бы решать с выяснения, что именно тормозит. Если $digest не укладывается в 50мс, то профилировал бы, за счет чего не укладывается.
С подобным описанием, сложно понять, что там и в какой момент тормозило. Где и как делается группировка и сортировка, выводится ли там все сразу на экран, сколько при этом там DOMа, и т.п.
Хотя все равно непонятно, зачем такие задачи в лоб через $watch решать.
Да, и в AngularJS единица наблюдаемых данных и есть $watch. Так что ваши арифметические операции не очень понятны. Ладно бы на 2-10 поделили. Но зачем вы поделили на 100К?
UX конкретного проекта будут проектировать не создатели фреймворка по определению. А вот почему создатели фронтенд-фреймворка не должны задумываться о принципах построения UI, я не понимаю. Кроме того, UX — это только часть того, о чем я говорил.
Я особых шуток тут не шутил, уровень аргументации просто на уровне популистких агиток, что с этим сделать можно?..
Кроме того, я не знаю, что такое «технологическое совершенство». Я знаю, что у каждого инструмента есть своя область применения. Если при выборе инструмента никак не учитываются его ограничения, то при чем тут фреймворк?
Даже уперевшись в 2000 биндингов (кстати, не факт, что эта цифра на данный момент именно такая, все же AngularJS развивается и оптимизируется), в небольшом количестве мест — это решается, причем изменения легко локализуются, тестируются и т.п. Если оно по-всему приложению так, то тут уж как ни крути, либо надо признать, что инструмент выбран неправильно и переписать. Либо вариант с кривыми руками тоже никто не отменял. С абстрактными рассказами про проблемы с производительностью никогда не поймешь, а точно ли причина там, где описывают.
И это тут случай, когда мы возвращаемся к проектированию UX. А также к вопросу «крайний случай» vs «обыкновенный случай». Никто не спорит, что на страницу можно вывести очень много, только зачем? Чтобы у пользователя глаза в кучку собрались? Или чтобы показать «архитектурные просчеты» фреймворка, которые на самом деле являются осознанным выбором и не скрываются ни от кого?
Ничего глупее нельзя представить. Тем более, что еще неизвестно, у каких фреймворков армии обезьян больше :)
И чтобы в одном месяце календаря получилось 2000 живых элементов, надо не менее 60 в каждой ячейке. Поэтому по поводу легкости преодолевания у меня пока все же некоторые сомнения.