Веб-компоненты

так это не сломано, это документация не так понята

если б не переиспользовал, там был бы шквал пересозданий на каждый пук

в Lit так работает директива repeat (перемещает ноды), а map нет, в документации описано https://lit.dev/docs/templates/lists/#when-to-use-map-or-repeat

на 4000 элементах вью уходит в раздумия на секунду целую в свои flushJobs в микротасках у меня

хотя навешан всего 1 computed

В doka.guide открыли PR с документацией веб-компонентов - кому интересно, можно поучаствовать в ревью https://github.com/doka-guide/content/pull/5852

Мы в Vaadin наконец перешли полностью на Lit, опубликовал статью по такому случаю https://dev.to/webpadawan/10-years-of-building-web-components-the-story-of-91d

пока ещё не опен сорснул, комбинация 4 самописных custom element'ов <wc-panzoom> (panning & zooming) <wc-d2> (selection, dragging, etc.) <wc-wire> (SVG wire connection rendering) <wc-wiring> (wiring logic) хорошо взаимодействует с server-side шаблонами, ибо параметризуется атрибутами и стреляет событиями которые хорошо накладываются на концепцию data-star.dev, HTMX и им подобных

воу, звучит круто, а что за data-star.dev в двух словах?

типа потоковый рендеринг HTML?

я подзабыл уже что такое HTMX

согласен, не лучша фомулировка ну наскока я понял из лендинга, сервер постепенно посылает чанками HTML

правда чанки чанкам рознь, там DOM всегда выглядит полным, только текст внутри узлов обновляется то есть тоже как будто тоже с ограничениями это решение но я и не помню что там в HTMX было и плохо себе представляю какие тут юз-кейсы вообще в реальности нужны

поэтому собсвтенно и спрашиваю 🙂 особенно в котексте твоих компонентов, которые я в своей голове не могу никак соединить с тем, зачем тут HTMX

ага, так понятнее звучит круто!

всё состояние считай на сервере и граф в реальном времени обновляется для всех подключённых участников