Имел неосторожность посерфить инет со слабого ноута [теория тупости]

Такими «по сути» можно продолбать принципиальные моменты. Надо еще разделять чтение с записью, чтобы апдейты группировать в animationFrame. Локи ведь происходят на чтении из DOM сразу после записи

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

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

Это лишняя абстракция, которая чуть больше защищает от forced layout, хотя все равно можно накосячить в обработчике событий с e.target.

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

Проблема не в «легко-трудно», проблема в том, что это работа, который в принципе не должно было быть, ни много, ни мало. Это «не трудно» при росте сложности очень незаметно превращается в «трудновато» и снижение FPS менее 60, а если не принимать меры и наращивать сложность SPA дальше, например, делать интерактивные карты и прочие фигмы, то пользователь уже будет созерцать время реакции порядка секунды на «нетрудные операции».

Для справки: на этой странице LOR у меня 2700 DOM элементов. Посмотрим на бенчи:

https://krausest.github.io/js-framework-benchmark/2020/table_chrome_84.0.4147...

Как можно заметить, уже на тысяче строк в таблице React и другие VDOM легко улетают за 100 мс. Да, крупные изменения DOM на ванильном JS тоже перваливают за 100 мс, но проблема в том, в реакте даже мелкие операции на большой таблице находятся за пределами 100 мс, а многие за 200 мс, в то время, как Svelt держится близко к ванильному JS. То есть, ты меняешь один элемент, а React перетряхивает весь DOM на тысячи элементов. Короче говоря, как я уже писал, на реакте нельзя писать динамичную кнопочку или поле ввода — хотя с загрузкой больших статичных страниц реакт справляется прекрасно.

Вот чего я не могу понять - это svelte, который ты упоминал. Там на главной странице гордятся тем, что заменили уровень абстракции данных на код. У меня глазик несколько раз дернулся, пока читал. Я как-то привык, что надо дизайнить data-flow, и если он хорош, то с функциями и классами уже особо не накосячишь. И тут хренак, диаметрально противоположное

Я вообще не понял сути претензии. Предлагаю тебе взглянуть на примеры простых SPA на их сайте, чтобы самому решить, что там data-flow, что там функции и классы. Потому что в Svelte код компонентов пишется как простой JS, то есть, как хочешь, с минимумом прокладок с фреймворком. Svelte — это такой генератор минимальных JS-прокладок.

уже на тысяче строк в таблице React и другие VDOM легко улетают за 100 мс

Кстати, на кой показывать юзеру тыщу строк? Он ведь не робат, по тыще строк в секунду не сканирует. Если ограничиться десятком-другим за раз, проблема не возникнет, наверное?

«Посерфить инет» и «зайти в фейсбук» - это довольно разные вещи, одинаковые только для зумеров. На одноядерном процессоре сейчас в интернете в принципе очень некомфортно, а уж на фейсбуке, которому сейчас периодически перестает хватать 16gb ram и который концентрированный эталон самой жирноты - тем более.

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

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

По твоему гисту больше про reflow. А я говорил про другое. С VDOM можно реализовать обращения к браузерному DOM «write only», а изменения слушать по событиям.

Например, запускаешь анимацию высоты, а читаешь вычмсленное значение вместо реального.

Ну и группировка - изменяешь 10 совсем разных элементов, и это автоматически пакетируется, чтобы страница только 1 раз пересчиталась.

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

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

Слушай, я мамой клясться не буду, не знаю откуда такая хрень как ты описываешь. Это точно не нормально и такого быть не должно. Ну, в конце концов, возьми vue.js. Вроде он так не должен козлить (да любой фреймворк с vdom не должен).

Локи ведь происходят на чтении из DOM сразу после записи.

Чтение из DOM ничего не стоит. Стоит чтение из CSSOM, в том числе косвенное, приводящее к reflow.

Ну и группировка - изменяешь 10 совсем разных элементов, и это автоматически пакетируется, чтобы страница только 1 раз пересчиталась

Вообще-то лет 15 все браузеры так делают. Советую пройти профайлером по моему тестовому проекту, чтобы убедиться в этом лично:

https://byko3y.github.io/simple_DOM_benchmark/

В любом раскладе, я не вижу никаких иных причин для «локи происходят при чтении после записи в DOM».

