Web Components в 2026 — стоит ли без фреймворка

Web Components — стандарт W3C: Custom Elements, Shadow DOM, HTML Templates. Появились в 2014, шумно обсуждались, тихо умерли в тени React и Vue. В 2026 ситуация другая: SSR через Declarative Shadow DOM работает, поддержка во всех браузерах, scoped CSS без styled-components, реальная переносимость. Разбираем, где сейчас Web Components — рабочий выбор, а где остаются нишей.

Что в стандарте сейчас работает

• Custom Elements. customElements.define('my-card', class extends HTMLElement {...}). Свой тег, свой жизненный цикл, без React.
• Shadow DOM. Изолированный DOM-подэкземпляр для компонента. CSS внутри не вытекает наружу, стили снаружи не протекают внутрь. display: contents вокруг работает.
• Declarative Shadow DOM. SSR теперь нормальный: <template shadowrootmode="open"> отдаётся с сервера, гидратится без перерендера. Поддержка во всех браузерах с 2024.
• Slots. <slot> и именованные слоты — композиция как в Vue, нативно.
• Form-Associated Custom Elements. Кастомный input участвует в нативной валидации формы.
• CSS Custom Properties + ::part() + ::slotted(). Темизация компонента снаружи без хаков.

Где Web Components выигрывают

• Дизайн-системы для разных стеков. Один my-button работает в React-приложении одной команды, в Vue другой, в чистом HTML третьей. Без зоопарка React-обёрток + Vue-обёрток.
• Виджеты для встройки. Чат, форма, виджет онлайн-записи на чужой сайт. Web Component не конфликтует с CSS клиента, не требует React-рантайма (только если сам не нужен).
• Постепенный апгрейд легаси-сайта. Старый PHP-сайт без сборки. Добавить интерактивный компонент: написать <script>, поставить тег, всё работает. Без webpack, без React, без Next.
• Сильно настраиваемые элементы UI. Видеоплеер, sparkline-график, code-highlighter — переиспользуются везде.
• Микрофронтенды. Каждая команда — свой WC. Хост-приложение тонкий клей.

Где Web Components не подходят

• Целое SPA. Без фреймворка получите боль с роутингом, стейтом, отдалёнными обновлениями. Lit + atomic state-helpers — почти, но это уже мини-фреймворк.
• Динамический SSR + гидратация по запросу. RSC из React делает это нативно. Web Components — нет, Declarative Shadow DOM — это статика + ленивая интеракция.
• Команды, привыкшие к React. Они знают хуки, контексты, React Query — переучивать дороже, чем держать React. WC оправданы, когда есть конкретная задача (дизайн-система, виджет).

Что писать — vanilla или Lit

• Vanilla. Чистый JS-класс, extends HTMLElement, ручной reactive (через сеттеры или MutationObserver). Минимум зависимостей, максимум контроля.
• Lit. Лёгкая (5 КБ) обёртка от Google. Reactive properties декларативно, рендеринг через template literals, не нужно вручную дёргать DOM. Стандарт де-факто для дизайн-систем (Material Web, Spectrum от Adobe, Shoelace).
• FAST. Microsoft, в Edge UI и Fluent. Менее популярен.
• Atomico, Solid Element. Если нужен фреймворк-стайл DX без React.

Для типовой дизайн-системы — Lit. Для одного виджета — vanilla. Для сильно реактивного — Solid Element.

Боль и грабли

• Темизация снаружи. Shadow DOM защищает, но иногда нужно дать клиенту изменить цвет. Делается через CSS custom properties и ::part(), и об этом нужно подумать с самого начала. Поздно — придётся переписать.
• Доступность. aria-атрибуты внутри Shadow DOM не пробрасываются между компонентами автоматически. Нужно вручную форвардить. ARIA Reflection API (2025) частично решает.
• Forms. Form-Associated Custom Elements работают, но требуют дополнительной разметки. Простая кнопка type="submit" сама собой не получится.
• SSR с гидратацией. Declarative Shadow DOM работает, но не все фреймворки на сервере умеют его отдавать. Astro и SvelteKit — да, vanilla Node + Express — нет, нужны ручные шаблоны.
• React не дружит из коробки. До React 19 нужно было оборачивать в обёртку для props и events. С React 19 — нативная поддержка, наконец.

Что выбирают сейчас крупные

• Дизайн-системы. Adobe Spectrum, GitHub Primer (часть), Material Web — все на WC. Apple News Format, IBM Carbon — пробуют.
• Виджеты. Stripe Elements мигрируют. Reddit embed, GitHub gist — нативные тенденции.
• В РФ. Яндекс Lego, VK UI пока на React, но WC-варианты появляются для embed в чужих экосистемах.

Чеклист «брать или нет»

1. Будет ли это переиспользоваться вне одного стека? Да → WC. Нет → лучше нативный для фреймворка вариант.
2. Это виджет для встройки в чужой сайт? Да → WC.
3. Это дизайн-система для нескольких команд с разными стеками? Да → WC.
4. Это целое приложение? Нет → фреймворк.
5. Целевые браузеры включают что-то старше Edge Legacy / IE? Нет → WC. Да → React + polyfills.

Итог: Web Components в 2026 — это не «замена React», а инструмент для конкретного класса задач. Дизайн-системы, виджеты, легаси-апгрейд, микрофронтенды. На все эти сценарии WC + Lit дают переносимый, лёгкий, нативный результат. Для типового SPA фреймворки остаются правильным выбором — пока что.