Comments 43
Респект за написание статьи, но чувак, ты со своим $mal иногда выглядишь как фанатик. Люди инертны, консервативны. Статьями на хабре призвать их использовать хорошее доброе вечное... вряд ли получится. Основывай свою корпорацию, делай ее продукт популярным и навязывай хорошие фоеймворки так! :)
Про сравнение памяти для объектов - второй вариант будет отрендерен в какой-нибудь див и будет занимать те же мегабайты наверное. А если виртуализация и он не будет рендериться, то и CE так же можно не рендерить. Логика переходит в контейнер выше.
Про композицию - делаем функции renderHeader, renderBody, renderFooter и переопределяем одну в наследнике. Лет 40 этой практике наверное.
C виртуализацией не всё так просто
бенч https://t.me/giper_dev/11/288
статья про неё https://mol.hyoo.ru/#!section=docs/=gjboo1_xhyrnq
Про композицию абсолютно согласен, тут поинт скорее в том что это архитектурное решение, то есть разработчик никак не может сделать плохо ( как я показал )
ну а чем меньше ошибок может допустить програмист и отловить компилятор - тем лучше
Опять же аппеляция к тому что не надо думать и писать "лишний" код
Тогда о чем статья?
не понял вопрос, может выйдет раскрыть ?
Вы привели минусы веб компонентов: много занимают памяти и неудобная компоновка требующая дублирование логики. Оба аргумента не выдерживают критики, по крайне мере я так понял из ответа на мой комментарий. Тогда напрашивается вопрос, в чем минусы, в чем суть статьи?
в статье есть еще аргументы)
про память - аргумент выдерживает критику ( веб компоненты обязаны занимать эту память, а с js обьектом можно много манипуляций до рендера провернуть )
про jit - тоже
про pull push реактивность тоже
CE отлично дружат с JS объектами, совершайте манипуляции в JS объекте. Про jit не вижу в статье.
WC ( Web components ) используют push семантику для реактивности. Pull думаю врядли буду поддерживать. Это ваше мнение. В CE нет реактивности, но никто не мешает в них добавить mobx, rxjs или вот ваш mol.state, наверное тоже можно?
Про jit второй пункт
Можно попробовать подключить что то из мола, но всё равно как то проталкивать изменения нужно будет ( опять же лишняя абстракция над мол компонентами выходит, тестируемость теряется, html придется парсить )
Mobx хорош, rxjs не очень хорош ( делает много лишней работы ) https://page.hyoo.ru/#!=3ia3ll_rcpl7b/View’3ia3ll_rcpl7b’.Details=RxJS
Да, спасибо, про jit тоже треш какой-то. Как будто в mol вам не нужен textContent и setAttribute. Вы ведь не в канвас рендерить? Значит тот же дом, только на другом этапе. Хоть один аргумент стоящий есть?
$mol использует абстракцию к dom, обращений к dom на порядок меньше. Мост на .cpp не нужен ( jit ) ( понятно что js вызовы попадают на jit, я же писал про другое, про .cpp мост )
обьяснение примера с выделелнием писем из статьи
еще аргументы:
парсинг html
кол-во строк кода
pull семантика архитектурно не поддерживается WC
композиция - в $mol это архитекрутное решение ( програмисту не нужно думать об этом ) Что бы повторить это на другом фреймворке, нужно выполнить кратно больше работы. И думать тоже нужно больше. Причем всегда.
Вы сравниваете mol с каким-то другим фреймворком, с Lit? Тогда при чем тут CE и WC?
pull семантика архитектурно не поддерживается WC
Чем она не поддерживается, CE или ShadowDom? Pull семантика у стейт менеджера, в WC нет дефолтного стейт менеджера, можно брать любой. Парсинг html - это про lit Кол-во строк кода - по сравнению чего с чем? Опять видимо Lit vs mol. Ну так и назовите статью “Вздор про lit и восхваление Mol”
я отвечаю на вопрос "стоит ли брать веб компоненты как основу для фреймворка ?"
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 сломан"
про парсинг да, но я не видел без него реализации на веб компонентах
строки кода отражают зависимость от выбранной семантики
Push - как и все события dom. В mol наверное тоже они обрабатываются. Дальше оборачивается в push/pull в зависимости от statemanager. Не все через атрибуты.
JS объект не отрендеришь, тебе нужен див - оверхеда нет
Obj.title потом все равно вызовет div.textContent. И наоборот customElement.data.title быстрый.
так мы ни к чему не придём)
нужен бенч)
было бы интересно скооперироваться и подготовить такой ? можем потом статью выпустить
Бенч mol и WC? Так для wc нужен фреймворк, там вот где-то в соседних ветках symbiote форсили, я хз что это, но наверное с ним можно. Lit конечно говно редкостное, рядом с mol и не лежал)
ага, я вот тут начал https://github.com/b-on-g/todomvc-compare
там как раз симбиот лит и мол
если добавить виртуализацию к СЕ , получиться $mol но с оверхэдом, лишней абстракцией
смысла маловато в этом
Я работал с Lit, но совсем не понял, что там такого ценного. Компоненты JS можно и так писать.
Может и есть что-то очень полезное в Web Component, но лично я ничего такого не нашел.
Вы почему-то скрыли от публики часть результатов вашего-же изначального сравнения. Именно ту, где были реальные значимые цифры, и они были СИЛЬНО не в пользу $mol. Кроме того, вы не боитесь открыть ящик Пандоры и добиться того, что кто-то все-таки не выдержит, и потратит время на РЕАЛЬНОЕ сравнение? Боюсь, оно будет разгромным.
буду рад получить реальное сравние от независимого автора, только таким, научным, методом рождается истина
я там бенч изначально неверно составил с размером ( в корне были мои мусорные файлы которые тянулись во все бандлы локально у меня )
Настоящий размер составил 181 кб, честно указал его в бенче
https://github.com/b-on-g/todomvc-compare
что бы проверить вы можете выполнить
git clone https://github.com/hyoo-ru/mam.git
cd mam
npm install
npm start hyoo/todomvcи в папке hyoo/todomcv/-/web.js -- вы тут получите весь собранный код
PS поправил пути, и у меня на чистую 185 вышло щас
Да, в целом ты прав, но ты немного радикально обобщаешь. Проблема не столько в самих веб-компонентах, сколько в том, как их используют. Если просто наивно рендерить тысячи элементов через DOM -любой подход упрётся в лимиты, не только WC.
я так же думаю, но почему многим это важно ( вот тут https://habr.com/ru/articles/1014708/#comment_29737390 )
эти многие реально смотрят на https://github.com/krausest/js-framework-benchmark
и думают что там реальная производительность показывается
тут фрустрация и отторжение из за "попытки обмануть" бенч этот
но если бенч плохой, зачем он нужен
я считаю лучше применять всё что можно, все допинги, и показывать реальную максимальную производительность JS. Она тоже не бесконечна, но насколько Не ? никто не знает. все упёрлись в html
по моим расчётам на моле можно свою OC написать, и она будет быстрее и стабильнее многих ныне живущих) ( и даже уведомления будут сразу прилетать и колокольчик краситься )
Не стоит рендерить то - что не видно.
Да, я именно так и думаю, когда поиск по странице ничего не находит, если это не на экране /s
Тут все просто, как по мне. Если делаем SPA - берем $mol. Он для этого топ-1. Если делаем сайт с интерактивными элементами - берем SSG (или классический веб-фреймворк с шаблонизатором, типа Laravel) и одно из вышеупомянутых WC-based решений. Все.
Вы так сподвигнете наконец изучить веб-компоненты и попробовать их на чём-нибудь реальном
Хорошая попытка, но нет. Привычнее Vue/React.
А как всё-таки читается это название? $mol типа маленький? Или тут доллар + моль (единица вещества)? Или типа как jQuery, но маленький?
Что всё таки не так с веб компонентами