Слушай, я мамой клясться не буду, не знаю откуда такая хрень как ты описываешь. Это точно не нормально и такого быть не должно. Ну, в конце концов, возьми vue.js. Вроде он так не должен козлить (да любой фреймворк с vdom не должен)

Аще-т я почти Vue-сеньор, так что конкретно Vue я знаю от и до. Так вот: во Vue тот же самый render, только в профиль, то есть, в пределах одного компонента. Если у тебя в компоненте тысяча дочерних, и ты удаляешь один из дочерних компонентов, то родительских компонент должен заново от-render-ить список. Однако, все дочерние компоненты не изменились, они «чистые», потому во Vue они не будут пересчитываться и бабушки-дедушки выше по дереву тоже не будут пересчитываться.

То, для чего Vue больше всего оптимизировано — это изменение одного дочернего компонента без изменения списка дочерних компонентов. Тогда считает только один-единственный компонент, и это почти так же быстро, как ванильный JS.

То, для чего Vue хуже всего оптимизировано — это когда изменение нескольких переменных приводит к изменению по цепочке целой кучи компонентов в разных местах дерева. Огромное количество звеньев Watcher-ов приходят в движение, и по итогу они приводят к полному или почти полному пересчету дерева — то есть, как React, только плюс лишний сложный механизм отслеживания изменений. На эту тему есть целое кунг-фу для исключения объектов из отслеживания и произведения ручных пересчетов.

Чтение из DOM ничего не стоит. Стоит чтение из CSSOM, в том числе косвенное, приводящее к reflow

По состоянию на 2022 год многие API CSSOM можно считать экспериментальной технологией и не принимать в рассмотрение:

https://caniuse.com/mdn-api_caretposition
https://caniuse.com/css-scroll-behavior

А старые, вроде CSSStyleSheet и CSSRule, ни к какому reflow не приводят.

Чего ты решил что дело в браузере?

На таком говне будет тормозить любая современная версия чего угодно - от компилятора, до текстового редактора, до самих Gtk/Qt. Открой графический текстовый редактор с кодом на 2000 строчек. Как полет?

На таком говне будет тормозить любая современная версия чего угодно - от компилятора, до текстового редактора, до самих Gtk/Qt. Открой графический текстовый редактор с кодом на 2000 строчек. Как полет?

По 10-16 килострок кода модули у меня на этом ноуте крутились в делфи. Да. про intellisense можно было забыть, но в остальном полёт нормальный.

HTMLElement.prototype.style - это внезапно тоже CSSOM. Как и getComputedStyle. И все возможные getBoundingClientRect, innerr\outer\width\height\offset\etc - всё это CSSOM. И сам CSSOM существует с момента как появился CSS. Как и любая визуальная составляющая элемента задающая layout/typography/geometry/position/etc - все это CSSOM.

Перестань уже из треда в тред нести о том, в чем ты не разбираешься. Читать тебя порой невыносимо.

ни к какому reflow не приводят.

К reflow приводят чтения computed style properties конкретных элементов.

крутились

В прошлом.

Вздулся на считаные проценты каждый уровень, от ядра, до libc и так далее, вплоть до пользовательских приложений.

А ты нафантазировал злодеев из React.

Правильно, поттеринги и так нагадили во все слои. А сверху ещё слоны покакали реактами.

TMLElement.prototype.style - это внезапно тоже CSSOM. Как и getComputedStyle. И все возможные getBoundingClientRect, innerr\outer\width\height\offset\etc - всё это CSSOM. И сам CSSOM существует с момента как появился CSS. Как и любая визуальная составляющая элемента задающая layout/typography/geometry/position/etc - все это CSSOM.
Перестань уже из треда в тред нести о том, в чем ты не разбираешься. Читать тебя порой невыносимо

И тем не менее ты сам обосрался: https://www.w3.org/TR/cssom-1/ — здесь нет никаких getBoundingClientRect и offsetXXX, потому что это уже отрендеренный DOM и к стилям не относится. CSSOM относится только непосредственно к самим CSS стилям, их селекторам и media query, вроде HTMLElement.style, который ты упомянул. Когда в CSS можно будет указать offsetHeight, тогда и поговорим про его отношение к CSSOM.

К reflow приводят чтения computed style properties конкретных элементов

Не всегда:

