Если кратко - да все с ними ТАК. Это замечательный набор современных браузерных технологий, для решения реальных задач веб-разработки. Веб-компоненты позволяют делать очень многое, более просто и элегантно, чем это было бы без них. А главное, они позволяют, с потрясающей гибкостью, решать задачи “со звездочкой” - те, которые немного выходят за рамки и требуют более творческого подхода от разработчика.
Почему-же тогда по Хабру гуляют, кхм… некие одиозные личности (не будем показывать пальцем) и рассказывают нам про то, что веб-компоненты это ужас-ужас и полный провал? Давайте разберемся.
Сперва, небольшая ремарка о том, почему именно я чувствую за собой моральное право взять микрофон и встать на защиту упомянутых стандартов. Дело в том, что я активно использую все это в работе уже много лет, еще со времен первых черновиков и ранних спецификаций. Я держу руку на пульсе с первых сырых версий Polymer и до современного Lit. За это время, я лично спроектировал и воплотил множество, по настоящему, сложных приложений и отдельных универсальных виджетов. Я понимаю, что определение “сложного приложения” - для каждого может быть своим, и я имею в виду большие дэшборды и панели управления реального времени, с кучей графовых данных, летающих по веб-сокетам, с коллекциями объектов из сотен тысяч элементов. Простых, но очень разношерстных проектов, также, реализовано немало. Я, также, являюсь автором библиотеки Symbiote.js, которая построена на тех самых API, о которых дальше пойдет речь.
Еще одно важное уточнение. Когда мы обсуждаем какую-либо технологию, важно понимать, что любое инженерное решение - это компромисс. Не существует абсолютно идеальных “сферических в вакууме” технологий (ну кроме, конечно, <sarcasm>$mol</sarcasm>). При оценке чего-либо, мы всегда взвешиваем “за” и “против” - это и есть, по сути, наша работа. Само по себе, наличие “против” не перевешивает все возможные “за”, априори. У каждого такого компромисса - есть конкретная цена. Если эта цена приемлема - это повод всерьез рассмотреть использование той или иной технологии. Из этого принципа я и буду исходить в своих рассуждениях и выводах.
Бред
Начну с самой жести - откровенного вранья, манипуляций и подтасовок.
Нам рассказывают про то, что в веб-компоненты можно передавать свойства ТОЛЬКО с типом “строка”. При этом, ссылаются на нативный хук жизненного цикла attributeChangedCallback. Для передачи сложных типов - предлагают использовать парсинг JSON из значений атрибутов. Ребята, опомнитесь, HTML-атрибуты - это часть обычного HTML, у которого нет никакой прямой связи с JS-рантаймом. Если вам нужно модно-реактивно установить свойство любого типа для компонента - используйте простые советские модификаторы доступа - геттеры и сеттеры! Используйте нативные прокси для продвинутой работы с данными. Кто вам запрещает это делать? Удобно обратиться к свойству веб-компонента, таким образом, можно, практически, из любого современного фреймворка или напрямую через DOM API. Всерьез говорить про этот “недостаток” все равно, что пытаться общаться по факсу с человеком, который сидит рядом с вами в одной комнате, и жаловаться на медленную связь. Не доводите до маразма простые вещи!
Далее Shadow DOM - отличный способ изолировать внутренности вашего компонента от внешний влияний, как непредсказуемых так и, потенциально, вредительских. Нам говорят, что сама по себе изоляция - это огромная проблема, так как, сюрприз-сюрприз, не дает нам произвольно стилизовать внутреннее содержимое снаружи. Тут явная фича выдается за баг. Во первых, ну кто вас заставляет использовать Shadow DOM там, где это вам НЕ НУЖНО? Использовать Custom Elements БЕЗ Shadow DOM - это нормальная и даже хорошая практика. И это вообще разные независимые API. К слову, Shadow DOM вы можете подключить вообще, практически, к любому DOM-элементу. А во вторых, у вас есть куча элементарных способов безопасной настройки внутренностей вашего компонента через самые обычные CSS-переменные (дизайн-токены) и правила ::part(). И это даже еще не все. Ребята, просто учите современный CSS и то, как строятся нормальные дизайн-системы, чтобы так не позориться.
Еще, иногда, упоминают необходимость избыточного дублирования стилей в Shadow DOM каждого экземпляра компонента. Ой, а такой необходимости - нет. А есть API Adopted Style Sheets, которые давно поддерживаются во всех современных браузерах.
Еще, жизненный цикл веб-компонента начинается с конструктора, а вовсе не с аттача компонента в DOM, как нам уверенно заявляют некоторые малограмотные “специалисты”. Вы можете создавать кастомные элементы исключительно в памяти, манипулировать ими в рамках общего Document Fragment через самые обычные методы DOM API, без затратной отрисовки чего-то лишнего в браузере, и прикручивать, таким образом, виртуализацию для обмана широкой публики в цифрах бенчмарков, лол.
Полуправда
Общий реестр имен кастомных элементов в браузере - это правда. А вот то, что это фундаментальная неразрешимая проблема - НЕТ. Помните, я говорил о стоимости компромисса? Ну вот, тут эта стоимость - мизерная. Решение на уровне соглашения о именованиях с префиксами (или постфиксами), что может быть проще? Даже если вы что-то упустили и коллизия имен произошла - вы всегда можете переопределить проблемный компонент банальным наследованием. Браузер вам явно укажет на проблему в момент попытки регистрации. Это легко ловится интеграционным тестом. Никаких silent-падений. Естественно, это можно оборачивать в try/catch. Исходя из многолетней личной практики, я вам уверенно заявляю: все это не стоит выеденного яйца.
Вообще, общие пространства имен - это базовый и древнейший паттерн всего нашего программирования. От ключей в объектах, до доменных имен и статистически-уникальных идентификаторов сущностей в распределенных системах. Имена стандартных тегов HTML входят сюда-же. Этот паттерн используется повсеместно и вокруг него давно устоялись практики и стратегии. Плоская структура, часто, быстрее и надежнее древовидной. Делать из этого какую-то особую драму, в случае с веб-компонентами - не вижу никакого смысла. Это просто нюанс, который нужно держать в уме и придерживаться системного подхода.
Теперь о основных хуках жизненного цикла: connectedCallback и disconnectedCallback. Нам заявляют, какой ужас, эти коллбеки могут сработать “вхолостую”, при простом переносе элемента из одного места в DOM - в другое! Действительно, какой кошмар! Это ведь можно решить одним маленьким флагом, установленным при первичной инициализации. Но это, видимо, слишком сложно для некоторых. Таким образом, одну из главных и самых мощных возможностей стандарта (управление жизненным циклом изнутри) нам представляют как, высосанный из пальца, “недостаток”.
Также, отметим невозможность де-регистрации компонента, однажды зарегистрированного в одном документе. Это правда. А то, что это большая проблема - нет. Браузер просто хранит ссылку на конструктор. Памяти это занимает - минимум, на производительность - не влияет. Больше проблем бы было, если бы такая возможность существовала: нам приходилось бы гадать какой именно класс сейчас активен и думать что делать с ранее созданными элементами.
Правда
Я не был бы достаточно объективен, если бы не упомянул реально существующую проблему, или, скорее, важный нюанс: когда браузер парсит HTML документ в потоке, он дергает хук connectedCallback сразу, как находит ОТКРЫВАЮЩИЙСЯ кастомный тег, но ДО того, как распарсит его содержимое. Это приводит к тому, что, например, методы DOM API, с помощью которых, вы хотите взаимодействовать с потомками - могут не работать в этот момент. Человек, который не знает причину такого поведения - может обжечься. Решается отложенной загрузкой скрипта (defer) или использованием type="module". В этом случае, инициализация сработает ПОСЛЕ окончания парсинга и ошибки не будет. В Symbiote.js, для удобства, есть готовый кастомный хук жизненного цикла renderCallback, который решает этот вопрос и гарантирует доступ к DOM API.
Есть и обратна сторона: вы можете получить ссылку на веб-компонент, который еще не был зарегистрирован. В этом случае, API самого компонента будет недоступен. Для того, чтобы быть уверенным, что все готово к полноценному взаимодействию, можно использовать promise, возвращаемый customElements.whenDefined(name).
Вся эта неожиданная асинхронность в поведении может сбить с толку, если не знать о ней заранее. Но тут как с потерей контекста в функции - иногда мы с этим сталкиваемся, но знаем, что делать. В Symbiote.js эти вопросы решены на уровне архитектуры.
Обманутые надежды
Часто, негатив в сторону веб-компонентов начинается с обманутых надежд. Люди ждали нативную и высокооптимизированную замену популярным фреймворкам, а получили слишком низкоуровневый API. Но чьи-то нереалистичные ожидания вовсе не означают, что сам стандарт - плохой. Веб-компоненты не призваны заменить собой весь наш JS-зоопарк, они решают свой ряд специфических но очень важных проблем, и не имеют никаких достойных аналогов или альтернатив в этом.
Суперспособности
Так в чем-же реальная сила веб-компонентов? Я бы выделил 3 основные вещи:
1. Связь HTML c JS-рантаймом на уровне узлов.
Часто, фронтенд-разработчики теряют из фокуса тот факт, что именно HTML - это альфа и омега всего веба. И начинается путь HTML-файла, определяющего все, что происходит на странице, задолго до попадания в браузер. В общем случае, на серверной стороне, нет никаких абстракций, призванных обеспечить прямое взаимодействие с пользователем. А кастомные теги, в теле формируемого текстового документа - есть. Эти теги - идеальные нативные маркеры для вашей JS-интеграции, они дают не только удобные точки привязки, но и естественную бесшовную структуру (XML), которая органично ложится на старый добрый HTML, без изобретения отдельных велосипедов и лишнего вендор-лока. Это-же касается и шаблонов самих компонентов.
2. Атомарное и естественное управление жизненным циклом.
Custom Elements - это способ узнать реальное текущее состояние DOM напрямую от браузера и реагировать на него. Компонент появился - мы знаем, компонент исчез - мы знаем. И это без каких-либо внешних громоздких абстракций, универсально и надежно. Не важно кто и как создал компонент, или в какой момент участок документа был полностью перерисован - мы знаем, когда и как нужно реагировать.
3. Базовая компонентная модель.
Custom Elements - это идеальная основа и фундамент для создания решений более высокого уровня. От библиотек общего назначения (типа Lit или Symbiote.js), до ui-китов, сложных универсальных виджетов, микро-фронтендов и мета-приложений-агностиков. Мощнейшая компонентная модель и базовый API - у нас есть из коробки. Сразу с документацией и широкой поддержкой. Не нужно изобретать очередное колесо. Работает везде, в React, Angular, Vue, с другими веб-компонентами, самостоятельно, в SPA, на динамических, гибридных или полностью статических страницах и так далее.
Мотивы хейтеров
Довольно очевидны. Инвестиции в альтернативные решения под угрозой. Страх потерять актуальность на рынке. Необходимость что-то опять изучать за рамками своей уютной мета-платформы. Попытки продать себя и продукты своей деятельности, под предлогом “экспертности”. И так далее.
Да простит меня Хабр за мой раздраженный тон. Но, честно говоря, достало уже. Изучайте истинные возможности платформы и современные стандарты. Не слушайте псевдо-экспертов.
Комментарии (105)
slavcopost
04.04.2026 10:22"бифы" программистов это весело :)
Поддержу-ка я автора, ссылаемая здесь статья откровенно глупая.
OlegZH
04.04.2026 10:22Что не так с веб-компонентами?
Если кратко - да все с ними ТАК. Это замечательный набор современных браузерных технологий, для решения реальных задач веб-разработки. Веб-компоненты позволяют делать очень многое, более просто и элегантно, чем это было бы без них. А главное, они позволяют, с потрясающей гибкостью, решать задачи “со звездочкой” - те, которые немного выходят за рамки и требуют более творческого подхода от разработчика.
А что Вы можете сказать начинающему разработчику, который только хочет изучить Ваши веб-компоненты?
Во-первых, можете ли Вы перечислить их; назвать их сильные и слабые стороны, а также обрисовать в целом наиболее подходящий их изучения/овладения?
Во-вторых, можете ли Вы привести сравнительные примеры того, как одни и те же задачи решаются без применения веб-компонентов и с применением веб-компонентов.
И, конечно же, в-третьих, можете ли Вы объяснить, почему, вообще, возникают эти самые задачи "со звёздочкой"? (Кстати! А что это за задачи?)
i360u Автор
04.04.2026 10:22Боюсь, чтобы полноценно ответить на ваш комментарий нужно целую отдельную статью написать. Поэтому простите, но пройдусь кратко:
Начинающему разработчику я посоветую почитать доки, и написать пару компонентов самому, чтобы получить базовое представление. Можно попросить ИИ помочь, он все подробно объяснит и посоветует куда дальше двигаться.
Про сильные стороны - я написал в статье. Эти три пункта - и есть то, ради чего стоит в эту тему вникать. Образно говоря, веб-компоненты - это клей, который склеивает HTML, JS, CSS в тех точках вашего приложения, где вам это нужно. Причем, как на клиенте, так и на сервере, как в пространстве (положение в DOM), так и во времени (контроль жизненного цикла). Без них, такая задача как, например, SSR - становится на порядок сложнее.
Простой пример задачи со звездочкой - это виджеты. Представьте, что вы создаете сервис, позволяющий вставить чат, прием оплаты или загрузку пользовательских файлов на любой сайт. Сайты ваших клиентов могут быть реализованы на чем угодно - любом фреймворке, CMS, серверном шаблонизаторе... С любым пайплайном сборки, с любыми "подводными камнями", которые только можно и нельзя придумать. Так вот, веб-компоненты - это, практически, единственный способ создать такое решение с минимальным количеством боли и без необходимости писать отдельные обертки и адаптеры под весь этот всевозможный зоопарк. И даже если вы будете писать эти адаптеры - это будет сделать на порядок проще, если внутри будет общее универсальное решение, поддерживаемое по умолчанию, на уровне стандартов самой платформы.
nin-jin
04.04.2026 10:22Вот вам задача с двумя звёздочками: встраиваете вы к себе этот прекрасный сторонний чат, но понимаете, что вместо кнопки "отправить" вам нужен селект из двух вариантов "отправить сейчас" и "отправить позже", а рядом с ним нужен флаг "отправить тихо", а при наведении на имя пользователя нужно показывать всплывашку со статистикой активности на вашем сайте, да и вообще имя пользователя должно быть разного цвета, в зависимости от ролевой модели вашего сайта. Но как на зло, автор чата даже подумать не мог, что вам потребуются такие кастомизации, поэтому не подстелил где-надо slot, где надо part. Расскажите же, про потрясающую гибкость веб-компонент в решении этой задачи.
ionicman
04.04.2026 10:22Делается очень просто, если компонент нормально отправляет события, и чуть сложнее, если нет.
Именно потому, что ты вообще не понимаешь и не принимаешь ничего кроме своего, ты и не можешь разобраться, как работать с веб-компонентами. Тебе куча народа это уже говорила, но, как говорится - "а еслим читан, то не понят, а если понят - то не так".
nihil-pro
04.04.2026 10:22Во-вторых, можете ли Вы привести сравнительные примеры того, как одни и те же задачи решаются без применения веб-компонентов и с применением веб-компонентов.
Synopticum
04.04.2026 10:22Если бы с ними все было так, их бы использовали. Безотносительно наличия хейтерских или фанбойских статей. 15 лет уже технологии скоро будет.
i360u Автор
04.04.2026 10:22Ну да, ну да, конечно, никто не пользуется. У Lit - двукратный рост по загрузкам в npm за год, у Symbiote.js - трехкратный. GitHub, YouTube, Microsoft, IBM и даже SpaceX - это совсем-совсем никто.
Synopticum
04.04.2026 10:22Да, да. Я тоже руководствовался громкими именами когда повелся на этот хайп в свое время. В реальности оно крутится под капотом у полутора землекопов, и то потому что зачем то взяли, а теперь выпилить не могут.
Cringeon
04.04.2026 10:22Ангуляром тоже пользуются и Гугл ?который его и "поддерживает") и некоторые громкие имена из Легаси банкинга в рф, но хорошим фреймворком он от этого не стал
i360u Автор
04.04.2026 10:22Я вам больше скажу, даже React - лидеру всех на свете рейтингов по использованию, ОЧЕНЬ далеко до звания "хорошего", в техническом плане. Поэтому "пусть расцветают сто цветов". А те, кому надо, выберут то, что им надо.
Cringeon
04.04.2026 10:22То есть не веб компоненты
Лишняя абстракция же просто, что в б2б что в б2с совсем другие проблемы, веб компоненты их никак не решают
i360u Автор
04.04.2026 10:22Веб-компоненты - это неотъемлемая часть современного DOM API, называть это лишней абстракцией, при том, что все остальное (фреймворки) - это и есть абстракции над DOM - крайне странно. Вы путаете курицу с яйцом.
Про то, какие проблемы они решают - буквально написано и в статье и в комментах. Если никогда не выходить за рамки одной мета-платформы, вы может никогда и не встретите таких задач. Веб-компоненты нужны, прежде всего, для тех, кто с такими задачами сталкивается.
https://github.com/rnd-pro/jsda-kit?tab=readme-ov-file#jsda-kit-vs-nextjs - вот тут становится все более очевидно.
Cringeon
04.04.2026 10:22Единственное решение реальных проблем это изоляция с shadow dom, но и она не работает из коробки, как тот же iframe, и тем более не сработает в принципе с 3rd party которые на этих компонентах не написаны
У реальных приложений в вебе вообще другого рода проблемы, компоненты их никак не решают
Dx тоже сомнительный
i360u Автор
04.04.2026 10:22Ок, хорошо. У вас Shadow DOM не работает, у меня - работает. У вас - компоненты проблем не решают, у меня - решают. Как минимум, половине из нас двоих, веб-компоненты - нужны.
Вот только не надо рассказывать нам про "реальные" приложения таким тоном, как будто вы в этом лучше разбираетесь. У вас нет никаких оснований для этого. Вы можете поделиться собственным опытом, но не говорите за всех.
dlartagnan
04.04.2026 10:22Мы мигрировали на Lit год назад - это было лучшее решение. И более приятного DX я в жизни не имел.
Synopticum
04.04.2026 10:22Чтобы не быть голословным, я когда-то очень ими интересовался и успел поработать на продакшене с Polymer и Lit. До сих пор иногда пишу небольшие компоненты без фреймворков, чтобы по быстрому вставить в какую-нибудь древность. За красивыми словами про глобальные стандарты (как будто кому то не пофиг), нативность против ненативности (как будто кому то не пофиг) в реальности это полное говно уровня чуть выше бэкбона с точки зрения DX.
Можно просто открыть доку к любой либе поверх них, включая либу многоуважаемого автора, посмотреть какое это убогое говно и закрыть.
Начинающим разработчикам рекомендую не тратить на них много времени, ознакомиться и просто иметь в виду, что оно вообще есть.i360u Автор
04.04.2026 10:22Уже второй раз вы приходите в комменты к моим статьям чисто нахамить, на ровном месте, без внятных аргументов. По существу есть что сказать?
Synopticum
04.04.2026 10:22Ты возможно что-то перепутал, но я напомню что ты публикуешься на открытом ресурсе.
В эпоху агентской разработки побеждает тот, на ком натренирована максимально обширная и качественная кодовая база. Я (речь про фронтенд) уже больше половины кода вообще не пишу, а ревьюю и правлю. А кто-то по слухам не уже пишет совсем.
Если ты не используешь нейронки для разработки, про работу можешь забыть уже сейчас. Если ты используешь нейронки, чтобы генерить приложения из подобного шлака - аналогично. Если кто-то до сих пор не понял, что руками больше писать не надо, то очень скоро он это поймет через рынок.Какой у тебя там красивый стандарт лежит в основе всем глубоко насрать, так как людям нужны разработчики, которые могут делать просто быстро, качественно и поддерживаемо. И это правильно.
i360u Автор
04.04.2026 10:22Вот это аргумент, поддерживаю! О бедных вайбкодерах забыли подумать. Не хочу тебя пугать, но нейросети становятся умнее, и сами скоро будут выбирать более легковесные технологии. А вот ты - умнее явно не становишься.
Впрочем, не вижу больше смысла в препираниях на таком уровне, дальше - игнор.
Synopticum
04.04.2026 10:22Удачи в в твоем бизнесе на лошадином извозе после изобретения автомобилей.
Sheti
04.04.2026 10:22какие нейронки? ChatGPT не может элементарнейший конфиг для Postfix написать не наделав кучу детских ошибок.
Synopticum
04.04.2026 10:22Не знаю как для postfix, на фронтенде вся рутина полностью убита, если формализовать требования нейронке на вход, а это не так сложно
jlllk
04.04.2026 10:22которые могут делать просто быстро, качественно и поддерживаемо
Золотые слова, но что они делают в контексте вайбкодинга?
Synopticum
04.04.2026 10:22Не знаю, а где в моем комментарии вы увидели, что я говорю о вайбкодинге? Откуда такой контекст?
strelkan
04.04.2026 10:22так вот же он: "в эпоху агентской разработки", и дальше всё сразу с вами понятно становится
Kenya-West
04.04.2026 10:22Начну с самой жести - откровенного вранья, манипуляций и подтасовок.
Нам рассказывают про то, что в веб-компоненты можно передавать свойства ТОЛЬКО с типом “строка”
... но ведь HTML-атрибуты (которые вы дальше по тексту разбираете) действительно передаются через коллбэк в виде строк, вы попросту не сможете это опровергнуть, ибо это правда. Ну, и в принципе
element.getAttribute()всегда строковый. Пришлось отложить чтение статьи, так как опровергается очевидно и заведомо правильный тезис, лол.Мне кажется, тот абзац надо переписать яснее, ибо я его так и не понял.
i360u Автор
04.04.2026 10:22Ну куда уж проще: атрибуты - это атрибуты (текст). Свойства класса - это поля объекта (в JS). Не нужно путать атрибуты со свойствами. Не нужно утверждать, что атрибуты - это единственный способ передать параметр. Все нормальные библиотеки, основанные на веб-компонентах, передают данные в js-рантайме, никто не использует парсинг JSON из атрибутов, если это не требуется специально для чего-то.
Synopticum
04.04.2026 10:22Комментарий не для автора, а для начинающих фронтенд-разработчиков. Не начинающие уже и так либо все знают, либо уволены. Если вы хотите работать, не выбирайте эту херь с веб-компонентами. Этот путь - он тупиковый. Автор в свое время поставил не на ту лошадку, а теперь, когда пушной зверек уже пришел, фрустрирует по статье в неделю.
Как реально работает сейчас фронтенд-разработка:Строятся хорошо формализованные требования к дизайну, создается достаточно гибкий юайкит. Дизайнеры, которые до сих пор путают фигму и фотошоп пойдут ко дну следующими.
Этот юайкит реализуется в виде сторибука на стороне фронтенда, мапится на данные с фигмы насколько это возможно. Сторибук проверяется отдельным агентом, проверки встраиваются в пайплайны при желании
Из компонентов этого юай-кита дизайнерами собираются экраны. Экраны на стороне фигмы валидируются плагином на предмет отсутствия компонентов не из юай-кита. Unsafe-зоны с непредсказуемым результатом реализации по желанию.
Эти экраны экспортируются из фигмы в виде JSON и преобразуются в пригодное для нейронки дерево компонентов.
Другой агент из этого дерева делает в точности то, что вы сверстали бы руками, но в несколько (десятков) раз быстрее. При этом сам проверяет результат в браузере.
Далее по вкусу и возможностям, автоматическая реализация интеграций, особенно при наличии OpenAPI или аналогичных контрактов
Так убирается куча ручной работы и вырастает скорость. И это в разы усиливает фокус на том ЧТО надо, а не на КАК. Еще это приводит к тому, что джуны и даже мидлы больше просто не нужны. И к этой реальности им надо подстраиваться: учить теорию, учить паттерны, учиться получать от нейронки результат, соответствующий и бизнесовым и техническим требованиям.
Если вы не будете так делать, вы будете не нужны. Фронтенд в своей массе - это первые кандидаты на выход, если не перестраиваться.
Ну либо можете писать нетипизируемый код, философствовать о плюсах и минусах размещения компонентов в глобальной области и вздыхать о нереализовавшихся мечтах, делиться этими чувствами на собеседованиях. Это сократит конкуренцию на рынке труда.
Mr_FatCat
04.04.2026 10:22Проблема в том, что вы сами не понимаете, с чем боретесь. ИИ-модели прекрасно разбираются в стандартах, и если попросить агента разработать веб без зависимостей, он это сделает именно на тех стандартах платформы, с которыми вы боритесь. Вы упускаете главное: те же фреймворки, на которых ИИ вам нагенерит код по умолчанию, будут работать поверх тех же базовых технологий, о которых написана эта статья. В чем, собственно, ваша проблема? Ну то есть, это снова фундамент, который вы пытаетесь выбить из-под ног, чтобы все рухнуло. А подход с опорой на стандарты, кстати, банально жрет меньше токенов.
Другой вопрос: почему вы так токсично общаетесь? Просто, как будто веб-компонент наступил вам на ногу. Ведь речь в статье совсем не о том, что людям нужно учить, а о том, чтобы не тянуть за собой ненужные зависимости. Можете, кстати, отправить этот разговор той же ИИ-модели для фактчека - посмотрите, чью сторону она займет.
Synopticum
04.04.2026 10:22Я без всяких нейронок вам скажу, что никакие веб компоненты ни в реактовую, ни в какую либо другую кодовую базу модель не нагенерит, если я ее специально не попрошу.
Так что нет, не на тех стандартах.
И я не борюсь, я просто говорю есть. Выйдите на рынок труда и посмотрите сами.
codegentop
04.04.2026 10:22когда вы дописали "Так что нет, не на тех стандартах." - стало противоречить словам и действительности ))
Synopticum
04.04.2026 10:22Только если не учитывать контекст беседы. Я использую реакт, вью, свелт и некоторые их производные. Никто из них не использует апи из стандарта веб компонентов. И ни одна модель их в кодовую базу по умолчанию не предложит для генерации. Потому что они никому там не нужны и нейронка эти вероятности видит
Mr_FatCat
04.04.2026 10:22Я, к слову, согласен с вами по поводу текущего состояния рынка труда - сам активно в нем участвую. Да и автор статьи, кажется, с этим фактом не спорил.
Но суть-то в другом: фреймворки все равно работают на нативных веб-стандартах браузера, от этого никуда не деться. Вы же сами пользуетесь нейронками - у вас есть идеальный инструмент под рукой, чтобы разложить этот технический нюанс по полочкам и убедиться. Попробуйте.
Synopticum
04.04.2026 10:22Не работают фреймворки на стандарте веб компонентов.
Mr_FatCat
04.04.2026 10:22Lit, Stencil, LWC и многие другие инструменты построены ИМЕННО на стандарте веб-компонентов. А те инструменты, которые перечислили вы - да, внутри себя используют другие механики. Но даже им приходится с этим стандартом считаться, потому что этого требует индустрия:
У Vue официально поддерживается макрос
defineCustomElementдля сборки в веб-компоненты прямо из коробки.У Svelte есть встроенная директива и флаг компилятора
customElement: trueдля тех же задач.У Angular под это вообще выделен целый официальный пакет Angular Elements.
А команда React еще в 19-й версии (2024 год) в официальном блоге отчиталась о существенном улучшении поддержки Custom Elements (наконец-то исправив свои старые архитектурные костыли с пропсами именно ради совместимости с этим стандартом).
Вы утверждаете, что эти технологии никому не нужны, но создатели ваших любимых фреймворков почему-то потратили массу времени на интеграцию этого стандарта.
Нейронке не нужно “учитывать вероятности”, она читает официальные спецификации. И если попросить ее сделать независимый переиспользуемый виджет, она без проблем соберет вам нативный кастомный элемент, который будет работать где угодно.
Synopticum
04.04.2026 10:22Чтобы собрать нативный переиспользуемый виджет, веб компоненты тоже не нужны. Откройте для себя zero runtime компоненты того же свелта. Кстати будет лучше чем веб компоненты.
Ну и естественно если вы попросите в свелтовом проекте создать нативный переиспользуемый виджет, то про веб компоненты модель без напоминания не вспомит.
Synopticum
04.04.2026 10:22Что до поддержки фреймворками, вы пробовали это использовать? Может объясните для чего она нужна? Хоть один юзкейс, по какой причине мне надо одновременно париться о двух разных способах управления компонентом и их жизненным циклом.
Я кроме как подрубить готовый компонент на том же lit не представляю зачем это надо и не знаю никого, кто это использует. А я знаю много разработчиков
nin-jin
04.04.2026 10:22Да что уж там, даже в $mol есть поддержка веб-компонент, на реализацию которой была потрачена масса времени (целый час).
replicate_1
04.04.2026 10:22Я смотрю, у вас заготовлены ссылки на все случаи жизни. Вы на Хабре работаете как глобальный полифилл - в каждой ветке затычка. Видимо, дела у моля совсем плохи, раз вы выбрали такую стратегию продвижения...
KonBone
04.04.2026 10:22Напишите статью на эту тему. И статью не начинающим фронт-энд разработчикам, а уже скорее дизайнерам, которым хотелось бы попробовать что-то новое, т.к. исходя из ваших слов разработчик уже и не нужен тут.
Synopticum
04.04.2026 10:22Я думаю, напишут и без меня. Разработчик в плане механический кодер (а это куча фронтовой работы) больше действительно не нужен. Тех кто не учится работать так как я описал, увольняют. Нужен опытный оператор и ревьюер нейронки + никуда не деваются задачи по просяснению требований, а это не механический скилл а скорее софтовый.
Причина простая: хоть ты сто раз сеньор, 'talk is cheap, show me the code'. Скорость разработки видна по гитхабу, качество видно по соответствию требованиям. И зачем платить от $3000 при цене нейронки в $200? Против такого же сеньора с настроенным агенстким флоу ты уже никто. Не учишься - конкурировать будешь теперь с мидлами на нейронках в лучшем случае. К счастью, те у кого мозг, а не ганглии, в большинстве переучиваются.
Точно также механические дизайнеры, которые не способны собрать нормально юайкит и собрать из него экраны тоже не нужны. Нейронкам на вход нужны максимально формализованные требования, читай дизайны из компонентов накиданные без всяких Shape и Text и отступов "я так вижу" для красоты. Не умеешь так делать - замедляешь работу дальнейших этапов - теряешь скорость разработки по сравнению с конкурентами.
Дизайнерам которые хотят попробовать что-то новое я бы посоветовал не ждать статей на хабре, которые все разжуют, а включать голову и думать, пока не пришли ребята поумнее, как уже пришли на фронтенд.
KonBone
04.04.2026 10:22Да, с бизнесом всё понятно, на эту тему у меня есть мысли даже, пожалуй, для статьи.
Просто совет в виде статьи, возможно разбор вашего опыта, был бы лучше комментариев под постом, который прочитают 4 человека, если вы бы, конечно, хотели бы этим опытом поделиться.
Synopticum
04.04.2026 10:22Автор, ходить по каждому комментарию и по ставить по минусу - это позорно и жалко :) Более жалко будет только оправдываться, что это не ты.
KonBone
04.04.2026 10:22Жалко, кажется, это писать ещё один, очередной провокационный коммент.
И верх этого, это жаловаться на это при сказанном ранее:Ты возможно что-то перепутал, но я напомню что ты публикуешься на открытом ресурсе.
Synopticum
04.04.2026 10:22Ты прав! Это еще было не жалко! Вот реально дно:
@KonBone - первый коммент с 2022 шгода, пишет из песочницы
@replicate_1 - по приглашению от @i360u, недельная рега
@Mr_FatCat - по приглашению от @i360u
@codegentop – по приглашению от @Mr_FatCat
Тут теряюсь, то ли @i360u сюда воспитательницу еще позвать забыл, то ли пора его пощупать за всякие места за ботоводство. Но в любом случае - это днище.
Synopticum
04.04.2026 10:22@Exosphere посмотрите @KonBone @replicate_1 и @codegentop на всякий - минимум комментов, все комменты в топиках автора, всегда появляются, чтобы оставить коммент в его пользу и молча посливать комментарии против. Насколько я знаю, ботоводство запрещено правилами.
Реальным пользователем выглядит только @Mr_FatCat
KonBone
04.04.2026 10:22Да, @Exosphere, посмотрите, пожалуйста.
Честно говоря редко встретишь человека в комментариях, который настолько пренебрегает правилом.
Оскорблять других пользователей, не следить за эмоциями
https://habr.com/ru/docs/help/rules/Synopticum
04.04.2026 10:22Уважаемый @i360u! Я по отношению к вам и вашим ботам адресных оскорблений не допускал. А называть описываемое в статье барахло - барахлом правилами не запрещено. То, что вы воспринимаете критику вашего решения как хамство по отношению лично к вам, еще не делает его таковым.
А вот сливать втихую карму ботами это поинтереснее будет.
i360u Автор
04.04.2026 10:22Чел, прости, но я искренне считаю, что ты психически не очень здоровый человек. Может это и не так, но выглядит - так. Я бы хотел тебе как-то помочь, но, честно, не знаю чем.
Synopticum
04.04.2026 10:22@Exosphere переход на личности и оскорбление.
Mr_FatCat
04.04.2026 10:22и это просто милые слова… https://habr.com/ru/articles/1019206/comments/#comment_29775948
flancer
04.04.2026 10:22Дружище, я тебе карму заминусил за твой стиль общения. Ты лично не считаешь свои выпады хамством, например такой:
Можно просто открыть доку к любой либе поверх них, включая либу многоуважаемого автора, посмотреть какое это убогое говно и закрыть.
Я, например, считаю.
У тебя такой пронзительный стиль общения, что тут боты не нужны для кармослива. Ты и сам прекрасно справляешься.
KonBone
04.04.2026 10:22Дополню тут, раз уж делимся теориями заговора:
Ситуация выглядит, как попытки пиара $mol путём "Задушить конкурента"(?).
@cmyser - явно упомянул, что связан с ним
@nin-jin - также, вероятно, связан, хотя прямо не говорил, либо я уже забыл
@Synopticum - его связь со $mol не понятна, но общий мотив сообщений похож на стратегию их пиара
Не прошу с этим ничего делать.ionicman
04.04.2026 10:22@nin-jin - это нездоровый автор поделия под названием mol и всей его экосистемы, не умеющий ни общаться, ни принимать каую-либо критику, а @cmyser очень похож на его альтер-эго.
@Synopticum раньше не встречал, но судя по его ответам, пахнет точно такойже cat-piss - либо тотже лагерь, либо альтер-эго.
Не прошу с этим ничего делать.
А вот я, наборот, прошу @Exosphere что-нибудь с этим сделать, ибо эти персонажи реально достали, как и весь их братвополь.
Что до веб-компонент - это лучшее и реально полезное, что случалось с вебом за последнее время.
cmyser
04.04.2026 10:22Дима, слава богу, здоров)
Критику он принимает, но остро отвечает ( что, согласен, не всегда хорошо и часто превращает спор в полемику )
я не альтер эго, я искренне считаю что $mol имеет огромное кол-во преимуществ с которыми невозможно спорить и от которых невозможно отказываться
приходите лично пообщаться на t.me/piterjs ( лично невозможно токсить, уверяю вас )
обсудим веб компоненты и иже с ними)ionicman
04.04.2026 10:22Критику он не принимает, для него есть только его поделие и все, остальные, кто не с ним - идиоты - это не признак здоровости.
Кроме этого он не гнушается манипуляциями и переходами на личности, что тоже не признак ума или чего-то ещё.
Чтобы не быть голословным, вот последняя его статья, где все отлично видно, особенно в комментах https://habr.com/ru/articles/1014708/
mol, если его сделать честным, а не как делает автор, например исключая оффскрин ноды и сравнивая с либами где они честно присутствуют ни какими плюсами по скорости обладать не будет, а с таким самодуром во главе - и подавно.
cmyser
04.04.2026 10:22да, те ответы его не красят, не буду как то оправдывать
но по бенчам - они все честные ( в js-framework мола нет )
https://t.me/giper_dev/11/24890 - гляньте, там разные js либы используются, никакого жульничества, чистый js
про рендеринг в js-framework-bench скажу что мол не умеет рисовать не виртуализированный интерфейс
Тут я склоняюсь к тому что бенч не отражает реальных возможностей фреймворков, я бы разрешил виртуализацию всем ( пользователю ведь хочется быстрый интерфейс а не 100К честно отрендеренных карточек за минуту реального времени )
если хочеться приятно поболтать, приходите на t.me/piterjs ( быть токсиком лицом к лицу просто невозможно! )
cmyser
04.04.2026 10:22мы никого не душим) если кого и критиковать дак это react)))
скорее просто пытаемся разобраться в вопросе веб компонент, ну и спорим, где то аргументировано где то не очень
я живой, отдельный человек) приходите на t.me/piterjs
пообщаемся лично ( в живую кстати, никогда не видел что бы кто то токсчил так что живое общение - лучший способ коммуникации я считаю)
я пишу на моле, Дима - его автор, третий это хз кто, хейтер какой то левый
replicate_1
04.04.2026 10:22Открою вам потрясающий секрет: в реальном ИТ-мире помимо нейронок и ботов существует такое понятие, как коллеги.
Когда вам по делу больше ответить нечего, в ход идут универсальные заглушки про "нейрослоп" и "это все боты". Забавно, что вы вообще рассуждаете о "дне" на фоне того, что вы пришли хамить всем подряд и проявляете поразительно аномальную активность в негативном ключе исключительно к одному автору во всех ветках.
Если в этом треде и есть подозрительные персонажи, чье поведение стоит изучить модераторам - так это вы и те, кто тут спамит ссылками на свой проект и откровенно неадекватными скриншотами.
BelkinVadim
04.04.2026 10:22Не любите веб компоненты? Вы просто не умеете их готовить.
Возможно многие выбирают не ту задачу для веб компоненты. Можно начать с простого UI kit на веб компонентах для проекта на vue, svelte или ещё чем-то
cmyser
04.04.2026 10:22часто вижу похожее мнение, не согласен с ним
задача же у нас всех одна - нарисовать удобный быстрый интерфейс
тут веб компоненты проигрывают, сильно проигрываютionicman
04.04.2026 10:22Кому они проигрывают? Что опять за чушь?!
Ваша фраза звучит примерно так "CSS проигрывает FastApi", ага.
Любой инструмент работает в контексте, так вот, если без фреймворка и нативно, без сборщиков и тд требуется нарисовать "красивый и удобный интерфейс", то у веб-компонент просто не существует конкурентов.
И рассматривать их надо не как конкурентов фреймоворков, а как дополнительная киллер-фича, которую можно использовать совместно, это же касается и shadow DOM.
cmyser
04.04.2026 10:22Не чушь, надо было сразу ссылку дать
они проигрывают по потреблению памяти
вот тут сделал аналитику https://habr.com/ru/articles/1019420/
И рассматривать их надо не как конкурентов фреймоворков, а как дополнительная киллер-фича, которую можно использовать совместно, это же касается и shadow DOM.
Согласен. Просто много появляется фреймворков основанных чисто на них, и они уже конкурируют с "обычными" фреймворками
ionicman
04.04.2026 10:22Вы реально думаете, что сравнивать сколько потребляется памяти в нэтиве DOM элементов и js объекты, которые потом плюсом рендерится в элементы DOM - это действительно корректно? Особенно если учитывать нагрузку на CPU при этом.
Если да - у меня больше вопросов нет)
cmyser
04.04.2026 10:22не совсем коректно, да
но мол использует виртуальный рендеринг и не деградирует, а вот всё остальное - деградирует
dlartagnan
04.04.2026 10:22О боги, вы опять передёргиваете факты. Скажите пожалуйста, а ваш $mol не в DOM рендерится? А после рендера каждого компонента в DOM узел у вас разве не выделится тот же объём памяти, что и у веб-компонентов?
Вы берете специфичный кейс ленивой инициализации (который в большинстве приложений не нужен), возводите его в абсолют, и кричите: смотрите, народ, веб-компоненты в 8 раз потребляют больше памяти, чем $mol!
Поэтому с вами и невозможно дискутировать, потому что вы живёте в своем мире вымышленных проблем.
cmyser
04.04.2026 10:22не передергиваю
мол использует виртуальный рендеринг и не деградирует, а вот всё остальное - деградирует, так как рендерит полностьюdlartagnan
04.04.2026 10:22Без комментариев)
cmyser
04.04.2026 10:22по памяти Если бы мол рендерил всё - было бы так же
но он же не рендерит
кейс не специфичный - проблема производительности сейчас массовая
я не стараюст как то передернуть, в сущности то вы правы - но фактически нет
проблема веб компонент в том что им обязательно занять эти минимальные 124 байта, вот суть то, еще до обработки уже памяти больше нужноdlartagnan
04.04.2026 10:22Проблема производительности массовая, потому что VDOM когда-то победил. Но благо сообщество опомнилось, и стали появляться нормальные фреймворки.
nin-jin
Вы забыли оставить ссылку на статью, на которую написали свою реакцию, чтобы она не выглядела, как диалог с воображаемым другом: https://habr.com/ru/articles/1014708/
i360u Автор
Вы с этим сами прекрасно справились.