What's the difference from virtual dom libraries?

[kuraga]

Здравствуйте, Дмитрий!

С удивлением смотрю на бенчмарки, и... Не подскажете, в чём коренное отличие Vidom от прочих virtual dom-библиотек? Что придает такую скорость?

Спасибо.

[dfilatov]

Ну возьмем, например, популярную https://github.com/Matt-Esch/virtual-dom. Там сначала вычисляется полностью дифф, после чего он уже накладывается на DOM-дерево отдельной операцией. В vidom же, дифф накладывается по мере вычисления. Ну и есть много всяких мелких низкоуровневых оптимизаций. Ну а про react я уже даже не говорю )

[kuraga]

Да, вот сравнение с ней (virtual-dom) меня в точности и интересует! А что значит по мере вычисления? Поясните, пожалуйста...

[dfilatov]

Есть первое виртуальное дерево, которому соответствует некое реальное DOM-дерево. Есть второе виртуальное дерево, дифф с которым нужно применить к реальному DOM-дереву. В vidom, по мере сравнения этих деревьев, патч сразу накладывается на соответствующий DOM, а не складывается в отдельную структуру как в virtual-dom, которая уже позже применяется к DOM отдельной операцией.

[kuraga]

Аааа, вот оно чё... Не думал, что это так всё замедляет... Спасибо! P.S. Я запиливаю библиотеку на основе virtual-dom, RotorJS. Чем-то похожа на Вашу, только всё, кроме минималистической реализации Component и Application - as a dependency. Вот, узнал, что всё может быть "до 10-ти раз быстрее" :smile: Хотя интерфейс virtual-dom'а мне нравится...

[dfilatov]

Ну там не только это, я это для примера рассказал.

[kuraga]

Ну ясно, что "низкоуровневых оптимизаций" много, и их количество только растёт :smile: Понял, есть и другое... Буду изучать код.

Я сейчас сгоряча говорю, может я и не прав, но было бы классно библиотеку манипуляций с DOM отдельно вынести... Потому что по http://vdom-benchmark.github.io/vdom-benchmark/ Vidom очень быстр, и reusable, возможно бы кому-то пригодилась.

[dfilatov]

Так вроде нет особой проблемы использовать vidom только как библиотеку манипуляций c DOM, без компонент и всего прочего.

[kuraga]

О, Вы юзаете Inferno... Логичная идея, перевести динамику в статику... Наверное, оптимальнее этого, в глобальном смысле, придумать что-то сложно?

У них там в чате Joel Richard (автор CitoJS) написал следующее, что дало мне понять, куда может быть направлен вектор оптимизации (я прошу простить, что Вас отвлекаю, я больше не буду, но этим уж черезчур хочется поделиться, хоть и звучит просто после прочтения):

My idea was that while "compiling" a template, it would count the number of variable values and nodes. For example, if you have a template with a single node which has two variable attributes, then the number would be 3 (one node + two values - a specific shape assumed). The compiled function would then return an object/array with the necessary amount of slots. The value slots would already be filled with the given values (arguments to the template). The node slots, however, would only be filled in the create/update function.In the update function, you will then have to compare the values and copy the old node references over to the new object/array. Theoretically, you could also store all nodes in a single separate object so that you only have to set one field, but if there are just a few node references, I think it will be quicker to have them all in the same object/array (instead of creating an additional object). I am aware that this algorithm is challanging to implement. Therefore, I would start with the following shapes: - Generic shape with list of child shapes, - Shape for (keyed) lists, - Static tree shape. For elements with variables, it would use the generic shape. For dynamic children, the keyed list shape and for all static sub trees, the static tree shape. A template would then be transformed into a tree of these three shapes. Once you have this working, you can add a few more specific implementations which can be used instead of the generic shape. For real world applications, this should not make a big difference though because most of the nodes are usually pretty static. To win the benchmarks, it will be a big help though. I don't see any other way (expect of compiling the templates to pure JavaScript) which can deliver the same performance.

[dfilatov]

Я не юзаю inferno ) Я просто тоже пытаюсь понять возможные пути оптимизации, если встанет вопрос о производительности в vidom (пока его нет). А вот некоторые проблемы с подходом, используемым в inferno я вижу, поэтому и привел одну из них в их трэкере.

[kuraga]

У них там полная нестабильность (имхо, но Dominic говорит в чате "I think Inferno is stable now..." примерно раз в неделю :smile:), а код только усложняется... А конечная идея, видимо, вот та, что в цитате...

[kuraga]

@dfilatov , а скажите, пожалуйста, в Vidom есть keyed reordering? Когда отслеживается положение узла по ключу...

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

[chicoxyzzy]

Есть первое виртуальное дерево, которому соответствует некое реальное DOM-дерево. Есть второе виртуальное дерево, дифф с которым нужно применить к реальному DOM-дереву. В vidom, по мере сравнения этих деревьев, патч сразу накладывается на соответствующий DOM, а не складывается в отдельную структуру как в virtual-dom, которая уже позже применяется к DOM отдельной операцией.

разве идея всех virtual DOM библиотек не в том, чтобы один раз тронуть реальный?..

[dfilatov]

@kuraga keyed reordering в vidom есть. Как это называется более официально, и называется ли, не знаю. Сам я смотрел несколько реализаций в других библиотеках + писал свою, потом остановился на некоем симбиозе того что видел и сам придумал.

[dfilatov]

@chicoxyzzy DOM и трогается один раз. Но один раз != одна операция, это невозможно просто.