Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 29
А в чем проблема была использовать готовые решения, например Lit, Stenciljs или solidjs?
я был техлидом команды, которая делала ui-kit на Lit, мы использовали вторую версию
на тот момент там были проблемы с перерисовкой (целиком вызывается функция render при каждом изменении атрибута веб-компонента)
насколько я знаю, в 3-й версии добавили точечное обновление DOM, но другие проблемы остались
например, ленивая загрузка контента табов (слотов), это не так просто и удобно сделать на lit, solid, stencil, используя именно веб-компоненты
также не хотелось использовать jsx или шаблонные строки для создания компонента, хотелось получить реактивность, но без лишних оберток (это как раз описано в статье)
Идея здравая, но насчёт поддержки и дальнейшего развития есть высокая доля сомнения, наверное по этой причине, возможно, стоит сделать выбор в пользу более зрелого решения
поддерживаю я + коллеги по работе
активно используем в компании на проде в одном из продуктов как основной инструмент для разработки фронтенда
А что за продукт? Можно его посмотреть на предмет тормозов
это b2b продукт, его нет в открытом доступе
мы сравнивали (в основном для больших списков и общее потребление памяти) с react/vue/angular, производительность выросла
но, чтобы не просто верить моим слова, а увидеть конкретные результаты, планировал выложить сюда https://krausest.github.io/js-framework-benchmark/ для сравнения производительности
Странно что нет сравнения со Svelte, ведь это первое что приходит на ум когда нужна реактивность без оверхеда
Как по мне стоит выбирать только между html first и js first. За последнее время посмотрел достаточно много библиотек. Практически все выглядят как ужас. Удобней реакта в плане построения компонентов нет- это то когда jsx реально тащит. Чисто для html vue хорош. Сигналы есть preact/reef и тд. Даже типа построения шаблонов в виде функций есть но выглядит это все как вырви глаз. Мне допустим зашёл alphinejs. Я сразу вспомнил старый добрый angularjs, это как раз когда нужна лёгкая реактивность - без лишних оберток. Правда с компонентами там непонятки. Скучаю по старому angularjs. А так, что то хорошего прям нет. Svelte да хорош, но хотелось бы без сборщиков. надоеда эта магия и бандлеры.
Автор выдает себя за уверенного пользователя фронта, но слышал лишь про нестареющую троицу... печально
Выше упомянули про свелт, солид и тд, но автор что-то пытается бубнить про веб-компоненты, хотя данный эвангелизм канул в лету где-то в 2015м, когда нашлись очевидные проблемы. Упомяну ещё alpine.js, мб это автор желал. Но детская привычка сделать "все сам" продолжает непокидать умельца
Если бы каждый, у кого возникла мысль написать своё, останавливался потому, что "это уже есть", не было бы ни "свелт, солид и тд".
пытается бубнить про веб-компоненты, хотя данный эвангелизм канул в лету где-то в 2015м, когда нашлись очевидные проблемы.
странно, а вот ребята из reddit и microsoft с Вами не согласны
в 2023-ем году reddit целиком переехал с react на Lit (веб-компоненты), и они получили значительный прирост производительности https://www.reddit.com/r/reddit/comments/11zso11/an_improved_web_experience/
есть пример с браузером edge, где тоже был переезд на веб-компоненты (2024 год) https://thenewstack.io/from-react-to-html-first-microsoft-edge-debuts-webui-2-0/
если не ошибаюсь, у них есть своя библиотека для создания веб-компонентов (fast)на российском рынке из примеров есть компания Едадил, они полностью переехали на Lit https://frontendconf.ru/moscow/2025/abstracts/16096
данный эвангелизм канул в лету где-то в 2015м
1-ая спецификация по веб-компонентам появилась в 2016, а поддержка браузерами появлялась с 2017 по 2020 (в 20-ом году начал поддерживать edge, а это очень важно, учитывая количество обычных пользователей на windows)
Веб компоненты гвоздями прибиты к DOM, что делает их мертворождёнными.
Хостовой объект, приаттаченый к документу - это крайне медленно. И JIT компилятор тут ничем помочь не может.
Значениями атрибутов могут быть лишь строки - нужны адовые не совместимые между либами костыли для передачи других типов значений.
Жизненный цикл компонента начинается лишь в момент аттача хостового элемента.
Перенос хостового элемента приводит к реаттачу всего поддерева компонент.
Легко словить конфликт имён компонент между разными либами. И механизмов разрешения этого конфликта нет.
Единожды зарегистрированный компонент уже нельзя удалить.
В теневом доме отваливаются все стили - их надо копипастить в каждый теневой дом отдельно. Надо ли говорить, что это тормоза на ровном месте?
Веб компоненты ничего не знают про пулл реактивность. Хочешь что-то им передать пуш по чём зря через атрибуты и слоты.
И вот на этой кривой архитектуре вы и сделали свой фреймворк, которого "как бы нет".
Можно раскрыть подробнее про хостовый элемент, который прикреплён к документу. Не совсем понятно, что имеется в виду.
Когда вы создаёте элемент - под капотом создаётся два объекта: объект хоста и js обёртка над ним, через которую вы взаимодействуете с первым. Это не бесплатный интероп. И он не может быть оптимизирован компилятором, ибо JS рантайм владеет только этими самыми обёртками, а сами объекты хоста для него - чёрный ящик. Но это под беды. Когда элемент аттачится к документу, он начинает реагировать на события и сам их рассылать, участвовать в расчёте стилей и лейаута, инвалидировать кеши браузера и дёргать их актуализацию, и тд, и тп. Короче, создавать дом элемент, да ещё и в документе, если не собираешься его прямо сейчас рендерить, - крайне расточительно.
Под объектом хоста вы имеете в виду внутреннюю реализацию элемента в браузере? Разве это не касается любого элемента, который мы создаем в DOM?
Пока у нас в браузере HTML и DOM кажется этой цены избежать невозможно?
P.S. и можно пожалуйста не минусить карму за обычный вопрос?
О том и речь - веб-компоненты гвоздями прибиты к дому, хотя сами как правило не рендерятся. Рендерится их содержимое. Иногда.
И в чем тут проблема? Мы в любом фреймворке в итоге работаем с элементами DOM в конечно счете. Какая разница: веб-компонент это или стандартный элемент?
Да, в SSR веб-компоненты становятся проблемой, потому что нам надо тащить эмуляцию DOM в node.js. Однако чисто для клиентских сценариев - веб-компоненты это отличное решение.
Виртуальный рендеринг, отрисовка на холсте, 3д сцены, аудио графы, удаленное управление, и тд.
Виртуальный рендеринг - отлично работает. Взять тот же lit-virtualizer
При чем тут отрисовка на холсте, если мы используем canvas?
Просто оставлю это https://modelviewer.dev/
Это вообще что за зверь?
Про удаленное управление - слишком абстрактный наброс. Не понятно, что конкретно имеется в виду
Глупый вопрос.
Написанный на three-js вьювер моделей. Попробуйте отрендерить таким образом сотню-другую объектов.
https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API
Да тот же ReactNative, RDP и тд.
Дмитрий, спуститесь до нас, простых смертных, и раскройте подробнее как Audio API связано с веб-компонетами? А также почему веб-компоненты мешают отрисовке на холсте?
Я пробежался по вашей статье, и не увидел сравнения с lit-virtualizer. Если что эта библиотека как раз отвечает за виртуализацию скролла, как и ваш $mol. Не исключаю, что ваша реализация может быть более эффективна. Однако, это не означает, что виртуализация в Lit ужасна и ее невозможно применять. Lit однозначно эффективнее большой тройки.
Классно объяснено! Хотя интересно, что при том, что вы называете RWC утилитками, (имхо) по стилю статья читается как описание небольшого фреймворка вокруг Web Components — с компонентами, реактивностью и архитектурой. Получилось даже чище, чем в Lit.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Reactive Web Components: реактивность без фреймворка