Каждый раз, когда в какой-либо статье, либо в комментариях, упоминается группа стандартов Web Components, происходит практически одно и то же: люди, которые, зачастую, весьма слабо представляют о чем идет речь, начинают делиться «экспертными» мнениями. Каждый раз обсуждения скатываются к одному и тому же накатанному сценарию, название которого рифмуется со словом «грач». А мне очень хотелось бы позитива, конструктива и перехода к вопросам практического применения. В данной статье, я попытаюсь разом ответить на подавляющее большинство типичных вопросов и опровергнуть максимум общих заблуждений. Впоследствии, в тяжелой ситуации, можно будет отбиться одной ссылкой. Итак, поехали.
Основы
Веб-компоненты — это набор современных спецификаций, состоящий из следующих основных элементов:
Custom Elements — нативная возможность создавать свои собственные HTML-теги, с заданным поведением, внешним видом и собственной внутренней разметкой.
Shadow DOM — разделение внутренней структуры компонента с инкапсуляцией внутренних стилей и остального тела документа.
Template — специальный тег, позволяющий хранить куски разметки, применять их и многократно использовать при необходимости.
HTML Imports — возможность импорта блоков HTML, хранящихся в других HTML-файлах
Блюдо из всего вышеперечисленного можно приправить нативными CSS-переменными, нативными ES-модулями и серверным пушем HTTP/2. Еще есть слоты, кастомные атрибуты, кастомные события и прочие детали. О них немного позже, когда перейдем к практике.
Да эти ваши веб-компоненты почти нигде не поддерживаются
Сухие цифры — лучшие друзья инженера. Давайте с этого ракурса посмотрим на «почти нигде»:
Custom Elements — 78.71%
Shadow DOM — 79.12%
Template — 89.61%
HTML Imports — 69.16%
Как мы видим, вышеуказанные технологии работают в браузерах у подавляющего большинства пользователей. Картину немного портят HTML-импорты, но использовать полный набор мы не обязаны (я предпочитаю нативные ES-модули для разбития на удобные блоки всего и вся), даже по отдельности в этом списке можно найти для себя много «вкусного».
Очень рекомендую не доверять мне слепо, а сходить по приведенным ссылкам. Там вы, например, сможете увидеть текущий статус для данных спецификаций и то, что Custom Elements и Shadow DOM получили полную поддержку в Firefox, начиная с версии 63. Когда основная масса пользователей лисы обновится до этой версии, а этот момент не за горами, общие цифры станут еще немного привлекательнее. Также, вы могли обратить внимание на «неполную поддержку» Custom Elements и Shadow DOM в Safari. Яблочный браузер не даст вам унаследовать ваш компонент от встроенного нативного браузерного элемента, типа кнопки, селекта и тому подобного. Еще в Safari есть небольшие нюансы в CSS-селекторах при использовании Shadow DOM. На практике, с этим вполне можно жить и не тужить. Видимо, по традиции, аутсайдером среди современных браузеров является Microsoft Edge. Разработчики утверждают, что поддержка реализуется. Ждем.
Хорошо, а что делать с остальными ~20% пользователей?
Для поддержки этих ребят можно использовать полифилы. Да, с полифилами работать будет немного медленнее, но невооруженным глазом это не заметно. Зато у всех остальных — будет быстрее.
Пытались лет пять назад делать проект на Polymer. Все ужасно тормозило.
В те «далекие» времена, бушевал черновик стандарта (v0), поддержка которого была реализована только в Chrome. С тех пор многое изменилось: была принята новая версия стандарта — v1, нативная поддержка была реализована в различных браузерах, полифилы были переписаны, хорошие практики прошли путь устаканивания. Сам Polymer из технологического превью превратился во вполне рабочее решение, с которым приятно иметь дело.
Полимеры какие-то… Что это вообще?
Polymer — это библиотека для создания веб-компонентов. Она реализует поддержку всего того «сахара», к которому мы так привыкли при работе с популярными фронтенд-фреймворками: динамические привязки данных (bindings), репитеры для работы с массивами и т. д. На данный момент, вышла уже 3-я стабильная версия этой библиотеки. Разработка ведется при активном участии разработчиков Chrome. Экосистема поддерживается компанией Google.
Когда стоит использовать веб-компоненты?
Если вам нужна универсальная общая библиотека UI-компонентов. Случай из жизни: проект, в котором основное приложение написано на React, а бэкофис — на Angular. И хочется одинаковости и всяческого переиспользования кодовой базы. А веб-компоненты замечательно себя чувствуют в разных экосистемах.
Если вам близок подход «дизайн в браузере». Вы сможете творить без постоянных пересборок приложения и без лишних зависимостей. Это делает прототипирование весьма приятным занятием и позволяет вашему приложению плавно эволюционировать от состояния прототипа до состояния production-версии. Люблю такое.
Если вы любите старое-доброе ООП: создаете класс наследованием от HTML-елемента, реализуете в нем желаемые фишки и плюшки общего плана, а потом наследуете от него классы для специализированных компонентов. И вот у вас получился свой собственный микрофреймворк. Красота!
Если вы ненавидите БЭМ: Shadow DOM изолирует стили компонента. Нет необходимости ни в многоэтажных монструозных именованиях, ни в обеспечении навигации к декларациям в общей куче CSS. Все компактно упаковано в компоненте: стили, разметка, логика.
Если вы разрабатываете приложения на основе Electron. Текущая версия Chromium в Electron уже поддерживает все необходимое. Не смотря на общий лаг в версиях.
Если вы хотите написать свой фреймворк/библиотеку. Веб-компоненты — это отличная композиционная основа для подобных экспериментов.
Если вам нужен гибридный подход: вы реализуете классические веб-страницы с элементами SPA: кастомные теги можно использовать с любым серверным шаблонизатором, они могут являться просто частью общей разметки и отрабатывать свое назначение в нужный момент. Вы можете соблюдать тонкий баланс того, что рендерится на сервере и что работает на клиенте.
Если ваши пользователи используют современные браузеры. Само-собой.
Если вы разрабатываете PWA: основные мобильные платформы поддерживают все «из коробки». Для быстрого старта есть pwa-starter-kit.
Если вы заинтересованы в повышенной безопасности приложения а детальный аудит зависимостей для вас непомерно дорог. Тут все просто: меньше зависимостей — меньше неподконтрольных дыр.
Если вы маньяк-оптимизатор и любите работать с DOM API: веб-компоненты — это часть DOM API, со всеми стандартными возможностями обычных DOM-элементов.
Если вы обжигались о поломку обратной совместимости версий библиотек: когда все основано на хардкорном стандарте — оно как-то надежнее.
Когда вам НЕ стоит использовать веб-компоненты
Когда в требованиях к вашему проекту имеется необходимость поддержки старых и экзотических браузеров. В этом случае, вам не позавидуешь в целом. Мои соболезнования.
Когда вы разрабатываете несложные продукты с коротким жизненным циклом и у вас нет необходимости развивать единую кодовую базу.
Когда вы имеете дело, преимущественно, с легаси-кодом.
Когда вы и ваши коллеги используете только что-то модное и ничего другого знать не хотите.
Зачем мне все это? У меня есть React/Vue/Angular/etc, мне хватает...
Затем, что значительную часть того, что делает JavaScript в популярных библиотеках и фреймворках, можно переложить на более низкоуровневую браузерную реализацию. Ради скорости, сокращения непомерного объема зависимостей, сокращения самой зависимости от зависимостей. Ради добра.
