Недавно я опубликовал статью с другим вопросом на похожую тему: Заменят ли веб-компоненты интерфейсные фреймворки? Большинство из нас сказали бы НЕТ. Но каков ваш ответ на более спорный вопрос о том, есть ли будущее у веб-компонентов?
Давайте увеличим масштаб и посмотрим, почему одни говорят, что веб-компоненты уже умерли, а другие думают, что за ними будущее веб-разработки.
Введение
В 2012 году, когда W3C запустил первую спецификацию веб-компонентов, многие ожидали, что веб-компоненты произведут революцию в разработке внешнего интерфейса. И есть все основания для оптимизма. Веб-компоненты обещали много замечательных вещей:
- Многоразовые компоненты с простым HTML, CSS, Javascript
- На основе официальных веб-стандартов
- Фреймворк не требуется
- Поддерживается во всех вечнозеленых браузерах
Но идея создания многократно используемых автономных HTML-компонентов на основе официальных веб-стандартов без какой-либо инфраструктуры звучала слишком хорошо, чтобы быть правдой. Несмотря на многообещающие преимущества, веб-компоненты постоянно пытаются найти широкое применение в отрасли. Многие разработчики говорят, что они уже умерли.
Кто прав? Каково текущее состояние веб-компонентов? Давайте подробно рассмотрим эти вопросы и рассмотрим, что такое веб-компоненты, где мы можем их найти, почему разработчики не хотят их использовать и что нас ждет в будущем.
Что такое веб-компоненты?
Веб-компоненты — это повторно используемые клиентские компоненты, основанные на официальных веб-стандартах и поддерживаемые всеми основными браузерами. Это отличный способ изолироватьфункциональность от остального кода. Кроме того, вы можете повторно использовать их в каждом веб-приложении и веб-странице.
Их цель — написать строго инкапсулированные пользовательские элементы для повсеместного использования. Веб-компоненты позволяют нам разрабатывать полностью независимо от интерфейсных фреймворков.
Основное преимущество веб-компонентов заключается в том, что мы можем использовать их везде. С любым фреймворком, или даже без фреймворка. — vuejs.org
Как они работают?
Вот пример определения автономного веб-компонента:
class MyWebComponent extends HTMLElement {...}
window.customElements.define('my-web-component', MyWebComponent);
Вы можете передать свой элемент на любую HTML-страницу следующим образом:
<my-web-component value="something"></my-web-component>
Подробнее о веб-компонентах читайте в других моих статьях:
Где найти веб-компоненты?
В мире веб-разработки, несомненно, правят интерфейсные фреймворки/библиотеки, такие как React, Angular и Vue.js.
Опрос о состоянии JavaScript за 2021 год показывает, что 80 % респондентов использовали React, за ними следуют Angular (54 %) и Vue.js. (51%). Кроме того, Svelte быстро развивается и привлекает все больше и больше пользователей. Какое место в этом рейтинге занимают веб-компоненты? Веб-компоненты полностью основаны на веб-стандартах, поэтому мы не ожидаем, что они будут здесь перечислены. Тем не менее, есть библиотеки, такие как Lit, которые помогают нам в их создании. Ведь им пользовались не менее 7 % респондентов.
Frontend Frameworks адаптируются к веб-компонентам
Однако это только половина правды. В последнее время наиболее часто используемые интерфейсные фреймворки получили довольно широкое распространение. Все они поддерживают создание официальных стандартных веб-компонентов.
Возьмем Angular, который предоставляет пакет @angular/elements, позволяющий разработчикам быстро преобразовать компонент в веб-компонент.
Элементы Angular — это компоненты Angular, упакованные как пользовательские элементы […] — angular.io
Angular Elements — это минимальная автономная версия фреймворка Angular. Он внедряется как служба для поддержки функций обнаружения изменений и привязки данных компонента. Если вам интересно, как работает Angular Elements в деталях, вот интересное Youtube видео Роба Вормолда.
Точно так же Vue.js поддерживает создание веб-компонентов с помощью метода defineCustomElement.
Vue поддерживает создание пользовательских элементов с использованием точно таких же API компонентов Vue […] — vuejs.org
Адаптация самых популярных и часто используемых фреймворков к веб-компонентам показывает, что их создатели делают ставку на будущее с веб-компонентами.
Использование веб-компонентов
Как мы видим, веб-компонентов больше, чем мы могли подумать. Однако иногда для их создания все же используется фреймворк. Однако как мы можем измерить фактическое использование веб-компонентов? Один из подходов — посмотреть, как часто веб-сайт регистрирует хотя бы один пользовательский элемент, вызывая customElements.define.
Напоминаем, как определить пользовательский элемент:
class MyWebComponent extends HTMLElement {...}
window.customElements.define('my-web-component', MyWebComponent);
Для Chrome мы можем сделать это, проверив использование функции CustomElementRegistryDefine на chromestatus.com:
Вы можете видеть, что около 17 % всех веб-сайтов, просматриваемых в браузере Chrome, регистрируют хотя бы один Пользовательский элемент. Для меня такой резкий рост веб-компонентов был удивительным. По сравнению с этим, по данным w3techs.com, только 2,9 % (по состоянию на июнь 2022 г.) всех веб-сайтов используют React.
Что ж, похоже, что использование веб-компонентов выше, чем большинство из нас ожидало (по крайней мере, я так предполагаю). Но как насчет крупных компаний? Судя по описаниям вакансий, большинство из них требуют опыта работы хотя бы с одним из наиболее часто используемых интерфейсных фреймворков — React, Angular и Vue.js. Итак, есть ли компании, которым необходимо знать о веб-компонентах? Есть ли крупные компании, которые решили, что веб-компоненты — лучший способ реализовать свой интерфейс?
Одним из самых известных примеров является Github. Когда Github был запущен более десяти лет назад, его кодовая база внешнего интерфейса в основном использовала jQuery. С годами их монолит GitHub рос в размерах, и они увидели необходимость в улучшении инкапсуляции, прежде чем внешний интерфейс станет неуправляемым. Они решили использовать веб-компоненты, потому что их кодовая база уже была структурирована в поведение, подобное компонентам. Кроме того, они могут экспериментировать с веб-компонентами вместе со своей существующей инфраструктурой внешнего интерфейса, поскольку это не требует каких-либо предварительных затрат или «покупки» для конкретной инфраструктуры.
Но Github также столкнулся со многими проблемами при переходе к интерфейсной инфраструктуре с использованием веб-компонентов. Есть некоторые общие болевые точки, с которыми сталкиваются все разработчики в связи с текущим состоянием веб-компонентов. Это подводит нас к следующему вопросу.
Почему разработчики неохотно используют веб-компоненты?
Как упоминалось в начале, есть много причин полагать, что веб-компоненты могут заменить современные интерфейсные фреймворки. Сейчас многие разработчики все еще неохотно используют веб-компоненты. Почему это? Не потому ли, что они чувствуют угрозу от мысли о том, что веб-компоненты уничтожат интерфейсные фреймворки? Как я уже анализировал в своей предыдущей статье Заменят ли веб-компоненты интерфейсные фреймворки? — нет причин отказываться от вашего внешнего интерфейса. Наоборот, сочетание интерфейсных фреймворков с веб-компонентами — настоящий секрет успеха.
Как разработчик, вы можете использовать React в своих веб-компонентах, использовать веб-компоненты в React или и то, и другое. — реагировать на js.илиg
Тем не менее, нельзя обойти стороной тот факт, что веб-компоненты еще не полностью разработаны и сталкиваются с множеством проблем и болевых точек.
Проблемы веб-компонентов
Давайте посмотрим на трудности, с которыми сталкиваются веб-компоненты в текущем состоянии. Вот некоторые из наиболее распространенных проблем разработчиков при работе с ними.
Теневой DOM
Одной из болевых точек веб-компонентов является Shadow DOM. Хотя идея полностью инкапсулировать разметку и стиль компонентов превосходна, остается много проблем и открытых вопросов. Например, как применить глобальные стили к веб-компонентам с теневым корнем? Действительно, Shadow DOM позволяет нам изменять стили внутри их корней, используя, например, теневые части и переменные CSS. Кроме того, существует множество подходов и обходных путей для применения глобальных стилей, но окончательного решения я не видел.
Github также сталкивается с проблемами при работе с Shadow DOM и поддерживает открытое предложение Github для декларативных Shadow DOM. Это может решить некоторые распространенные проблемы, с которыми сталкиваются разработчики при работе с теневыми корнями.
Эти предложения еще больше упростят для инженеров поставку веб-компонентов и решат некоторые общие проблемы, связанные с текущим состоянием веб-компонентов. — github.блог
Но основной причиной этого предложения является поддержка рендеринга на стороне сервера (SSR) для веб-компонентов. Это приводит нас к следующей проблеме.
Визуализация на стороне сервера
Все современные фреймворки предоставляют способ рендеринга своих компонентов на стороне сервера. Например, Angular предоставляет Angular Universal, React — ReactDOMServer, а Vue.js предоставляет функцию renderToString.
Использование SSR в сочетании с веб-компонентами практически трудно или невозможно использовать. Веб-компоненты полагаются на API-интерфейсы DOM для конкретных браузеров, которые недоступны на сервере. По крайней мере, до тех пор, пока вы не используете какой-нибудь безголовый браузер, такой как Puppeteer, для предварительного рендеринга ваших компонентов и отправки исходной строки в браузер. Но даже при предварительном рендеринге ваших компонентов мы пока не можем использовать Shadow DOM, потому что пока не можем представить их декларативно. Следовательно, его невозможно передать в исходной строке HTML. Короче говоря: Чтобы использовать Shadow DOM, нам нужен JavaScript.
К счастью, есть такие библиотеки, как Lit или Stencil, которые помогают нам в создании веб-компонентов. Stencil уже предоставляет свой "Hydrate App-Bundle" для выполнения SSR, а также "Lit" работает над пакетом @lit-lab/ssr для рендеринга на стороне сервера.
Специальные возможности
Еще одна проблема, которую мы должны иметь в виду при работе с веб-компонентами, — это доступность. Доступность направлена на предоставление общедоступной глобальной информационной системы для всех. Тем самым мы гарантируем, что люди с ограниченными возможностями могут использовать все инструменты и технологии веб-сайта.
Эту проблему также можно проследить до Shadow DOM. Как правило, вы создаете узлы DOM и добавляете их как дочерние элементы другого элемента. С помощью Shadow DOM вы создаете дерево DOM с ограниченной областью действия, которое прикрепляется к элементу, но отдельно от его фактических дочерних элементов. Это поддерево с заданной областью называется теневым деревом и, по сути, является отдельным документом. Наличие нового документа означает, что если идентификатор установлен внутри теневого DOM, он должен быть уникальным только внутри этого пользовательского элемента.
Веб-компоненты вынуждены использовать ARIA для объявления своей семантики по умолчанию. — wicg.github.io
Надеюсь, вы знаете, что, используя правильные семантические элементы, вы напрямую предоставляете встроенные функции доступности для таких элементов, как кнопки или формы. К сожалению, при создании пользовательских элементов нам приходится самим добавлять все эти свойства, чтобы обеспечить те же функции доступности. В идеале пользовательские элементы должны иметь неявную семантику по умолчанию, как и собственные элементы. К счастью, существует предложение Объектная модель специальных возможностей (AOM), цель которого — включить это с помощью ElementInternals.
Проект Объектная модель специальных возможностей направлен на улучшение определенных аспектов взаимодействия пользователей и разработчиков, касающихся взаимодействия между веб-страницами и вспомогательными технологиями. — wicg.github.io
В настоящее время мы вынуждены использовать так называемые атрибуты ARIA в наших веб-компонентах для выражения семантики, неявной для нативных элементов. Например, если мы используем атрибут selected для такого элемента:
<custom-option selected></custom-option>
Нам также потребуется добавить к нему ARIA атрибут, чтобы обеспечить встроенные функции специальных возможностей:
<custom-option selected aria-selected="true"></custom-option>
AOM теперь предлагает использовать ElementInternals для установки семантики по умолчанию, чтобы избежать необходимости в дополнительных атрибутах, а также избежать потери семантики, если разработчики забудут добавить атрибуты ARIA.
Использование ElementInternals будет выглядеть так:
class CustomOption extends HTMLElement { constructor() { super(); this._internals = customElements.createInternals(this); } // ...}
В конце концов, мы можем сказать, что обеспечение доступности для наших веб-компонентов возможно. Но на данный момент это все еще связано с некоторыми дополнительными усилиями.
Что в будущем?
Тот факт, что все современные интерфейсные фреймворки рассчитывают на веб-компоненты, показывает, что их создатели планируют использовать их в долгосрочной перспективе. Но, как мы видели, на данный момент работа с веб-компонентами все еще связана с некоторыми нетривиальными проблемами. Вот почему большинство компаний, решивших пойти по пути веб-компонентов, используют библиотеки для облегчения своей жизни. Например, Github использует Catalyst. Лично мне нравится работать с библиотекой Lit, из которой черпал вдохновение Catalyst.
Catalyst, наша библиотека с открытым исходным кодом, упрощающая написание веб-компонентов — github.blog
Не только Github пошел по пути веб-компонентов. Многие другие компании, такие как Youtube, SAP, Salesforce и многие другие, осознали, что объединение веб-компонентов с их текущей архитектурой внешнего интерфейса — отличный способ инкапсулировать части своего приложения.
YouTube перестраивается с помощью веб-компонентов - react-etc.net
То, что такие крупные компании рассчитывают на веб-компоненты, подтверждает мое личное мнение о том, что без веб-компонентов нет будущего. Но и в ближайшем будущем без интерфейсных фреймворков тоже нет. Цель веб-компонентов заключалась не в том, чтобы заменить их, а в том, чтобы улучшить их.
Нет необходимости ненавидеть веб-компоненты.
Последние мысли
В заключение, каждому разработчику полезно хотя бы слышать о веб-компонентах и, в лучшем случае, даже знать, как с ними работать. Существующие предложения, как мы надеемся, решат многие проблемы веб-компонентов. Мы можем избежать их, используя такие библиотеки, как Lit, Stencil или Catalyst. Осознание того, что все современные интерфейсные фреймворки и многие крупные компании полагаются на веб-компоненты, ясно показывает, что веб-компоненты не мертвы.
Спасибо за чтение! Если вам нравятся подобные технические истории и вы хотите поддержать меня, чтобы я продолжал писать вечно, подумайте о том, чтобы зарегистрироваться, чтобы стать участником Medium. Это 5 долларов в месяц, что дает вам неограниченный доступ к историям на Medium. Если вы зарегистрируетесь по моей ссылке, я получу небольшую комиссию.
Вы также можете следить за мной в Medium, Twitter и LinkedIn. Или подпишитесь, чтобы получать мои истории по электронной почте.
об авторе
Я аналитик по разработке программного обеспечения в Accenture Song. Что меня больше всего движет, так это мое стремление создать что-то, что может быть полезным и изменить жизнь других. Например, вы устали просматривать свою историю, чтобы найти информацию, которую вы видели несколько дней назад? Мое расширение Web Highlights для Chrome поможет вам и повысит вашу продуктивность, организовав ваши исследования структурированным и эффективным способом. Как и в книгах и статьях, выделяйте текст на любой веб-странице или в PDF-файле. Ваши основные моменты синхронизируются непосредственно с веб-приложением на web-highlights.com, где вы можете найти их где угодно.
