Должна смотреть только на кубки, еще смотрит, если ты сливаешься, то выбирает тебе таких же соперников. По факту, сражение практически всегда идет на полную выкладку, по крайней мере у меня. Это стресс.
Каким образом? Мне тоже было бы интересно убрать стадию транспиляции из джаваскрипта.
Я знаю единственный вариант — это использование JSDoc комментариев, однако их функционал — это 1% от функционала Тайпскрипта (насчет Флоу не знаю). Плюс JSDoc не дружит с ES6+.
Ну вроде как иметь дополнительную информацию о типах — это лучше, чем не иметь ее вообще, разве нет? Тем более, что она опциональна и, при необходимости, легко обходится.
Не совсем правильно называть это "статическими типами", это скорее аннотации типов. Статическая типизация гарантирует (ну или пытается) отсутствие ошибок типов в рантайме. Ни флоу, ни тайпскрипт этого не гарантируют.
Старую модель необходимо переиспользовать, чтобы не грузить одни и те же данные по нескольку раз.
Вот это и есть ключевая проблема. Обновить модель по новым данным просто, если она тривиальная. Если нет — то сложно, и будут те же костыли, что и в реакте/ангуляре, только вручную.
Ну а "нетривиальных структур данных" в модели быть не должно. Гораздо удобней работать с нормализованными данными, а не с развесистым JSON.
Много чего не должно быть, однако есть. Те же лишние дивы-врапперы, появляющиеся по условию, которые вы упоминали выше. Спорить не с чем, просто уточняйте, что $mol — самый лучший фреймворк (для простых и нормализованных моделей). Замечу, однако, что в dirty checking и virtual DOM такой проблемы нет.
Пример притянут, конечно, за уши. Но суть в том, что каждый вызов создаст новый объект, и магия графа зависимостей перестанет работать и пересоздаст кусок разметки.
Для того же, чтобы она заработала, нужно хранить где-то модель, и обновлять ей свойства.
Поэтому реконциляция должна контролироваться программистом (например, как в моём примере — через создание уникальных идентификаторов)
В Реакте, если я не ошибаюсь, она контролируется через key. Это не совсем то, что у вас, но позволяет указать, когда элемент должен переиспользовать реальный ДОМ элемент (но опять же, я не уверен).
Гранулярность этого чека гораздо выше (мы чётко знаем где у нас могло что-то поменяться). И нет, вручную это проверять не надо. Вычислили новое значение, библиотека сравнива его со старым, и если зафиксировано изменение — каскад обновлений продолжается.
Понятно, что вручную обычно быстрее, т.к. учитывает специфику данных. Только вручную можно в любом фреймворке, это не интересно :)
С чего бы полное перестроение?… В случае $mol_view каждый компонент имеет ссылку на соответствующий ему элемент. ...
При пересоздании модели по новым данным ссылка будет указывать на старую модель. Напомню, я рассматривал ситуацию обновления модели новыми данными, старую модель можно переиспользовать только реализовав ручное заполнение (а это не совсем тривиально для сложных структур данных).
Построение графа, конечно, не бесплатно, но и не так уж затратно, а профита даёт много:. ...
Есть преимущества, и есть недостатки, из них: загрузка данных — это плохой сценарий, описал в предыдущих комментариях, плохая работа с проекциями (вычисляемыми моделями) — для эффективной работы проекции нужно делать наблюдаемыми и обновлять свойства при изменении.
То есть модель с графом зависимостей тяготеет к императивному стилю.
Затесалась где-то лишняя обёртка или другое имя тега и привет, полный ререндер.
Да, это так (наверное), но касается лишь случая, когда обертка добавляется или удаляется динамически. Возможно, в каком-то фреймворке есть оптимизация для этого, но имхо овчинка не стоит выделки.
При этом именно в виртуальном ДОМ наибольший потенциал для оптимизации более реалистичного случая — динамического рендера одного компонента из фиксированного набора. Если их структура похожа, то будет происходить обновление физ. ДОМ вместо пересоздания.
Все объекты (не только визуальные компоненты) переиспользуются, так что это вполне штатный сценарий.
То есть обновляются значения всех свойств во всей иерархии? Или обновляются только измененные? А массивы как, как определяется, какие элементы в массиве изменились? Или если порядок поменялся, как определяется?
Это тот же dirty checking, только вручную. А если все пересоздается заново — то тот же рендеринг v-dom.
Тут природу не обманешь, в любом из подходов есть неэффективные сценарии.
Например?
Например, из массива чисел подготовить данные для графика; по массиву свободных мест отрисовать доступные к продаже места (учитывая правила продажи); не суть важно.
Рассмотрим каждый подход и вариант с пересозданием или же модификацией:
С dirty-checking — разницы особо нет, при модификации будет чуть меньше проверок (или же вообще не распознает изменения). Реальный ДОМ обновится как карта ляжет — может оптимально, а может и пересоздать заново большой кусок.
С графом зависимостей — при модификации будет оптимальное изменение, при пересоздании — будет полная перестройка графа. Обновление ДОМ — оптимальное при модификации, полное перестроение в противном случае.
С виртуальным ДОМ — либо полная перестройка и реконсиляция при пересоздании, либо частичная перестройка при модификации (и то не факт). Обновление же ДОМ всегда близко к оптимальному.
При этом модификация вручную — это императивный (не "реактивный") код, и он по производительности будет сопоставим с dirty checking и v-dom reconciliation. Пересоздание графа зависимостей же — это самая затратная операция из всех, и если ее делать постоянно, то выигрыша в производительности не будет.
Виртуальный ДОМ — это не серебряная пуля, конечно же, это всего лишь разумный компромисс, который дает аккуратное и предсказуемое (а это не менее важно часто, чем быстрое) обновление реального ДОМ дерева.
Перестроение — это вообще не про реакт, согласны? Это, возможно, про редакс или флакс, но речь разве о них?
Речь про подход реакта. И я тут считал задержку между действием пользователя и появлением реакции на экране, а не только лишь время процессора, проведённое в определёной библиотеке.
Я же и говорю — это костыли для редакса, не для реакта. Редакс бывает и для Ангуляра, и для Вью, и даже для Нокаута.
На каких же данных вдом может быть быстрее? Уже для 3000 элементов, разница заметна:
1) На больших объектах, со множеством свойств — когда у элемента виртуального ДОМ свойств меньше. 2) На больших массивах (да и объектах), из которых рендерится только часть (то же отфильтрованное меню) — сравнение будет идти по реально отображаемым элементам, а не по всем данным.
Опять же, это все фиксится — подготавливаются модели, заранее фильтруются данные, но, в общем случае, плохие сценарии бывают у всех подходов.
Вы очень смело обобщаете. с какими фреимворками вы работали? работали ли с $mol? сможете придумать для него худший релистичный сценарий?
Я не работал с ним, как я понимаю, это фреймворк с построением графа зависимостей. Плохой сценарий для него — это 1) перестроение виджета по новым данным (при перезагрузке с сервера, например), 2) сложные проекции (селекторы) — производные вычисляемые данные, которые не сделать наблюдаемыми (т.к. они вычисляются каждый раз заново), и, следовательно, ДОМ для них просто тупо перестраивается.
Подход реакта. Заново формируем то же самое дерево (+50мс), заново фильтруем его с тем же результатом (+150мс),
заново преобразуем в список пунктов меню (+50мс).… После чего реакт делает дифф с real-dom и применяет разницу (+40мс). Итого — четверть секунды на удаление атрибута у одного элемента и добавление его другому.
Итого — 90мс для списка в 10 000 элементов.
Перестроение — это вообще не про реакт, согласны? Это, возможно, про редакс или флакс, но речь разве о них?
Вы ниже писали, что Ангуляр применяет точечные патчи.
Вы думаете, что это быстрее генерации и сравнения v-dom для списка в 10К элементов? Возможно, но я бы не утверждал. Сравнение произвольных данных может быть как быстрее, так и медленнее в-дом, зависит от данных.
В "реактивных" фреймворках типа MobX или Knockout время тратится на построение графа зависимостей. Будет ли это быстрее, чем в-дом? Может да, а может и нет, зависит будут ли меняться данные, как часто и каким образом они будут меняться.
Писать быстрые приложения сложно на любом фреймворке, потому что невозможно выиграть во всем. У каждого из них есть свой худший сценарий (и вы для демонстрации выбрали худший для в-дом, вот где непредвзятость).
Выбирать фреймворк по производительности, если производительность отличается, ну, пусть даже на 50% — нету смысла, если только заранее не известны узкие места, и они действительно критичные и важные (придуманный пример — обновление котировок, или лотов аукциона, тяжелые графики на SVG, и т.п.).
У всех современных фреймворков производительность удовлетворительная. 80% приложений никогда не испытают проблем с производительностью, а половина тех, что испытают — решат их минимальными исправлениями.
Ничто не мешает использовать реакт, как, скажем, jquery-компоненты, или директивы ангуляра, или еще что-то другое. Но только зачем? App state management библиотеки придумали не потому, что в реакте по-другому нельзя, а потому, что это удобно и имеет преимущества. Об этом говорит и существование байндингов того же redux под многие фреймворки.
Смотреть нужно не на текущую рентабельность, а на рентабельность проекта (с учетом багфиксов, запуска, поддержки). А так да, для фриланс-заказов на 10 часов выгоднее всего наиболее дешевый из подходящих, как уже указали ниже.
Есть настройка
"workbench.editor.enablePreview": false, которая отключает режим просмотра.Думаю, отличается правилами вызова. Например:
Должна смотреть только на кубки, еще смотрит, если ты сливаешься, то выбирает тебе таких же соперников. По факту, сражение практически всегда идет на полную выкладку, по крайней мере у меня. Это стресс.
Каким образом? Мне тоже было бы интересно убрать стадию транспиляции из джаваскрипта.
Я знаю единственный вариант — это использование JSDoc комментариев, однако их функционал — это 1% от функционала Тайпскрипта (насчет Флоу не знаю). Плюс JSDoc не дружит с ES6+.
Ну вроде как иметь дополнительную информацию о типах — это лучше, чем не иметь ее вообще, разве нет? Тем более, что она опциональна и, при необходимости, легко обходится.
Вы не поверите...
Не совсем правильно называть это "статическими типами", это скорее аннотации типов. Статическая типизация гарантирует (ну или пытается) отсутствие ошибок типов в рантайме. Ни флоу, ни тайпскрипт этого не гарантируют.
Это, я так понимаю, издержки фреймворков с графом зависимостей (хотя не знаю, почему не использовать свойства вместо этого).
Вот это и есть ключевая проблема. Обновить модель по новым данным просто, если она тривиальная. Если нет — то сложно, и будут те же костыли, что и в реакте/ангуляре, только вручную.
Много чего не должно быть, однако есть. Те же лишние дивы-врапперы, появляющиеся по условию, которые вы упоминали выше. Спорить не с чем, просто уточняйте, что $mol — самый лучший фреймворк (для простых и нормализованных моделей). Замечу, однако, что в dirty checking и virtual DOM такой проблемы нет.
Я так понимаю, что массивы обрабатываются поэлементно, и т.к. объекты переиспользуются, то и разметка для них переиспользуется.
Я же имел ввиду нечто вроде
Пример притянут, конечно, за уши. Но суть в том, что каждый вызов создаст новый объект, и магия графа зависимостей перестанет работать и пересоздаст кусок разметки.
Для того же, чтобы она заработала, нужно хранить где-то модель, и обновлять ей свойства.
В Реакте, если я не ошибаюсь, она контролируется через
key. Это не совсем то, что у вас, но позволяет указать, когда элемент должен переиспользовать реальный ДОМ элемент (но опять же, я не уверен).Понятно, что вручную обычно быстрее, т.к. учитывает специфику данных. Только вручную можно в любом фреймворке, это не интересно :)
При пересоздании модели по новым данным ссылка будет указывать на старую модель. Напомню, я рассматривал ситуацию обновления модели новыми данными, старую модель можно переиспользовать только реализовав ручное заполнение (а это не совсем тривиально для сложных структур данных).
Есть преимущества, и есть недостатки, из них: загрузка данных — это плохой сценарий, описал в предыдущих комментариях, плохая работа с проекциями (вычисляемыми моделями) — для эффективной работы проекции нужно делать наблюдаемыми и обновлять свойства при изменении.
То есть модель с графом зависимостей тяготеет к императивному стилю.
Да, это так (наверное), но касается лишь случая, когда обертка добавляется или удаляется динамически. Возможно, в каком-то фреймворке есть оптимизация для этого, но имхо овчинка не стоит выделки.
При этом именно в виртуальном ДОМ наибольший потенциал для оптимизации более реалистичного случая — динамического рендера одного компонента из фиксированного набора. Если их структура похожа, то будет происходить обновление физ. ДОМ вместо пересоздания.
Да, для эффективности больших обновлений нужно делать "транзакционные" методы
То есть обновляются значения всех свойств во всей иерархии? Или обновляются только измененные? А массивы как, как определяется, какие элементы в массиве изменились? Или если порядок поменялся, как определяется?
Это тот же dirty checking, только вручную. А если все пересоздается заново — то тот же рендеринг v-dom.
Тут природу не обманешь, в любом из подходов есть неэффективные сценарии.
Например, из массива чисел подготовить данные для графика; по массиву свободных мест отрисовать доступные к продаже места (учитывая правила продажи); не суть важно.
Рассмотрим каждый подход и вариант с пересозданием или же модификацией:
С dirty-checking — разницы особо нет, при модификации будет чуть меньше проверок (или же вообще не распознает изменения). Реальный ДОМ обновится как карта ляжет — может оптимально, а может и пересоздать заново большой кусок.
С графом зависимостей — при модификации будет оптимальное изменение, при пересоздании — будет полная перестройка графа. Обновление ДОМ — оптимальное при модификации, полное перестроение в противном случае.
При этом модификация вручную — это императивный (не "реактивный") код, и он по производительности будет сопоставим с dirty checking и v-dom reconciliation. Пересоздание графа зависимостей же — это самая затратная операция из всех, и если ее делать постоянно, то выигрыша в производительности не будет.
Виртуальный ДОМ — это не серебряная пуля, конечно же, это всего лишь разумный компромисс, который дает аккуратное и предсказуемое (а это не менее важно часто, чем быстрое) обновление реального ДОМ дерева.
Я же и говорю — это костыли для редакса, не для реакта. Редакс бывает и для Ангуляра, и для Вью, и даже для Нокаута.
1) На больших объектах, со множеством свойств — когда у элемента виртуального ДОМ свойств меньше. 2) На больших массивах (да и объектах), из которых рендерится только часть (то же отфильтрованное меню) — сравнение будет идти по реально отображаемым элементам, а не по всем данным.
Опять же, это все фиксится — подготавливаются модели, заранее фильтруются данные, но, в общем случае, плохие сценарии бывают у всех подходов.
Я не работал с ним, как я понимаю, это фреймворк с построением графа зависимостей. Плохой сценарий для него — это 1) перестроение виджета по новым данным (при перезагрузке с сервера, например), 2) сложные проекции (селекторы) — производные вычисляемые данные, которые не сделать наблюдаемыми (т.к. они вычисляются каждый раз заново), и, следовательно, ДОМ для них просто тупо перестраивается.
Ну то есть
Итого — 90мс для списка в 10 000 элементов.
Перестроение — это вообще не про реакт, согласны? Это, возможно, про редакс или флакс, но речь разве о них?
Вы ниже писали, что Ангуляр применяет точечные патчи.
Вы думаете, что это быстрее генерации и сравнения v-dom для списка в 10К элементов? Возможно, но я бы не утверждал. Сравнение произвольных данных может быть как быстрее, так и медленнее в-дом, зависит от данных.
В "реактивных" фреймворках типа MobX или Knockout время тратится на построение графа зависимостей. Будет ли это быстрее, чем в-дом? Может да, а может и нет, зависит будут ли меняться данные, как часто и каким образом они будут меняться.
Писать быстрые приложения сложно на любом фреймворке, потому что невозможно выиграть во всем. У каждого из них есть свой худший сценарий (и вы для демонстрации выбрали худший для в-дом, вот где непредвзятость).
Выбирать фреймворк по производительности, если производительность отличается, ну, пусть даже на 50% — нету смысла, если только заранее не известны узкие места, и они действительно критичные и важные (придуманный пример — обновление котировок, или лотов аукциона, тяжелые графики на SVG, и т.п.).
У всех современных фреймворков производительность удовлетворительная. 80% приложений никогда не испытают проблем с производительностью, а половина тех, что испытают — решат их минимальными исправлениями.
Ничто не мешает использовать реакт, как, скажем, jquery-компоненты, или директивы ангуляра, или еще что-то другое. Но только зачем? App state management библиотеки придумали не потому, что в реакте по-другому нельзя, а потому, что это удобно и имеет преимущества. Об этом говорит и существование байндингов того же redux под многие фреймворки.
А какой еще возможен вариант? Почему он более "успешный"? И в чем проблема его реализовать на реакте?
Для меня лично MobX стойко ассоциируется с Knockout и всеми его болячками.
Плюс не нравится описывать структуру данных модели и загрузку ее данными сервера, как было в Нокауте. Хотя, может быть, в МобХ такой проблемы и нет.
Я имел ввиду качество продукта — соответствие требованиям с приемлемым количеством ошибок.
Смотреть нужно не на текущую рентабельность, а на рентабельность проекта (с учетом багфиксов, запуска, поддержки). А так да, для фриланс-заказов на 10 часов выгоднее всего наиболее дешевый из подходящих, как уже указали ниже.