Недавно инженер-программист Райан Карниато опубликовал статью под названием «Будущее не за веб-компонентами», которая вызвала немалый ажиотаж. Я хочу доказать обратное: будущее за веб-компонентами.
TL;DR
Веб-компоненты (Web Components) — стандарт, встроенный в каждый браузер.
Использование большого компонентного фреймворка скоро будет похоже на использование jQuery: оба инструмента совершенно не нужны в современном JavaScript, хотя некоторые разработчики продолжают ими пользоваться.
Углубимся в статью Райана Карниато
Начнем с того, что Райан Карниато — создатель библиотек SolidJS и MarkoJS, потративший много времени на разработку версии того, чем должны быть компоненты. Я ценю и приветствую вклад Райана: он наверняка повлиял на то, какой стала спецификация Web Components.
Но думаю, что именно в этом кроется его разочарование. Пытаться заставить новый стандарт работать с существующим фреймворком все равно что вставлять квадратные колышки в круглые отверстия.
Рассмотрим основные аргументы Райана Карниато и приведем контраргументы.
Конкурирующие стандарты
Не существует конкурирующих стандартов — есть только один, и это веб-компоненты.
Согласитесь, спецификация Web Components не слишком сложна. Она нацелена только на одно — дать разработчику возможность определять собственные HTML-теги, обеспечивая надежную изоляцию компонентам, чтобы их использование — единоличное или совместное — не оказало пагубного влияния на остальную часть приложения.
Большинство методов, связанных с веб-компонентами, например addEventListener и dispatchEvent, также являются стандартным JavaScript, используемым уже более 10 лет. Опять же, это стандартные технологии, которые поддерживает каждый браузер, а не механизмы событий, специфичные для определенного фреймворка.
Реальность издержек утраченных возможностей
Мне не совсем понятен этот довод Райана. Веб-компоненты делают то, что делают, а это не так уж много, и ничего более. Не думаю, что спецификация сильно изменится, и вряд ли она должна сильно меняться.
Что касается ожидания новых возможностей, то по-прежнему можно создавать любые невероятные проекты на основе веб-компонентов.
Согласен, хорошего решения для рендеринга на стороне сервера пока нет, но можно прекрасно обойтись и без него. Не уверен также, что смешивать серверные компоненты с клиентскими — хорошая идея. Как по мне, сложность, которую это добавляет, слишком велика. Мое эмпирическое правило таково: то, с чем пользователь взаимодействует, является веб-компонентом; то, что статично или просто содержит ссылки, — серверный компонент. Я пользуюсь собственной небольшой библиотекой серверного рендеринга, содержащей простейшие серверные компоненты, похожие на Lit-компоненты, только без интерактивных возможностей. При этом часто использую функции с rend в качестве серверных компонентов.
Что касается простого решения «не использовать React», то выбор этого пути чреват довольно высокой стоимостью возврата. Цена перехода на веб-компоненты практически равна нулю. К тому же можно постепенно переходить на новые компоненты, не удаляя фреймворк из приложения и не заменяя его.
Затраты, имеющие отношение к привязке к фреймворку, — самые большие издержки, которые приходится нести.
Цена абстракции
Райан приводит несколько весомых аргументов, но их недостаточно, чтобы утверждать, что веб-компоненты неэффективны. Lit отлично справляется со многими задачами.
Что касается производительности, то да, похоже, что Solid обладает более высокой производительностью, но имеет ли это значение? Для большинства случаев, вероятно, нет. Приложение, использующее веб-компоненты, может быть достаточно быстрым.
Но это еще не все контраргументы
Есть множество других причин использовать веб-компоненты вместо фреймворка. Приведем некоторые из них.
Веб-компонентами можно делиться и использовать их где угодно
Один из самых важных доводов в пользу веб-компонентов заключается в том, что они работают везде и всюду, и вы можете легко делиться ими.
Чтобы убедиться в этом, вставьте приведенный ниже код на одну из своих веб-страниц и откройте ее:
<script type="module">
import "https://cdn.jsdelivr.net/gh/treeder/web-components@0/tr-rick/tr-rick.js"
</script>
<tr-rick></tr-rick>
Все просто. Не нужно использовать определенный фреймворк, устанавливать npm, применять транспилятор.
На GitHub собрана отличная коллекция действительно полезных компонентов, которые тоже можно использовать. Этого нет в документации, но, если вы хотите применить веб-компоненты без установки npm, импортируйте и используйте их следующим образом:
<script type="module">
import 'https://cdn.jsdelivr.net/npm/@github/relative-time-element@4/dist/index.min.js'
</script>
<relative-time datetime="${this.thing.createdAt}">...</relative-time>
Такого нельзя сделать ни с одним другим компонентным фреймворком. Одного этого должно быть достаточно для понимания того, что вы на правильном пути.
Никакого сложного фреймворка и никакой привязки
Вам не нужно использовать какой-то сложный фреймворк, чтобы воспользоваться преимуществами компонентов, как и не нужно зацикливаться на фреймворке.
Экономия времени на отсутствии сборки и быстром развертывании
Не уверен насчет времени сборки на Solid, но точно знаю, что сборка на Next.js занимает 15 минут. Я вообще не трачу времени на сборку, а развертывание у меня занимает 15 секунд.
Возможность легко отлаживать веб-компоненты в Chrome DevTools
Поскольку Chrome DevTools — нативный инструмент, отладка в нем веб-компонентов становится обычным и довольно приятным делом:
Заключение
Нравится вам это или нет, но теперь, когда веб-компоненты стали стандартом, они никуда не денутся. Тем, кто привязан к какому-то фреймворку, возможно, будет сложно перейти на технологию Web Components, но тем, кто начинает новый проект, рекомендовал бы попробовать это сделать.
Как только вы начнете использовать веб-компоненты, скорее всего, больше не вернетесь к прежним технологиям.
Начало работы с веб-компонентами
Начните с Lit — небольшой библиотекой-оболочкой, которая упрощает создание компонентов. Кроме того, обратите внимание на несколько замечательных в реализации библиотек UI-компонентов, таких как Shoelace и Material.
Читайте также:
- OutSystems: взаимодействие в реальном времени
- Как веб-серверы обрабатывают запросы
- Микрофронтенды: 9 шаблонов для каждого разработчика
Читайте нас в Telegram, VK и Дзен
Перевод статьи Travis Reeder: Web Components Are the Future
