Pull to refresh
16K+
93
Alex M@i360uread⁠-⁠only

CTO / Tech Lead / Full Stack / R&D

27
Rating
101
Subscribers
Send message

После 20-ти лет в айти меня уже ничего не бесит. Ну кроме тех, кого все бесит.

Так об этом же и написано...

Очень сложно спорить с чьими-то выдумками. Тебе пишут, что никто компонентами не пользуется - ты приводишь статистику, но твоя статистика, почему-то, не статистика. Тебе рассказывают про какие-то мифические проблемы, ты на пальцах объясняешь, почему таких проблем - нет, но вместо аргументированного ответа тебе начинают рассказывать про демагогию.

Все что я тут пишу я не с потолка взял, а из личной практики. Я лично решал сотни конкретных проблем и с компонентами и без них. Я работал со всеми популярными фреймворками именно потому, что занимался и занимаюсь интеграциями решений для бизнеса и мне приходится иметь дело со всякими экосистемами, с разными подходами к безопасности, от полного пофигизма до самых строгих политик.

Но вам, видимо, виднее. Вы увидели какие-то "очевидные" баги. Ок, хорошо. Вам лично я ничего не продаю и продавать не собираюсь. Просто проходите мимо.

Вы, похоже, кроме названия, так ничего не прочитали.

  1. Веб компоненты вообще НИКАК не противоречат и не мешают ни использованию ИИ (модели очень хорошо ориентируются в стандартах), ни какой-либо модифицируемости. Тут вы просто признаетесь, что не понимаете о чем говорите.

  2. Изоляция Shadow DOM идет сверху вниз потому, что каскадная модель CSS утроена именно так, и не наоборот. Конфигурировать снаружи - ВОЗМОЖНО. Учите стандарты, прежде чем делать такие заявления. Кроме того, использовать Shadow DOM в компонентах - НЕ ОБЯЗАТЕЛЬНО. Хватит тиражировать эту глупость, в статье про это подробно написано. iframe - это полноценный window в вашем документе, использовать его ради изоляции - убийство производительности. У iframe и еще проблемы есть, но вы их как-нибудь сами изучите. Про встраивание уязвимости - тоже полный бред. Вы встраиваете фиксированный код, который проверяется по хэш сумме и прекрасно работает с SRI политиками. 3rd party библиотеку в компонент завернуть проще простого. Если ВЫ конкретно не знаете как- это ВАШ skill issue.

  3. API веб-компонентов вообще НИКАК не мешает SEO. Достаточно не прятать SEO-контент внутри Shadow DOM. Если вы делаете это, вы САМИ стреляете себе в ногу, это просто глупо.

  4. Про энтерпрайз и 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 - это совсем-совсем никто.

Вы с этим сами прекрасно справились.

1
23 ...

Information

Rating
Does not participate
Registered
Activity

Specialization

Фулстек разработчик, Технический директор
Ведущий
JavaScript
Веб-разработка
Управление проектами
Fullstack
Проведение исследований
DevRel
Нейронные сети
Blockchain
Проектирование архитектуры приложений
Progressive Web Apps