window.getComputedStyle() will force layout in one of 3 conditions:
    1. The element is in a shadow tree
    2. There are media queries (viewport-related ones). Specifically, one of the following:
        https://source.chromium.org/chromium/chromium/src/ /master:third_party/blink/...
        min-width, min-height, max-width, max-height, width, height
        aspect-ratio, min-aspect-ratio, max-aspect-ratio
        device-pixel-ratio, resolution, orientation , min-device-pixel-ratio, max-device-pixel-ratio
    3. The property requested is one of the following:
        https://source.chromium.org/chromium/chromium/src/ /master:third_party/blink/...
        height, width
        top, right, bottom, left
        margin [-top, -right, -bottom, -left, or shorthand] only if the margin is fixed.
        padding [-top, -right, -bottom, -left, or shorthand] only if the padding is fixed.
        transform, transform-origin, perspective-origin
        translate, rotate, scale
        grid, grid-template, grid-template-columns, grid-template-rows
        perspective-origin
        These items were previously in the list but appear to not be any longer (as of Feb 2018): motion-path, motion-offset, motion-rotation, x, y, rx, ry

ХЗ, зачем ты в таком духе ведешь беседу. Тебе очень хочется проверить, сеньор я или нет, или просто побесить захотелось?

Вздулся на считаные проценты каждый уровень, от ядра, до libc и так далее, вплоть до пользовательских приложений

По ощущениям там не «проценты», а раза в 2-3.

Кумулятивно получается что 4 ГБ уже не катит и твой комп годен чтобы быть мини сервером, может для музыки или торрентов, без иксов

Кумулятивно получается что 4 ГБ уже не катит и твой комп годен чтобы быть мини сервером, может для музыки или торрентов, без иксов

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

Вообще-то лет 15 все браузеры так делают. Советую пройти профайлером по моему тестовому проекту, чтобы убедиться в этом лично:

https://byko3y.github.io/simple_DOM_benchmark/

В любом раскладе, я не вижу никаких иных причин для «локи происходят при чтении после записи в DOM».

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

Фреймворки же ограничивают юзера (на уровне своего апи), и там проще сделать отложенные обновления. Обычно копят несколько десятков миллисекунд, а потом чохом вываливают в AnimationFrame.

Технически, ты можешь и без фреймворков всё выписывать на AnimationFrame. Просто это гиморно очень.

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

По моему опыту, кастомный скрол во Vue был тоже нифига не сахар. Ну то есть это ожидаемый пересчет макета, с VDOM или без, а вот если накосячить на уровне JS, то можно словить несколько пересчетов где угодно.

Фреймворки же ограничивают юзера (на уровне своего апи), и там проще сделать отложенные обновления. Обычно копят несколько десятков миллисекунд, а потом чохом вываливают в AnimationFrame

Еще раз: браузеры делают абсолютно то же самое. Нет никаких специальных API для того, чтобы сделать некий набор обновлений DOM пакетным или во время отрисовки фрейма аля WebGL — изменения просто применяются к DOM по очереди и в следующей итерации главного цикла отрисовываются браузером.

Еще раз: браузеры делают абсолютно то же самое. Нет никаких специальных API для того, чтобы сделать некий набор обновлений DOM пакетным или во время отрисовки фрейма аля WebGL — изменения просто применяются к DOM по очереди и в следующей итерации главного цикла отрисовываются браузером.

Ты просто не в курсе. https://developer.mozilla.org/ru/docs/Web/API/window/requestAnimationFrame - отсюда копай.

Нет никаких специальных API для того, чтобы сделать некий набор обновлений DOM пакетным или во время отрисовки фрейма аля WebGL — изменения просто применяются к DOM по очереди и в следующей итерации главного цикла отрисовываются браузером

Ты просто не в курсе. https://developer.mozilla.org/ru/docs/Web/API/window/requestAnimationFrame - отсюда копай

requestAnimationFrame — это лишь хитрожопый вариант setTimeout, предназначенный для того, чтобы фоновые приложения не колбасили DOM по setTimeout при неактивной странице. Само оно ничего не рисует, и если обработчик не поменяет DOM, то никакого пересчета не произойдет — браузер просто отрисует тот же буфер. В отличие от WebGL, которая таки непосредственно занимается отрисовкой и отдает буфер.

здесь нет никаких getBoundingClientRect и offsetXXX

https://www.w3.org/TR/cssom-view/#extension-to-the-element-interface

https://www.w3.org/TR/cssom-view/#extensions-to-the-htmlelement-interface

