Вы, похоже, кроме названия, так ничего не прочитали.
Веб компоненты вообще НИКАК не противоречат и не мешают ни использованию ИИ (модели очень хорошо ориентируются в стандартах), ни какой-либо модифицируемости. Тут вы просто признаетесь, что не понимаете о чем говорите.
Изоляция Shadow DOM идет сверху вниз потому, что каскадная модель CSS утроена именно так, и не наоборот. Конфигурировать снаружи - ВОЗМОЖНО. Учите стандарты, прежде чем делать такие заявления. Кроме того, использовать Shadow DOM в компонентах - НЕ ОБЯЗАТЕЛЬНО. Хватит тиражировать эту глупость, в статье про это подробно написано. iframe - это полноценный window в вашем документе, использовать его ради изоляции - убийство производительности. У iframe и еще проблемы есть, но вы их как-нибудь сами изучите. Про встраивание уязвимости - тоже полный бред. Вы встраиваете фиксированный код, который проверяется по хэш сумме и прекрасно работает с SRI политиками. 3rd party библиотеку в компонент завернуть проще простого. Если ВЫ конкретно не знаете как- это ВАШ skill issue.
API веб-компонентов вообще НИКАК не мешает SEO. Достаточно не прятать SEO-контент внутри Shadow DOM. Если вы делаете это, вы САМИ стреляете себе в ногу, это просто глупо.
Про энтерпрайз и B2B вы тоже поосторожнее делайте заявления, вы разговариваете с человеком, который за много лет в этом вашем энтерпрайзе повидал всякое. Еще больше - спроектировал и воплотил в жизнь. А вот из чего вы делаете свои выводы - совершенно не понятно.
Про DX - тоже бред. За DX - идите к библиотекам, у них с этим все в порядке. Есть куча современных либ, основанных на веб-компонентах. Одну из них я сам написал. И ожидать от низкоуровнего API - DX уровня библиотеки - глупо. Вы бы еще весь DOM API обвинили в плохом DX, лол.
Ок, хорошо. У вас Shadow DOM не работает, у меня - работает. У вас - компоненты проблем не решают, у меня - решают. Как минимум, половине из нас двоих, веб-компоненты - нужны.
Вот только не надо рассказывать нам про "реальные" приложения таким тоном, как будто вы в этом лучше разбираетесь. У вас нет никаких оснований для этого. Вы можете поделиться собственным опытом, но не говорите за всех.
Веб-компоненты - это неотъемлемая часть современного DOM API, называть это лишней абстракцией, при том, что все остальное (фреймворки) - это и есть абстракции над DOM - крайне странно. Вы путаете курицу с яйцом.
Про то, какие проблемы они решают - буквально написано и в статье и в комментах. Если никогда не выходить за рамки одной мета-платформы, вы может никогда и не встретите таких задач. Веб-компоненты нужны, прежде всего, для тех, кто с такими задачами сталкивается.
Я вам больше скажу, даже React - лидеру всех на свете рейтингов по использованию, ОЧЕНЬ далеко до звания "хорошего", в техническом плане. Поэтому "пусть расцветают сто цветов". А те, кому надо, выберут то, что им надо.
Я до конца не уверен, клон ли вы Дмитрия, или настоящий живой человек, но что касается общения - ему явно стоило бы у вас поучится. По технической части я вернусь с фидбеком позже.
Чел, прости, но я искренне считаю, что ты психически не очень здоровый человек. Может это и не так, но выглядит - так. Я бы хотел тебе как-то помочь, но, честно, не знаю чем.
Вы почему-то скрыли от публики часть результатов вашего-же изначального сравнения. Именно ту, где были реальные значимые цифры, и они были СИЛЬНО не в пользу $mol. Кроме того, вы не боитесь открыть ящик Пандоры и добиться того, что кто-то все-таки не выдержит, и потратит время на РЕАЛЬНОЕ сравнение? Боюсь, оно будет разгромным.
Боюсь, чтобы полноценно ответить на ваш комментарий нужно целую отдельную статью написать. Поэтому простите, но пройдусь кратко:
Начинающему разработчику я посоветую почитать доки, и написать пару компонентов самому, чтобы получить базовое представление. Можно попросить ИИ помочь, он все подробно объяснит и посоветует куда дальше двигаться.
Про сильные стороны - я написал в статье. Эти три пункта - и есть то, ради чего стоит в эту тему вникать. Образно говоря, веб-компоненты - это клей, который склеивает HTML, JS, CSS в тех точках вашего приложения, где вам это нужно. Причем, как на клиенте, так и на сервере, как в пространстве (положение в DOM), так и во времени (контроль жизненного цикла). Без них, такая задача как, например, SSR - становится на порядок сложнее.
Простой пример задачи со звездочкой - это виджеты. Представьте, что вы создаете сервис, позволяющий вставить чат, прием оплаты или загрузку пользовательских файлов на любой сайт. Сайты ваших клиентов могут быть реализованы на чем угодно - любом фреймворке, CMS, серверном шаблонизаторе... С любым пайплайном сборки, с любыми "подводными камнями", которые только можно и нельзя придумать. Так вот, веб-компоненты - это, практически, единственный способ создать такое решение с минимальным количеством боли и без необходимости писать отдельные обертки и адаптеры под весь этот всевозможный зоопарк. И даже если вы будете писать эти адаптеры - это будет сделать на порядок проще, если внутри будет общее универсальное решение, поддерживаемое по умолчанию, на уровне стандартов самой платформы.
Забавно, что вы привели ссылку на статью, как раз защищающую веб компоненты, где автор полемизирует с автором приведенной цитаты. Она даже называется "Веб компоненты - в порядке".
Ну куда уж проще: атрибуты - это атрибуты (текст). Свойства класса - это поля объекта (в JS). Не нужно путать атрибуты со свойствами. Не нужно утверждать, что атрибуты - это единственный способ передать параметр. Все нормальные библиотеки, основанные на веб-компонентах, передают данные в js-рантайме, никто не использует парсинг JSON из атрибутов, если это не требуется специально для чего-то.
Вот это аргумент, поддерживаю! О бедных вайбкодерах забыли подумать. Не хочу тебя пугать, но нейросети становятся умнее, и сами скоро будут выбирать более легковесные технологии. А вот ты - умнее явно не становишься.
Впрочем, не вижу больше смысла в препираниях на таком уровне, дальше - игнор.
Ну да, ну да, конечно, никто не пользуется. У Lit - двукратный рост по загрузкам в npm за год, у Symbiote.js - трехкратный. GitHub, YouTube, Microsoft, IBM и даже SpaceX - это совсем-совсем никто.
Строить искусственные языковые заборы в областях, где особенно важно свободное международное сотрудничество и обмен знаниями - это выстрел в ногу. Именно поэтому, как международный медицинский язык принята Латынь, а как айтишный - английский. Документация и комментарии в коде популярных проектов - это все на английском.
Но почему-бы не окуклиться в своем уютном языковом загончике? Хорошая идея ведь! И в науке так-же. Все ради того, чтобы пастухам было удобнее управлять стадом, да? Ведь для этого исследование проводили?
Вы, похоже, кроме названия, так ничего не прочитали.
Веб компоненты вообще НИКАК не противоречат и не мешают ни использованию ИИ (модели очень хорошо ориентируются в стандартах), ни какой-либо модифицируемости. Тут вы просто признаетесь, что не понимаете о чем говорите.
Изоляция Shadow DOM идет сверху вниз потому, что каскадная модель CSS утроена именно так, и не наоборот. Конфигурировать снаружи - ВОЗМОЖНО. Учите стандарты, прежде чем делать такие заявления. Кроме того, использовать Shadow DOM в компонентах - НЕ ОБЯЗАТЕЛЬНО. Хватит тиражировать эту глупость, в статье про это подробно написано. iframe - это полноценный window в вашем документе, использовать его ради изоляции - убийство производительности. У iframe и еще проблемы есть, но вы их как-нибудь сами изучите. Про встраивание уязвимости - тоже полный бред. Вы встраиваете фиксированный код, который проверяется по хэш сумме и прекрасно работает с SRI политиками. 3rd party библиотеку в компонент завернуть проще простого. Если ВЫ конкретно не знаете как- это ВАШ skill issue.
API веб-компонентов вообще НИКАК не мешает SEO. Достаточно не прятать SEO-контент внутри Shadow DOM. Если вы делаете это, вы САМИ стреляете себе в ногу, это просто глупо.
Про энтерпрайз и B2B вы тоже поосторожнее делайте заявления, вы разговариваете с человеком, который за много лет в этом вашем энтерпрайзе повидал всякое. Еще больше - спроектировал и воплотил в жизнь. А вот из чего вы делаете свои выводы - совершенно не понятно.
Про DX - тоже бред. За DX - идите к библиотекам, у них с этим все в порядке. Есть куча современных либ, основанных на веб-компонентах. Одну из них я сам написал. И ожидать от низкоуровнего API - DX уровня библиотеки - глупо. Вы бы еще весь DOM API обвинили в плохом DX, лол.
Итого: с демагогией сюда пришли именно вы.
Ок, хорошо. У вас Shadow DOM не работает, у меня - работает. У вас - компоненты проблем не решают, у меня - решают. Как минимум, половине из нас двоих, веб-компоненты - нужны.
Вот только не надо рассказывать нам про "реальные" приложения таким тоном, как будто вы в этом лучше разбираетесь. У вас нет никаких оснований для этого. Вы можете поделиться собственным опытом, но не говорите за всех.
Хорошая статья, кстати. Рекомендую присутствующим прочитать. Лайк.
Веб-компоненты - это неотъемлемая часть современного DOM API, называть это лишней абстракцией, при том, что все остальное (фреймворки) - это и есть абстракции над DOM - крайне странно. Вы путаете курицу с яйцом.
Про то, какие проблемы они решают - буквально написано и в статье и в комментах. Если никогда не выходить за рамки одной мета-платформы, вы может никогда и не встретите таких задач. Веб-компоненты нужны, прежде всего, для тех, кто с такими задачами сталкивается.
https://github.com/rnd-pro/jsda-kit?tab=readme-ov-file#jsda-kit-vs-nextjs - вот тут становится все более очевидно.
Я вам больше скажу, даже React - лидеру всех на свете рейтингов по использованию, ОЧЕНЬ далеко до звания "хорошего", в техническом плане. Поэтому "пусть расцветают сто цветов". А те, кому надо, выберут то, что им надо.
Я до конца не уверен, клон ли вы Дмитрия, или настоящий живой человек, но что касается общения - ему явно стоило бы у вас поучится. По технической части я вернусь с фидбеком позже.
Чел, прости, но я искренне считаю, что ты психически не очень здоровый человек. Может это и не так, но выглядит - так. Я бы хотел тебе как-то помочь, но, честно, не знаю чем.
Вы почему-то скрыли от публики часть результатов вашего-же изначального сравнения. Именно ту, где были реальные значимые цифры, и они были СИЛЬНО не в пользу $mol. Кроме того, вы не боитесь открыть ящик Пандоры и добиться того, что кто-то все-таки не выдержит, и потратит время на РЕАЛЬНОЕ сравнение? Боюсь, оно будет разгромным.
С удовольствием расскажу. В отдельной статье.
Боюсь, чтобы полноценно ответить на ваш комментарий нужно целую отдельную статью написать. Поэтому простите, но пройдусь кратко:
Начинающему разработчику я посоветую почитать доки, и написать пару компонентов самому, чтобы получить базовое представление. Можно попросить ИИ помочь, он все подробно объяснит и посоветует куда дальше двигаться.
Про сильные стороны - я написал в статье. Эти три пункта - и есть то, ради чего стоит в эту тему вникать. Образно говоря, веб-компоненты - это клей, который склеивает HTML, JS, CSS в тех точках вашего приложения, где вам это нужно. Причем, как на клиенте, так и на сервере, как в пространстве (положение в DOM), так и во времени (контроль жизненного цикла). Без них, такая задача как, например, SSR - становится на порядок сложнее.
Простой пример задачи со звездочкой - это виджеты. Представьте, что вы создаете сервис, позволяющий вставить чат, прием оплаты или загрузку пользовательских файлов на любой сайт. Сайты ваших клиентов могут быть реализованы на чем угодно - любом фреймворке, CMS, серверном шаблонизаторе... С любым пайплайном сборки, с любыми "подводными камнями", которые только можно и нельзя придумать. Так вот, веб-компоненты - это, практически, единственный способ создать такое решение с минимальным количеством боли и без необходимости писать отдельные обертки и адаптеры под весь этот всевозможный зоопарк. И даже если вы будете писать эти адаптеры - это будет сделать на порядок проще, если внутри будет общее универсальное решение, поддерживаемое по умолчанию, на уровне стандартов самой платформы.
Забавно, что вы привели ссылку на статью, как раз защищающую веб компоненты, где автор полемизирует с автором приведенной цитаты. Она даже называется "Веб компоненты - в порядке".
Хорошие таблички, мне нравятся. Есть спорные моменты в начале (список проблем), но в целом - цифры очень показательные.
Ну куда уж проще: атрибуты - это атрибуты (текст). Свойства класса - это поля объекта (в JS). Не нужно путать атрибуты со свойствами. Не нужно утверждать, что атрибуты - это единственный способ передать параметр. Все нормальные библиотеки, основанные на веб-компонентах, передают данные в js-рантайме, никто не использует парсинг JSON из атрибутов, если это не требуется специально для чего-то.
Вот это аргумент, поддерживаю! О бедных вайбкодерах забыли подумать. Не хочу тебя пугать, но нейросети становятся умнее, и сами скоро будут выбирать более легковесные технологии. А вот ты - умнее явно не становишься.
Впрочем, не вижу больше смысла в препираниях на таком уровне, дальше - игнор.
Ну ладно.
Уже второй раз вы приходите в комменты к моим статьям чисто нахамить, на ровном месте, без внятных аргументов. По существу есть что сказать?
Ну да, ну да, конечно, никто не пользуется. У Lit - двукратный рост по загрузкам в npm за год, у Symbiote.js - трехкратный. GitHub, YouTube, Microsoft, IBM и даже SpaceX - это совсем-совсем никто.
Вы с этим сами прекрасно справились.
Оверхед - излишек, джуниор - юнец, коммит - зарука.
Строить искусственные языковые заборы в областях, где особенно важно свободное международное сотрудничество и обмен знаниями - это выстрел в ногу. Именно поэтому, как международный медицинский язык принята Латынь, а как айтишный - английский. Документация и комментарии в коде популярных проектов - это все на английском.
Но почему-бы не окуклиться в своем уютном языковом загончике? Хорошая идея ведь! И в науке так-же. Все ради того, чтобы пастухам было удобнее управлять стадом, да? Ведь для этого исследование проводили?