Comments 47
Вопрос не совсем по теме статьи - существуют ли хорошие примеры UI-kitов на чистых веб компонентов без дополнительных абстракций типа lit или их аналогов?
Грубо говоря, чтобы все было в одном стиле, и при этом можно было подключить, скажем мультиселект или датагрид одним-двумя импортами прямо в HTML?
https://www.fast.design/ - есть такое. Оно?
А Lit - это достаточно тонкий утилити-слой для более удобной работы с веб-компонентами и лучшего DX. Я с удовольствием использую библиотеку shoelace.style, хоть она и использует Lit под капотом
Ну а я добавлю по теме статьи: автор почему-то постеснялся дать ссылку на упоминаемую им дискуссию.
Всё у веб компонент хорошо, но…
хотелось бы попроще создавать атрибуты и проперти - наверное, однажды решится с появлением декораторов
почему нельзя создать `<some-component />` а надо именно `<some-component></some-component>`
почему нельзя создать
<some-component />;а надо именно<some-component></some-componen>;
Это из-за механизма парсинга в браузере: до активации компонента браузер не знает, могут ли у такого элемента быть обычные потомки в дереве, и как дальше строить структуру документа. Поэтому, по умолчанию, требуется закрытие тега. До активации, веб-компонент это некий аналог тега <span></span>, а он тоже подразумевает закрывающий тег. Другими словами, для скорости, это как с парсингом JSON и запятой в конце.
Надо вспомнить, что когда только эти самые веб-компоненты появились, ими можно было пользоваться разве что для каких то демок поиграться. Были разные реализации в разных браузерах. Это все вставляло палки в колеса разработки. А потом появился React. И только потом настала смерть IE, а вместе с этим наступила эра когда веб-компоненты начали поддерживаться всеми браузерами. Но сейчас уже 2023 год, и вот я задаюсь вопросом, а что могут сделать веб-компоненты, что не может React? Shadow DOM у них есть, а если он мне не нужен?
Мне кажется, что React как раз и послужил этаким "убийцей" веб-компонентов. Из мира React мне не разу не пригодилась эта технология. А любой велосипед можно сделать и на React, получится React-компонент.
А вот не в мире React, когда я тут что-то сделал, но я не хочу чтобы другие стили на сайте у меня тут все не поломали, дай-ка я засуну все это в веб-компонент - Shadow DOMом едины. Такой подход имеет место быть. Но здесь же очевидны и другие проблемы, более высокого уровня, архитектурные.
Для меня важной фичей была бы возможность подключения компонентов любой сложности поштучно в пару <script> тегов, при этом не таща рантайм какого либо фреймворка. Но сколько не встречал готовых решений, везде вижу обвязки-абстракции (которые надо тащить точно также, как реактовый рантайм). Разве что более тонкие, но с явно менее удобные для разработчика по сравнению с React и др. фреймворками.
а что могут сделать веб-компоненты, что не может React
Статья же буквально об этом. Очень много чего React не может. Вы поймите, если среди ваших задач только работа с избранным вами на старте рантаймом - вам веб-компоненты вполне могут быть и не нужны вовсе. Если перед вами встанет задача композиции нескольких рантаймов (виджеты, микрофронты) - тут уже совсем другая ситуация. Ваша проблема описана в первом же пункте, вы сравниваете и противопоставляете конкретную либу и браузерный API и я пишу о том, что так делать не совсем корректно. А еще, React тяжелый и тормозной, и бывают случаи, когда это само по себе становится проблемой.
Веб-компоненты - отличное решение для дизайн-систем и ui-китов. Преимущества в том, что это нативные технологии и они работают в любом фреймворке (для реакта нужен враппер). В итоге один и тот же компонент дизайн-системы можно использовать на статичном HTML-лендинге, во Vue, Angular, React, Svelte и тд (что может быть актуально для микрофронтов).
У веб-компонентов лучше перформанс, поскольку они близки к браузеру и их API про растают из C++ маппингов и нативного DOM API. И как сказано в статье, не нужно сравнивать их с фреймворками, они не противники, а союзники.
Я один из «скептиков», попробую объяснить свою нелюбовь. Сразу оговорюсь, считаю, что веб-компоненты имеют свою область применения, но она ограничена.
Мне кажется, проблема с веб-компонентами в том, что они идут в разрез с общим трендом развития фронтенда, воюют не в ту сторону так сказать. Успей они к 2012му или хоть к 2015му, все бы их любили, ценили и использовали какое-то время, но насколько я помню они начали дозревать и быть пригодными к использованию в проде только к 2018му где-то, когда поезд уже давно уехал в совершенно другую сторону.
Ваш тезис:
HTML - это альфа и омега всего веба
я считаю ошибочным. HTML - это альфа и омега всего веба в той форме в какой он был задуман, то есть как всемирная база знаний в духе гигантской Википедии. Современный веб совершенно другой. Это платформа для запуска приложений, а не хранилище гипертекста. В современном вебе альфа и омега - это пользовательский интерфейс, а HTML - это не более чем промежуточная его репрезентация, клей между приложением и браузерным рендерером. Причем клей крайне корявый и неудобный, который мы вынуждены использовать по инерции. Приложение ведь можно например отрендерить на Canvas, и HTML тогда будет играть роль не более чем вынужденной входной точки. А бывают еще фреймворки типа Flutter или React, на которых одно приложение может таргетить несколько платформ сразу, и в таком приложении HTML будет просто implementation detail рендеринга под одну из платформ.
И вот в такую кодовую базу, написанную на одном фреймворке в едином декларативном стиле, пихать веб-компоненты - это по-моему просто грех. Если бы в мое React-приложение кто-то попытался засунуть веб-компонент, я бы просто дал ему по рукам, потому что это не что иное как протечка абстракции. В таком приложении не React-компонент будет как вы говорите «лишней абстракцией», потому что вся кодовая база уже состоит из React-компонентов, а лишней абстракцией как раз таки будет веб-компонент.
И тут я считаю надо оговориться о модных хипстерских смузихлёбных фреймворках. Удивительно, но до сих пор можно иногда наткнуться на людей которые при слове «фреймворк» закатывают глаза и восклицают «о боже мой, очередной фреймворк, зачем они вообще нужны». Хочется спросить этих людей, а где вы были все эти восемь лет? Мне кажется, идея о том, что сколь либо сложное приложение проще, дешевле и удобнее всего писать на декларативном фреймворке с vDOM или его аналогом - это уже устоявшийся и проверенный временем консенсус. Уже сто раз наступали на эти грабли. Ну нет в природе более хорошего способа описывать пользовательский интерфейс, чем f(x) где x - состояние.
Ну и о том где я считаю веб-компоненты можно использовать хорошо.
Сайт (не приложение) с минимумом интерактивных элементов, где можно обойтись без декларативного фреймворка и при этом не сойти с ума;
Когда вы вынуждены дружить свой новый код со старьем вроде Wordpress;
Когда у вас беспорядочный зоопарк разных технологий в одном приложении (сейчас это называется модным словом «микрофронтенды»)
Да, веб-компоненты "опоздали на поезд", но это не делает их ненужными. Технологии постоянно меняются, и то, что было актуально в 2015 году, может быть не таковым в 2023. Автор статьи предлагает рассмотреть альтернативу: сесть на новый высокотехнологичный, скоростной поезд, созданный с использованием новых корейских сверхпроводников. Ведь существуют молодые разработчики, которым навязывают один единственный путь, не упоминая о существовании альтернатив, в пользу своих старых привычек.
Меня тоже бесит, что большинство курсов для новичков сфокусированы исключительно на React или других популярных фреймворках. Это как учить человека ездить на танке, когда ему нужен велосипед. Новичкам важно понимать базовые принципы, а не сразу погружаться в сложные экосистемы. Веб-компоненты могут быть отличным стартом для понимания, как устроен веб, без лишнего "шума" от фреймворков.
Сразу оговорюсь, считаю, что веб-компоненты имеют свою область применения, но она ограничена.
Именно об этом я и пишу. Как и абсолютно у любого API, у этого своя область применения и свои ограничения. Почему это вдруг делает его плохим - мне не понятно. Особенно в сравнении с попытками родить костыли, какие породили разработчики таких решений, как Next.js для создания плейсхолдеров и гидрации.
я считаю ошибочным
Любая веб-страница, буквально, начинается с HTML-файла. Любая статическая страница с сервера, это буквально, HTML. Мое утверждение про альфу и омегу - это не какая-то моя личная философия, это то, как оно работает, как на заре веба, так и сейчас.
И вот в такую кодовую базу, написанную на одном фреймворке в едином декларативном стиле, пихать веб-компоненты - это по-моему просто грех
Использовать нативный браузерный DOM API - это грех? Ну ладно.
vDOM или его аналогом - это уже устоявшийся и проверенный временем консенсус
Очень спорно, особенно, если вам важна производительность. Это не только мое мнение, авторы кучи либ говорят о отсутствии vDOM как о достоинстве а не о недостатке.
Ну нет в природе более хорошего способа описывать пользовательский интерфейс, чем f(x) где x - состояние
На мой взгляд это просто огромное заблуждение всех, кто тащит функциональщину во фронт. Красота математической чистой функции тут ломается о необходимость синхронизации с DOM, то есть с реальным миром... в котором, к тому же, есть такие штуки как накладные расходы на аллокацию и очистку памяти для иммутабельных объектов. Повторюсь - если вам не важна производительность - ок.
Ты 100% прав, я же добавлю, что математически чистая функция - это не так уж и приятно. Даже если взять реакт, скажем у компонента 10 детей, а если обновилось только 1 его свойство, которое затрагивает только 1 ребенка, нужно идти в каждого из ребенков и исполнять его как чистую функцию, чтобы смотреть, не нужно ли что перерисовать. Поэтому и говорят, что "реакт на самом деле не реактивен". Чистые функции для отрисовки UI, которые все так боготворят, это на самом чистый фаб, просто хак оттого, что никто не знает, как правильно сделать. не легче ли каждому компоненту иметь свои свойства, и если эти свойства меняются, давать ему перерисовывать только свое дерево, причем реально только в тех местах, где надо?
не легче ли каждому компоненту иметь свои свойства, и если эти свойства меняются, давать ему перерисовывать только свое дерево
Скажу по секрету, именно так оно и работает :) Дерево перерисовывается только вниз от компонента, у которого поменялся стейт. Поэтому если обновилось только одно свойство, которое затрагивает только одного ребенка, исполнять нужно будет только этого ребенка. Но с точки зрения разработчика это все равно выглядит как f(x).
причем реально только в тех местах, где надо
Для этого и есть vDOM, чтобы автоматически искать те места, где надо.
Нет, я неправильно сказал, не своего "дерева", а только своего уровня в дереве, то есть не лезть в перерисовку детей вообще. То есть не "исполнять нужно будет только этого ребенка" как ты говоришь, а "исполнять нужно будет только этого ребенка и все его дерево". С другой стороны, можно сделать так, что если у ребенка что-то изменилось, он сам перерисует тот кусок, который изменился. vDOM - очень неэффективный способ решения этой проблемы. Места искать не нужно, они должны быть уже известны за счет того, что в идеале мы можем знать, какое свойство влияет на какую отрисовку.
Есть данные, нам надо из них делать элементы, и обновлять элементы когда данные меняются. Есть ровно два способа как это сделать:
Определить, каким образом данные превращаются в элементы, и позволить фреймворку определить, как изменения данных превратить в изменения элементов. Тогда нужен vDOM.
Самим определить, каким образом изменения данных превращаются в изменения элементов. Тут есть два варианта, оба со своими издержками - либо императивная лапша, которую сложно писать отлаживать. Либо какие-то декларативные шаблоны, как в Svelte. Шаблоны будут ограничены в том, какие конкретно способы изменения данных они поддерживают, потому что иначе мы возвращаемся к варианту 1 и нам опять нужен vDOM.
В первом варианте нам никак не избежать перерисовки родительского дерева при изменении данных родителя. Дерево ребенка можно и не перерисовывать, если его данные не поменялись, эта особенность не является свойством vDOM как такового. В React ее можно при необходимости обойти мемоизацией. А в Flutter / Dart есть еще такая штука как const expression, позволяющая не перерисовывать те части дерева, которые не меняются вообще никогда. Так или иначе, в подавляющем большинстве случаев, отрисовка виртуального дерева - пренебрежимо дешевая операция.
есть в общем 4 варианта, когда что-то меняется:
показываем/прячем элемент (возможно, с каким-то эффектом)
добавляем / убираем класс элемента (.Hidden, .Shown)
модифицируем аттрибуты элемента (включая стиль)
Обновляем список, из которого берутся данные для отображения
возьмем простой метод компонент:
function Render({propA, propB, list}) {
// some hook calculations
var [b]=useSomething([])
return (<div data-a={propA} disabled={propB}>
{list.map(a=><ListItem item={a} b={b} />)}
</div>)
}Это твой любимый "неимперативный" метод. Только дело в том, что он такой же неимперативный, как и недекларативный. Настоящий декларатив -- это CSS, ты прописал пару правил, они распарсились и показались тебе, при этом ты вообще не знаешь, как. Компоненты вроде реакта -- это не декларативный код. Декларативный код подразумевает, что ты задал какие-то правила, и они магическим образом показываются. В примере выше нет ничего магического: если изменилось свойство и нужно лишь поменять аттрибут "data-a", помимо VDom о котором ты говоришь, будет перевыполнен ВЕСЬ код как самого компонента, включая хуки (вся стена хуков), так и детей, который находятся в списке. Это друг ни разу не декларатив, это просто сотейник со спагетти. Я на 100% за то, что не нужно писать императивный код, потому что веб страницы - это тип систем, которые остаются запущенными, в отличие от вон ноймановских программ, которые получили input и отдали output. Тут нужны стратегии по data-flow, но реакт - это не лучшая стратегия. VDom вообще не нужен. Представь, что метод Render можно проанализировать заранее, и выяснить, что data-a зависит от свойства propA, и поэтому когда propA меняется, мы исполним только ту часть, которая бы была ответственна за это. То есть функция компонента разбивается на 3 рендера:
function RenderA({propA}) {
return (<div data-a={propA} />)
}
function RenderDisabled({propB}) {
return (<div disabled={propA} />)
}
function RenderList({list}) {
var [b]=useSomething([])
return (<div>
{list.map(a=><ListItem item={a} b={b} />)}
</div>)
}Каждая из функций делает только свою часть по отрисовке, и реагирует только на определенное свойство, от которого зависит. Это, конечно, возможно только если у нас уже есть стандартный Домовский элемент, которым можно манипулировать. И сделать это очень даже можно, если только перестать думать в "функиональном" стиле, который является тупиком и ничего по-настоящему интересного, как выше, не дает, а уж тем более не является декларативным.
Почему это вдруг делает его плохим - мне не понятно
Не говорю что делает плохим, но я уловил в статье такой посыл что это такое классное универсальное решение, которое можно пихать куда угодно, хоть с фреймворком, хоть без фреймворка, хоть куда. Я и говорю, что с фреймворком - не надо.
Плюс я пытаюсь отрефлексировать на тему почему веб компоненты "недооценены", почему недополучили хайпа / внимания. На мой взгляд это потому что они не являются технологией, идущей в фарватере тренда, а являются технологией, делающей работу со всяким там легаси чуть менее невыносимой. Такие технологии полезны и нужны, но совершенно естественно, что они привлекают меньше внимания и интереса.
Мое утверждение про альфу и омегу - это не какая-то моя личная философия, это то, как оно работает, как на заре веба, так и сейчас
Не спорю, только вот я к этому факту отношусь как к досадному техническому ограничению, возникшему по историческим причинам. Поэтому и работать с ним надо соответствующим образом - стыдливо прятать под слоем абстракций, как это делают декларативные фреймворки, а не плясать от него, как это делают веб компоненты. Кстати, думаю, в ближайшие лет 10 мы с вами увидим постепенное выдавливание обязательного HTML из веба, как сейчас видим постепенное выдавливание обязательного javascript через WebAssembly.
Использовать нативный браузерный DOM API - это грех?
Не не, я этого не говорил. Я сказал что это грех в определенной ситуации, и четко описал, в какой. Если у вас реакт приложение, то навешивать руками обработчики, когда можно обойтись без этого - грех. Использовать нативные компоненты - тоже грех. Потому что это протечка абстракции. Посылать запросы к БД - грех? Конечно нет. Посылать запросы к БД из слоя презентации - грех? Еще какой. Тут то же самое.
авторы кучи либ говорят о отсутствии vDOM как о достоинстве а не о недостатке
Естественно, потому что vDOM не является и не может являться достоинством сам по себе, а является необходимым элементом декларативного фреймворка. Говоря метафорически, авторы таких либ продают инновационные автомобили, которые не потребляют бензина, не шумят и не выбрасывают углекислый газ. Только вот они умалчивают, что водителю их автомобилей придется самому крутить педали.
Красота математической чистой функции тут ломается о необходимость синхронизации ... с реальным миром.
Это описание применимо к любому программированию чего угодно.
такие штуки как накладные расходы на аллокацию и очистку памяти для иммутабельных объектов
Все говорят про эти накладные расходы, но я не видел ни одного приложения где рендеринг vDOMа был бы главным баттлнеком, помимо ситуаций когда это был какой-то легко исправляемый баг, либо синтетический пример по типу "меняем местами 40000 div'ов". Если у вас 40000 div'ов, у вас это и на чистом JS будет лагать, ну сделайте вы виртуализацию, благо в декларативных фреймворках она элементарно делается. Почему-то при этом никто не обращает внимания на реальные накладные расходы, в виде накладных расходов часов разработчиков, ковыряющих императивную лапшу в поисках бага.
Позвольте отметить, что не смотря на то, что вы явно мой идеологический противник по многим вопросам, с вами приятно разговаривать. Это редкость. Подробнее на ваш комментарий я смогу ответить уже только завтра.
На мой взгляд это потому что они не являются технологией, идущей в фарватере тренда, а являются технологией, делающей работу со всяким там легаси чуть менее невыносимой.
С этим не соглашусь. Мне кажется, тренды рожденные в экосистеме Реакта напрямую связаны с большим количеством "свежей крови" в индустрии. Поскольку это наше айти стало самым эффективным социальным лифтом, к нам пришла куча народа, которую пришлось как-то подключить к процессам. И Реакт стал такой адаптационной площадкой, где некоторые, весьма поверхностные, идеи и привычный для многих DX, стали стандартом. Но стандартом только внутри Реакт-загончика, вовсе не для всей веб-экосистемы. После Реакта появилась уже куча решений, которые активно набирают свою популярность, и многое там идет наперекор реактовским трендам.
Но есть еще тренды платформы. Новые стандарты, которые принимаются консорциумом. Новые подходы (типа JAMStack), которые позволяют решать задачи более эффективно. И тут уже веб-компоненты становятся технологией на острие прогресса, а Реакт - тормозным легаси.
Не спорю, только вот я к этому факту отношусь как к досадному техническому ограничению, возникшему по историческим причинам. Поэтому и работать с ним надо соответствующим образом - стыдливо прятать под слоем абстракций, как это делают декларативные фреймворки, а не плясать от него, как это делают веб компоненты.
В мире существуют не только фронтэнд фреймворки. На сервере веб-документы тоже нужно как-то формировать. Потом то, что вы сформировали, нужно как-то передать пользователю. А еще, вам может быть необходима доступность вашего контента для индексации. А еще у вас есть некая вариативность в пользовательских средах.
Когда-то давно, мне тоже казалось, что иметь для решения, по сути, одной задачи, целых три разных языка и подхода, таких как HTML, CSS и JS - это какой-то перебор и ужасное неудобство. Поверьте, очень многие инженеры пытались родить "правильную" и "современную" замену HTML. И я пытался. Мне казалось, что HTML - ужасно избыточен и добавляет оверхед даже тупо на уровне количества символов в документе. Сперва я пошел по пути разработчиков Svelte - пытался сделать создать какой-то компактный способ описания DOM в JS объекте и выяснил такую интересную и контринтуитивную штуку: HTML - оказался компактнее а нативный парсинг значительно быстрее, создания элементов из JS рантайма. Говоря о DX, можно отметить, что ментальные модели, стоящие за HTML - на порядок проще и доступнее для широкой аудитории, чем любые альтернативы на сегодня. Ох рано вы HTML хороните.
навешивать руками обработчики, когда можно обойтись без этого - грех.
Вам не обязательно навешивать что-то руками с веб-компонентами.
Только вот они умалчивают, что водителю их автомобилей придется самому крутить педали.
Вот это просто неправда. Со стороны пользователя либы, ваш воркфлоу вообще ничем принципиально не отличается в случае если у вас нет vDOM. Я сам разработчик такой либы. Со стороны, вы просто не увидите разницы, пока не напишите бенчмарк. А с бенчмарком, разница будет не в пользу vDOM, и разница будет большая. Для страничек с парой кнопочек и формой, может и не важно это. Но если вы начнете делать редактор каких-нибудь таблиц с кучей ячеек - вот тогда всплывет в полный рост.
Это описание применимо к любому программированию чего угодно
Ну значит, у функциональщиков проблемы не только во фронте.
Почему-то при этом никто не обращает внимания на реальные накладные расходы, в виде накладных расходов часов разработчиков, ковыряющих императивную лапшу в поисках бага.
Кто мешает сделать декларативный фреймворк на веб-компонентах? Их и сделано уже дофига, в моей статье есть ссылка. Разница с другими лишь в том, что этим ребятам не приходится тащить дополнительную логику для реализации именно компонентной модели, они ее получают "бесплатно" и в более производительном виде, вот и все.
со старьем вроде Wordpress
то, что вы называете старьем - самый популярный движок в интернете на данный момент. На ворпресс сделано сайтов в разы больше чем на реакте, и они действующие. Кроме вордпресс есть куча других, более новых, движков с такими-же проблемами как описывает автор
Очень часто люди путают HTML и DOM. На тему альфы и омеги у меня даже есть статья: Карго-культ HTML в современном фронтенде.
Во-первых, HTML это удобная текстовая репрезентация объектной модели документа. Во-вторых, я считаю что react-native и подобные ему гибридные подходы скоро уйдут. Так как они по сути являются попыткой пере-изобретения велосипеда истинно кроссплатформенной среды вэб броузера. Поводом их создания было недостаточное количество поддерживаемых фич и скорости работы броузера. С тех времен много воды утекло и теперь 90% нативных приложений может быть реализовано как PWA https://whatpwacando.today/
Пробовал atomico для сайта с простейшим роутингом парой инпутов и парой кнопок на каждой странице. shadowroot был каждые два шага вложенности, после чего было принято решение не вы... и взять реакт.
да кому нужны ваши веб-компоненты, если главная проблема -- не сами компоненты и их стили, а общение между ними, протокол которого напрочь отсутствует как концепт в текущей html 5 модели веб-компонентов. что значит общение? вот есть кнопка, я ее нажал, я хочу, чтобы изменилось состояние другого компонента, например, кол-во кликов. А если кол-во кликов больше 10, то я хочу изменить еще другое свойство еще другого компонента. В первом вопросе поможет событейная модель: onClick -> component.incrementClicks(). Со вторым поможет только фреймворк, и в этом все горе, что в html 5 просто не продумана реактивность, которая свойственна всем persistent системам (то есть тем системам, которые запускаешь и они продолжают работают, а не просто выводят результат). Сколько бы ни пилили сами компоненты, пока не реализуют eventual transconsistency (правильное название реактивности) на уровне протокола, они так и останутся никому не нужны.
Да кому нужны эти ваши болиды Формулы 1, если у них нет экскаваторного ковша?
Вы требуете от API того, для чего он в принципе изначально не предназначен. Веб-компонент - это точка сборки для вашего решения, а не волшебная пилюля для решения всех возможных вопросов.
Что значит не предназначен? Взаимодействие между компонентами - это фундаментальная проблема пользовательского интерфейса. Есть 3 уровня для веб-разработки: презентация (стили, классы), интеракция с пользователем (нажал кнопку -> что-то произошло) и коммуникация (передать сообщение другому компоненту / получить сообщение от другого компонента), напр, вышел из системы - поле комментариев погасло. Как вы можете говорить, что API веб-компонентов не предназначен для обмена данных между ними? А что тогда предназначено? Вернее, то что вы говорите это на данном этапе правда, и в этом и есть проблема: что внешний вид / интеракции можно спокойно писать и на чистом HTML/JS, а вот реактивную коммуникацию между компонентами никто не потрудился устроить, которая является самой актуальной проблемой. Ну и зачем они тогда нужны без протокола коммуникации?
Глобальная коммуникация - это вопрос архитектуры вашего решения. У вас есть миллион возможностей: событийная модель, глобальные хранилища с синхронизацией на колбэках и прочие варианты pub/sub, готовые либы для управления состоянием (тысячи их), синхронные и асинхронные пакетные обновления, работа через транзакции и очереди, привязка к вебсокетам... Повторюсь: вам дают точку сборки, которая позволяет реализовать нужный именно вам сценарий и принцип. Например, Custom Events чем не протокол? Вы хотите чтобы вам дали одну единственную правильную архитектуру для всех возможных типов приложений?
во-первых, не глобальная коммуникация, а локальная, то есть компонент-компонент, а не компонент -> хранилище состояния -> компонент. у моих компонентов уже есть состояния, зачем мне создавать какие-то там хранилища, и через них обмениваться? во-вторых, событейная модель подходит не до конца, потому что она не реактивна, зачем мне подписываться на какие-то там события, если значение переменной в состоянии одного компонента напрямую, по формуле, зависит от значения состояния в другом компоненте? Из вашей логики, мол вот вам стандарт "веб-компонентов", который по сути своей не привносит ровным счетом ничего (что такое "точка сборки"), а чтобы решить реальную, насущую проблему - делайте что хотите. Да я хочу чтобы мне дали единственную правильную архитектуру, иначе зачем вообще тогда делать специальный стандарт компонентов, если потом все равно приходится к нему прикручивать базовую функциональность обмена сообщениями между ними?
Кстати, я как-то делал прототип реактивности для DOM. Не очень удобно, конечно, но даже в таком виде её в браузеры так и не завезли.
Заметил, что вы много спамите ссылками на ваш сайт. Лучше бы это были ваши статьи на хабре, которым можно было дать соответствующую оценку.
Классная статья! Круто разъяснил, что веб-компоненты — это не враги фреймворкам, а как раз помощники. Я сам часто использую веб-компоненты для создания виджетов. Они легко "втыкаются" в разные проекты и не создают проблем. С ними всегда понятно, когда что происходит, и это реально удобно. Плюс, они хорошо ладят с HTML и CSS, так что можно быстро и просто их настроить. В общем, с ними работать — одно удовольствие.
Согласен что вэб компоненты это очень важное и нужное подспорье для нас, как вэб разработчиков. И фреймворки и компоненты имеют пересекающийся функционал. Но то что они прекрасно могут работать вместе это факт. Например фреймворк отвечает за создание и обновление DOM внутри компонента, а компоненты отвечают за общую структуру документа и композицию.
React кстати был не совсем совместим с вэб компонентами, также в нем дублируется логика жизненного цикла, и еще он тяжеловесен.
Некоторое время назад я начал разработку легковесной библиотеки для создания и обновления DOM. Фундаментально она схожа с React, но без этих недостатков. Так что предполагаю что она могла бы быть идеальным помошником для написания вэб компонентов https://github.com/fusorjs/dom
Веб-компоненты в 2023: нужно поговорить