Неплохая статья про то, почему web компоненты переживут все современные фреймворки. Если коротко, то автор ведёт свой блог довольно давно (около 15 лет) и за это время он понял, что привязываться к конкретным инструментам в вопросе ведения блога - это путь в никуда, т.е. если технология сейчас кажется перспективной, то через 5 лет она, скорее всего, окажется аутсайдером, а через 10 про неё уже и не вспомнят

Поэтому автор хранит свои заметки в чистом markdown. И при переезде на новые технологии (сейчас он использует Astro) особых проблем не возникает т.к. markdown абстрагирован от инструментов. Но у markdown есть одна крутая фишка - в нем можно писать html и большинство инструментов его отрисуют. Это дает возможность вставлять в markdown всякое, для чего он не предназначен (графики, интерактивные примеры). А если что-то и вставлять - то web-компоненты, потому что они будут работать и сейчас и через 10 лет.

В общем, если вы делаете что-то, что должно работать без правок и через 10 лет - то нативные веб-компоненты - лучший выбор. Они точно будут работать везде и еще долго будут с нами

Пререлиз Lit 3.0. Короткое напоминание: Lit - это инструмент для облегчения работы с веб-компонентами.

Релиз выглядит достаточно интересным: отказ от поддержки IE11, переход на новые декораторы из стандарта языка, обновления компилятора (неожиданно для меня, шаблоны Lit компилируются через Typescript) и, самое для меня неожиданное, интеграция с Preact Signals.

В продолжении недавних статей про взлет и падение веб-компонентов, вышла статья про проблемы Shadow DOM

В целом, статья рассказывает, что применение Shadow DOM для инкапсуляции привносит в проект лишь проблемы. В будущем ситуация будет лучше, но пока так. Поэтому Enhance (я так понял это фреймворк) не использует Shadow DOM при описании компонентов

Проблемы Shadow DOM:

1. Shadow DOM требует загрузки и исполнения JS, что по перформансу намного хуже чем простой HTML
2. Пока не завезли декларативный Shadow DOM, нет возможности делать серверный рендер
3. Пока не будет вызван customElements.define(), к компоненту не будут применены стили (FOUCE - Flash of Unstyled Custom Element)
4. Кнопки в Shadow DOM в формах работают иначе, чем кнопки вне Shadow DOM в формах.
5. Shadow DOM усложняет реализацию доступности

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

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

Первый хороший кейс, это компоненты, которые имеют смысл только в браузере (виджет выбора дат в календаре или выбор эможи)

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

Третий хороший кейс - это крупные компании и дизайн системы. Автор говорит, что по некоторым замерам, веб-компоненты в интернете встречаются намного чаще, чем React. Это готовые дизайн-системы на веб-компоненты и крупные компании типа Oracle, IBM, Adobe и другие . Они используют web-component'ы потому что они работают почти везде и их легко подключать: никаких бандлеров и транспайлеров, просто вставь html тэг и скрипт и все заработает

Вывод: у веб-компонентов определенно есть проблемы, но то что это вообще стандартизуется - это хорошо. Нет четкого ответа, кому и когда стоит использовать веб-компоненты в 2023 году. Но есть кейсы, где они хороши