Оптимальный способ работы с DOM

[DmitryKazakov8]

Спасибо за перевод, когда-то тоже основывал решение по выбору react-like-библиотеки для проектов на основе синтетических тестов. Однако, после нескольких сравнений в реальных проектах (заменой react с помощью webpack-алиасов на preact / inferno и тщательным исследованием профилировщика), пришел к выводу, что разница в производительности близка к нулю, как и разница в размере production-бандла. Тем не менее, регулярно стараюсь проверять этот вывод на новых версиях библиотек и новых проектах, вдруг действительно обнаружится заметный выигрыш? Но пока он заметен только на «добавить тысячи строк — обновить тысячи строк», что в реальном приложении не встречается, так как подобные задачи разбиваются по lazy-паттерну. А вот несовместимость некоторых пакетов с «неканонической» react-like библиотекой и разное поведение встречаются довольно часто.

[AlexxNB]

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

Зря на Svelte наговариваете:

Svelte benchmark

[JustDont]

Но масштабируемо ли его отсутствие?

Как показывают решения, не использующие VDOM (от собственных а-ля Svelte до стандартизируемых и вынесенных в браузер, как webcomponents) — отлично масштабируются.

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

Во-первых по производительности оно не так уж и далеко. Во-вторых, автор сравнивает теплое (шаблонизацию и проверку diff-разницы с VDOM) с мягким (компонентную разработку). Второе — решение другого уровня абстракции, и может полностью включать в себя первое, и естественно, что второе создаёт гораздо больше оверхеда ради более удобных абстракций, а потому и тормозит больше.

Ну и вообще, не раскрыта соль гонки за производительностью DOM. UI нужно как максимум работать со скоростью пользователя, а не со скоростью железа. И поскольку DOM не основан на framebuffer, то даже и перерисовывать экран 60 раз в секунду — тоже не нужно.