потому что это уже отрендеренный DOM и к стилям не относится. CSSOM относится только непосредственно к самим CSS стилям

Дилетантишка, прекрати нести о том, в чём ты не разбираешься. Продолжай ныть о социальной несправедливости в своей жизни. Ты ни на что более не способен.

Тебе очень хочется проверить, сеньор я или нет

Ты даже на трейни не тянешь.

Core2Quad + 4GB RAM + 8GB SSD Swap:

Host: Devuan v9 (ASCII) + Libre Kernel + ZFS + Docker + Trinity DE + Firefox + WINE + MS Office + KVM

Гостевуха (здесь же на 4 гиговой коре кедра): Devuan v11 (Chimaera) + guest ext4 on host zvol + IceWM + Telegram + браузеры

Скриншот:

https://paste.pics/FJRWA

Ниче не тормозит, что я делаю нитаг?

Ну ты заявил (мне так показалось), что в браузере нет апи для пакетирования апдейтов. Вот оно, есть.

Само оно ничего не рисует, и если обработчик не поменяет DOM, то никакого пересчета не произойдет — браузер просто отрисует тот же буфер.

Я про другое. Если у тебя 10 изменений, и все вызывают reflow, то браузер может первые 9 reflow пропустить и потом сделать все сразу. Благодаря этому апи.

Ну там килотонны нюансов конечно, я только общее направление описываю.

Я про другое. Если у тебя 10 изменений, и все вызывают reflow, то браузер может первые 9 reflow пропустить и потом сделать все сразу. Благодаря этому апи.

Обновил страничку:

https://byko3y.github.io/simple_DOM_benchmark/

Особенно хром долго пересчитывает макет. Это к слову о том, что на самом деле хром ни разу не быстрее лисы — уже который раз замечаю, что DOM в лисе работает быстрее хрома. Гугл просто деоптимизирует ютьюб и гмейл для лисы, раньше выпускает новые фичи, ну и V8 на отдельных задачах у них быстрее (в число этих задач не входит нахождение целочисленного остатка).

Попробуй Ungoogled Chromium.

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

По DOM я вообще не особый спец. Больше сталкивался с JIT, то есть «как писать на жыэс молотилки байтов и строк, чтобы не сильно медленнее сишечки». Фронт делаю только когда совсем деваться некуда, и похоже разбираюсь в нем сильно слабее тебя.

По DOM я вообще не особый спец. Больше сталкивался с JIT, то есть «как писать на жыэс молотилки байтов и строк, чтобы не сильно медленнее сишечки». Фронт делаю только когда совсем деваться некуда, и похоже разбираюсь в нем сильно слабее тебя

Ты знаешь, когда я начал разбираться во фронте, то я чуть не сошел с ума — там десяток слоев совместимости друг на друге, и в большинстве случаев разработка сводится к «нагуглить самое близкое проверенное решение, потому что даже сам разработчик стандарта с трудом скажет тебе, как правильнее всего сделать». Неудивительно, что фронтэндерам (по крайней мере до короны) платили больше, чем бэкэндерам.

Конечно, со временем выясняется, что разнообразие проверенных решений не бесконечно — это же и является недостатком веб-платформы, очень многие вещи на ней нельзя сделать иначе как «написать с нуля на JS/WAsm работу с байтами/пикселями».

Ну да, там свой странный мир. Плюс еще и архитектурные подходы за последние 5 лет меняются с дикой скоростью, вместе со спеками. Невозможно уследить и упомнить, если плотно на этом не сидеть.

В принципе, стандарты пилят в нужную сторону, и когда-то этот хаос с фичами браузеров/фреймворков уляжется, как js в ноде. А пока мне проще пешком постоять. Не вебом единым. Вона, я еще для фана железки леплю https://hackaday.io/projects/hacker/440909. После вебни интерфейсы эмбедов - это дошкольная группа, где твои скилы уровня бога :).

а большинство снг сидело с adsl’ом

Щито? Тогда уже у всех оптика была или витая пара.

В Mozilla Firefox Quantum надо выставить работу в 2-3 потока и можно смотреть. Остальные браузеры «висят», да.

Но не в нем причина тормозов.

Но ведь способствует. Типа вместо вызова функции запускать конструктор метода и прочий трэш. Был бы уровня, простите, бейсика - тормозило бы меньше.