было бы круто, например, всем интернетом пилить один автокомплит / комбобокс

виртуальный список

вот это все

и вставлять тегами

всем профит

ну или там вот компонент-полифилл для <dialog>

Ты описываешь одно направление использования. Недоумение вызывает обратное направление.

omg, ну это же совсем разные вещи
написание компонентах, независимого от фреймворка, это одна задача

разработка компонентов уровня приложения, которые не нужно реюзать за его скоупом, друго дело

конечно можно все это связать в одну кашу и в качестве аргумента привести тот, что удобно иногда выносить компоненты из приложения и делать реюзабельными
это наверно и есть ответ на мой изначально поставленный вопрос

но полезность такого подхода все еще кажется мне сомнительной, так так на практике никто не будет делать его насктолько реюзабельным и настолько близким к нативному стандарту, чтобы он работал с другими фреймворками и на то много причин
самая раздражающая была рассмотрена Робом как раз на саммите
https://custom-elements-everywhere.com/
https://www.youtube.com/watch?v=sK1ODp0nDbM

Ну, у реюзабельности есть свои границы. Внутрь её попадают всякие "контролы" (тогглеры, маскед-инпуты, авто-комплитеры) и "дамп-компоненты", те, где все данные можно передать снаружи (карусели, аккардеоны, менюшки и пр.). Так же сюда могут попадать реюзабельность внутри отдельной взятой компании, для сохранения общего стиля (тот же яндекс, по-моему, имеет собственную библиотеку контролов). Пытаться сделать реюзабельным какой-то специфичный "смарт-компонент" - отчаянная и глупая попытка. А по поводу, зачем фреймворкам юзать не собственные компоненты, и как они их будут использовать веб-компоненты: ну используют же до сих пор и bootstrap, material disign, и, прости господи, jquery-ui компоненты и в ангуляр/реакт/вью/ембер приложениях и справляются, так же и с вэб-компонентами будет...

Надеюсь я правильно понял смысл дискуссии, а то будет глупо 😕

значит рассказываю историю
вчера с коллегами устроили нехилый батл про стилизацию сожержимого slot в компонентах
пытались убедить друг друга, как можно и как нельзя делать, а также как должно и не должно работать
как это часто бывает с программисткими спорами, их можно было и не вести, если бы сразу посмотрели как ведет себя код
поэтому детали спора я упущу, а приведу репку, которую я создал, чтобы можно было посмотреть суть обсуждаемого решения
https://github.com/bashmish/shadowdom-slot-styling-specifics

интересно узнать ваше мнение (даже если вы нифига не шарите в веб-компонентах) по поводу такого вот противостояния инкапсуляции стилей и необходимости иногда ее обойти
и как думаете, зачем нам понадобилось решение №3? 🙂

Вот так нагородят технологий, а потом борются с ними.

Сначала Shadow DOM, теперь это вот.

А, это одно и то же?

не понял суть втоего вопроса
там ShadowDOM, да
и там изнутри компонента происходит запись в хост, к которому имеет доступ через JS

> как думаете, зачем нам понадобилось решение №3? 🙂

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