Мне тоже сначала было необычно, но стоило понять что этот "непонятный" код декларативной описывает интерфейс и превращается в js, как сразу стало понятнее и проще
я отвечаю на вопрос "стоит ли брать веб компоненты как основу для фреймворка ?"
lifecycle CE (connectedCallback, attributeChangedCallback, observedAttributes) — это push семантика, её не обойти
Оверхед по памяти будет всё равно — каждый CE это ~124 байта в C++ куче Blink (Node → Element → HTMLElement), независимо от фреймворка сверху. JS-объект — ~16-64 байта в V8 heap.
операции с JS-объектами V8 оптимизирует на полную (inline caches, hidden classes). Операции с DOM — это binding-вызовы в C++, которые V8 не может оптимизировать так же. Поэтому obj.title = x — 1-2 ns, а el.textContent = x — 30-60 ns. Это и называется "Jit сломан"
про парсинг да, но я не видел без него реализации на веб компонентах
строки кода отражают зависимость от выбранной семантики
$mol использует абстракцию к dom, обращений к dom на порядок меньше. Мост на .cpp не нужен ( jit ) ( понятно что js вызовы попадают на jit, я же писал про другое, про .cpp мост )
обьяснение примера с выделелнием писем из статьи
еще аргументы: парсинг html кол-во строк кода pull семантика архитектурно не поддерживается WC композиция - в $mol это архитекрутное решение ( програмисту не нужно думать об этом ) Что бы повторить это на другом фреймворке, нужно выполнить кратно больше работы. И думать тоже нужно больше. Причем всегда.
Можно попробовать подключить что то из мола, но всё равно как то проталкивать изменения нужно будет ( опять же лишняя абстракция над мол компонентами выходит, тестируемость теряется, html придется парсить )
Самые неэффективные технологии зачастую хвастаются своей максимальной производительностью. На микробенчмарках с полным пересчётом всех состояний самое тупое решение легко может показаться самым быстрым. Но эти спринтеры не способны пробежать марафон, падая на обочину уже с тривиальных тестов корректности применения побочных эффектов. Разработчики ищут ключи там, где светло (оптимизации кода), а не там, где их потеряли (оптимизации архитектуры). Для лучшего понимания ключевых проблем в реактивных архитектурах, лучше глянуть мою давнюю лекцию: Main Aspects of Reactivity
а вообще я не к этому аппелирую там самое лучшее 22 милисекунды на 1000 строк худшее 93
допустим я сделаю бенч для мола и он ( допустим ) покажет 100 мс для 1000 строк, ужасный результат
но рендерить мол будет что то около 50 и всё равно уложиться в 16 мс за кадр, понимаете к чему я веду ? Пользователю абсолютно всё равно на "честность" Интерфейс должен отрисовываться\работать как минимум за 16мс, и мол - это гарантирует. Никто другой нет. Стоит ли смотреть на такой бенч ? Я сомневаюсь
приложу так же аналитику со своего сайта на моле ( хоть там и нет ни тысяч ни миллионов элементов ) https://b-on-g.github.io/blitz
в статье есть еще аргументы) про память - аргумент выдерживает критику ( веб компоненты обязаны занимать эту память, а с js обьектом можно много манипуляций до рендера провернуть ) про jit - тоже про pull push реактивность тоже
Генерировать интерфейс из json ? Не очень перспективно
Как аргумент слабовато, это скорее мнение
Мне тоже сначала было необычно, но стоило понять что этот "непонятный" код декларативной описывает интерфейс и превращается в js, как сразу стало понятнее и проще
Тут бы хорошо реальное исследование провести
ага, я вот тут начал https://github.com/b-on-g/todomvc-compare
там как раз симбиот лит и мол
так мы ни к чему не придём)
нужен бенч)
было бы интересно скооперироваться и подготовить такой ? можем потом статью выпустить
я отвечаю на вопрос "стоит ли брать веб компоненты как основу для фреймворка ?"
lifecycle CE (connectedCallback, attributeChangedCallback, observedAttributes) — это push семантика, её не обойти
Оверхед по памяти будет всё равно — каждый CE это ~124 байта в C++ куче Blink (Node → Element → HTMLElement), независимо от фреймворка сверху. JS-объект — ~16-64 байта в V8 heap.
операции с JS-объектами V8 оптимизирует на полную (inline caches, hidden classes). Операции с DOM — это binding-вызовы в C++, которые V8 не может оптимизировать так же. Поэтому obj.title = x — 1-2 ns, а el.textContent = x — 30-60 ns. Это и называется "Jit сломан"
про парсинг да, но я не видел без него реализации на веб компонентах
строки кода отражают зависимость от выбранной семантики
$mol использует абстракцию к dom, обращений к dom на порядок меньше. Мост на .cpp не нужен ( jit ) ( понятно что js вызовы попадают на jit, я же писал про другое, про .cpp мост )
обьяснение примера с выделелнием писем из статьи
еще аргументы:
парсинг html
кол-во строк кода
pull семантика архитектурно не поддерживается WC
композиция - в $mol это архитекрутное решение ( програмисту не нужно думать об этом ) Что бы повторить это на другом фреймворке, нужно выполнить кратно больше работы. И думать тоже нужно больше. Причем всегда.
Про jit второй пункт
Можно попробовать подключить что то из мола, но всё равно как то проталкивать изменения нужно будет ( опять же лишняя абстракция над мол компонентами выходит, тестируемость теряется, html придется парсить )
Mobx хорош, rxjs не очень хорош ( делает много лишней работы ) https://page.hyoo.ru/#!=3ia3ll_rcpl7b/View’3ia3ll_rcpl7b’.Details=RxJS
на моле тоже можно делать веб компоненты
как нравится) я по простому пишу - мол
но задумка да, $mol = small ( маленький )
если есть желание можем созвониться, я помогу ( мне тоже было сложно )
слишком много информации, мне кажется
для старта достаточно этого :
git clonehttps://github.com/hyoo-ru/mam.gitcdmamnpm installnpm startсоздать приложение ( строго внутри mam нужно ) -npm create view-tree-lsp@latest mynamescape/myapp – --no-docker --no-tauriи скил для нейронки - npx skills b-on-g/mol_skill
базовый компонент который может быть любым html элементом - mol_view ( div по умолчанию )
у него свойсвтво sub - массив элементов вложенных
вы нашли самый слабо проработанный компонент сразу же)
Да, в идеале надо бы так, что бы примером показывать
не знал, спасибо
если добавить виртуализацию к СЕ , получиться $mol но с оверхэдом, лишней абстракцией
смысла маловато в этом
и еще по поводу бенча этого https://page.hyoo.ru/#!=3ia3ll_rcpl7b/View’3ia3ll_rcpl7b’.Details=RxJS
мол не умеет рендерить не виртуально, можно взять либу - mol_wire для реактивности, но смысла не много
на счёт этого бенча есть разные мнения https://habr.com/ru/articles/1019420/#comment_29778712
а вообще я не к этому аппелирую
там самое лучшее 22 милисекунды на 1000 строк
худшее 93
допустим я сделаю бенч для мола и он ( допустим ) покажет 100 мс для 1000 строк, ужасный результат
но рендерить мол будет что то около 50 и всё равно уложиться в 16 мс за кадр, понимаете к чему я веду ?
Пользователю абсолютно всё равно на "честность"
Интерфейс должен отрисовываться\работать как минимум за 16мс, и мол - это гарантирует. Никто другой нет. Стоит ли смотреть на такой бенч ? Я сомневаюсь
приложу так же аналитику со своего сайта на моле ( хоть там и нет ни тысяч ни миллионов элементов )
https://b-on-g.github.io/blitz
попробую как нибудь еще)
в статье есть еще аргументы)
про память - аргумент выдерживает критику ( веб компоненты обязаны занимать эту память, а с js обьектом можно много манипуляций до рендера провернуть )
про jit - тоже
про pull push реактивность тоже
Лишняя шапка меня выдала!)
о, багу не заметил, надо поправить будет
рестарт страницы поможет кстати ;)
всё остальное работает, не позор)
по метрикам
FCP возможно расчитывается неправильно, не уверен
на декстопе еще добавлю
Если вдруг в Питере приходите развиртуализироваться на t.me/piterjs !
Там очень лампово и уютно ( и иногда шутять про смол 😄)
Мне кажется что есть всё таки, новые фрейморки появляются чтобы заменить старичков, но и те и те решают одни и те же задачи
По поводу доки, да она отстойненькая)
Но никто не запрещает делать красиво, например как у меня вот
https://b-on-g.github.io/blitz/
Подробнее:
https://t.me/Dev_cmuser/25
И на самом деле я как раз стараюсь думать про пользователей, бенчи тут так, просто в тему для объективности
К тому же никому не нравятся лаги) и баги)
Ещё раз все сайты на моле не одинаковые !!! Это миф !)