Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 69
Респект за написание статьи, но чувак, ты со своим $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
плюсик в карму) согласен)
забавно, но в $mol поиск как раз таки работает)
но для этого нужно переопределять поиск стандартный ( в моле по дефолту )
А на мобильных устройствах это тоже работает? Или там просто глобальный хендлер на страницу добавлен на ctrl+f?
Да, поиск есть, можно на иконку нажать и откроется ввод
На сочетание клавиш по идее тоже должно работать, но я не знаю как нажать на телефоне его )
К хроме на андроиде - три точки в верхнем правом углу - find in page / найти на странице Думаю у остальных примерно так же:) На смартфонах это не сочетание клавиш
Если поработать с a11y то становится понятно что эта фича очень популярна и она работать должна с дефолтным браузерным api а не через доп иконки и тд, без неё не пройти аудит WCAG 2.1 и соответственно это ставит крест на использовании этого вот много где
Да, на телефонах тоже работает
С доступностью нужно доп работы проводить, согласен. Но сделать это правильно и пройти аудит ничего не мешает
Нет, не работает Идём на страницу https://mol.hyoo.ru/#!section=docs/=xanlom_yimh6x
Делаем поиск по странице слова “заработали” дефолтным браузерным поиском И видим 0 А должно быть 4
да оно и не может работать если не рендерить весь контент, потому как браузеры не предоставляют api для вызова функции поиска по странице
вообще не понятно кому пришла идея рендерить только viewport , окей для крупных таблиц или если вы книгу целиком с lazy пагинацией рендерите, но для обычных 99% страниц это абсолютно лишняя ломающая дефолтное браузерное поведение фича
так же вся вот эта куча кастомных элементов в DOM tree - включите voice over / narrator и побегайте по странице, у этого абсолютно нет шансов пройти какие либо a11y аудиты/быть минимально юзабельным для людей использующих скрин ридеры, дефолтные HTML это не просто красивые слова
Частично согласен
Выглядит так как будто создаём себе проблемы а потом героически решаем
Ломаем старые привычки, возможно это можно как то фиксануть, перехватить ивент
Про 99% не согласен. 99% людей нужен быстрый интерфейс, а а11 не нужен, как бы цинично это не было
Для а11 нужно доп работы проводить, но пройти можно
Когда то кому то пришла идея не рендерить в играх то что игрок не видит...
Тут все просто, как по мне. Если делаем SPA - берем $mol. Он для этого топ-1. Если делаем сайт с интерактивными элементами - берем SSG (или классический веб-фреймворк с шаблонизатором, типа Laravel) и одно из вышеупомянутых WC-based решений. Все.
Вы так сподвигнете наконец изучить веб-компоненты и попробовать их на чём-нибудь реальном
Хорошая попытка, но нет. Привычнее Vue/React.
попробую как нибудь еще)
.../Svelte )
Он не готов к проду)
Однако, я так понимаю проблема из-за <p>, но это какой-то слишком хитрый кейс и такое лучше собрать отдельной функцией которая соберет строку не ломая переменные, не вижу проблемы, это отловится еще на этапе разработки фичи и будет исправлено
Не-а
Если разнести в два разных тэга, проблема останется
справедливости ради, если вернуть число, реактивность восстановиться ( c биндингами, без них нет )
еще тут попробовал разнести на два компонента
делал всё в туторе https://svelte.dev/tutorial/svelte/passing-snippets
А как всё-таки читается это название? $mol типа маленький? Или тут доллар + моль (единица вещества)? Или типа как jQuery, но маленький?
Сколько $mol не рекламируй, пока у него такой не читаемый синтаксис он никому не нужен. Как ты правильно заметил-всем нужен поддерживаемый код, но шаблоны $mol это абсолютно не читаемая хрень на уровне зубодробительных однострочников лиспа
Как аргумент слабовато, это скорее мнение
Мне тоже сначала было необычно, но стоило понять что этот "непонятный" код декларативной описывает интерфейс и превращается в js, как сразу стало понятнее и проще
Тут бы хорошо реальное исследование провести
Ну сделайте опрос, тупо по коду из этой статьи, кому понятно что у TodoApp есть footer и кому понятно что у $hyoo_todomvc есть foot (мне вот вообще непонятно почему у него есть нога), ну и попробуйте объяснить откуда она взялась.
Дальше больше - вы пишете что в MyTodoApp у вас не вышло заменить только футер. Конечно можно было бы вызвать родительский render и перетряхнуть его результат как нужно, например поменяв хедер и футер местами в зависимости от времени суток.
Попробуйте такое сделать в вашем декларативном описании.
Согласен что не понятно ( по этому поводу есть предложения, сделать нагляднее ) надо исходники компонента смотреть что бы узнать какие свойства у него есть, тут стоит относиться к компоненту как к либе с API который нужно узнать
от времени суток - это будет уже в ts, делается не сложно
примерно в таком духе
если хотите, давайте созвонимся, постараюсь быстро обьяснить концепцию view.tree
Я читал статью о нем и понимаю как он работает, проблема в том, что он не более чем json в смешной обёртке. Представьте что вместо шаблонов будет json с экзотическими полями - на сколько доступно это будет?
В конкретном примере это не просто странный json, а json который содержит в себе кучу магии. И эта магия зависит от контекста и на сколько программисту её реализующему было не лень.
Можно ли sub вызвать в произвольном месте и будет ли он всегда работать?
Как будет выглядеть код, который заменяет <sub> на <sub>/</sub> ?
view.tree не более чем json в смешной обёртке
боюсь тогда спросить вас о jsx ))))
Ну, любая технология кажется "магией" по началу, надо просто разобраться
Вы же не называете магией наследование в ООП ? А там тоже не известно какие методы есть у родительского класса, тоже нужно смотреть. И эта магия зависит от контекста и на сколько программисту её реализующему было не лень.
Представлять не нужно, view.tree сделан максимально строгим и простым, без лишних символов
На фото выше - ts код
Можно ли sub вызвать в произвольном месте и будет ли он всегда работать?
в произвольном нельзя, можно поиграться тут
если синтаксически верно написано то всегда будет в js превращатся
Все наследники $mol_view имеют свойство sub
Как будет выглядеть код, который заменяет <sub> на <sub>/</sub> ?
Пример вложения дива в див показал по ссылке выше
Ну посыл понятен, типа меньше оберток (избавляемся от <component>...</component>). Отлаживаться конечно без этих оберток тяжелее
Это к аргументу про композицию ?
Отлаживать на самом деле очень просто.
В браузере при наведении на компонент будет что то типа
Root().Page().Button().Icon()И потом что бы в css.ts достучаться до иконки нужно просто прописать этот же путь без рута
Интересное решение. Просто на данный момент держать в dom-дереве лишние теги, для меня имело смысл, только для отладки. А так, дополнительная обертка веб компонента жрет память, усложняет стилизацию и является по-моему мнению чем-то лишним
а там нету обёртки) и лишних тэгов
кстати приходи на piterUX ) https://piterjs.org/#!meetup=chf4lr_ow1ixs
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что всё таки не так с веб компонентами