Перевод статьи The failed promise of Web Components с сайта lea.verou.me, опубликован на CSS-live.ru с разрешения автора — Лии Веру
Веб-компоненты обещали так много новых возможностей для HTML, с ними веб-разработка должна была стать намного доступнее для непрограммистов и легче для программистов. Помните тот восторг от каждого новёхонького HTML-элемента, который реально что-то делал? Помните, как было здорово, когда стало можно делать слайдеры, палитры для выбора цвета, диалоговые окна, раскрывающиеся виджеты прямо в HTML, без необходимости подключать какие-либо библиотеки?
От веб-компонентов ждали такого же удобства, но для намного более широкого спектра HTML-элементов, и гораздо быстрее, поскольку никому не нужно было бы ждать весь цикл стандартизации и реализации. Просто подключим скрипт, и бац — в нашем распоряжении стало еще больше элементов!
По крайней мере, так задумывалось. В какой-то момент пространство успели заполонить фанатики JS-фреймворков, балдеющие от сложных API, заумных процессов сборки и графов зависимостей, похожих на корни дерева баньян.
Вот как выглядят корни дерева баньян. Фото Дэвида Стенли на Flickr (лицензия CC-BY).
Просмотр кода компонентов на webcomponents.org приводит меня в дрожь, а ведь для меня писать JS самое привычное дело — я этим зарабатываю! На что же надеяться тем, кто не умеет писать JS? Чтобы использовать кастомный элемент из каталога, часто вначале надо провести целый ритуал вида npm флюгельгорн, import клоунскиетуфли, build чётотам — всё это без объяснения причин, просто потому что «вот моя куча зависимостей, ага, вот это вот всё». Многие шаги бывают пропущены, видимо как «очевидные». И часто вы продираетесь через этот лабиринт лишь затем, чтобы узнать, что компонент больше не работает или не подходит для вашей задачи.
Помимо сложностей с установкой, главная проблема в устройстве этих компонентов в том, что в них не уделяется должного внимания HTML. Они не проектируются максимально близкими к стандартным HTML-элементам, а рассчитывают на то, что придется писать JS, чтобы заставить их делать что-то полезное. HTML рассматривается как просто сокращение или, хуже того, чисто как маркер места будущего элемента в DOM, а все параметры передаются через JS. Я вспоминаю прекрасный доклад Джереми Кита про этот феномен несколько лет назад, где он рассматривал этот пример веб-компонента магазина от Google, яркий пример такого подхода. Вот всё содержимое его элемента <body>:
<body> <shop-app unresolved="">SHOP</shop-app> <script src="node_assets/@webcomponents/webcomponentsjs/webcomponents-loader.js"></script> <script type="module" src="src/shop-app.js"></script> <script>window.performance&&performance.mark&&performance.mark("index.html");</script>
</body>
Если сам Google показывает такой пример, то как нам надеяться, что компоненты других авторов будут соблюдать общепринятые соглашения HTML?
Джереми критиковал этот подход с точки зрения обратной совместимости: если JS не загрузился или отключен, или браузер не поддерживает веб-компоненты, вместо всего сайта будет пустая страница. Хоть это и вправду серьезное замечание, для меня на первом месте удобство: HTML — язык с низким порогом входа. Писать на HTML может намного больше людей, чем на JS. Даже те, кто в итоге начинает писать JS, часто приходят к этому после многих лет работы с HTML и CSS.
Если компоненты сделаны так, что без JS не могут, то это закрывает их для тысяч потенциальных пользователей. И даже тем, кто умеет писать JS, часто легче иметь дело с HTML: не так уж много людей используют слайдеры на JS или ваяют собственные, когда <input type="range"> стал везде поддерживаться, правда?
Даже когда без JS не обойтись, есть множество оттенков между крайностями. Хорошо спроектированный HTML-элемент может свести количество и сложность необходимого JS к минимуму. Возьмем элемент <dialog>: обычно для него нужно *немного* JS, но чаще всего код там весьма простой. Аналогично, элемент <video> полностью работоспособен, если просто написать его в HTML, и обладает понятным JS API для любого, кто хочет сделать что-то своё прикольное.
Еще как-то раз я искала простой, без зависимостей, компонент табов. Знаете, такой классический пример чего-то, что легко делается на веб-компонентах, который упоминается в половине руководств. Мне даже было неважно, как он выглядит, это было нужно для проверки интерфейса. Хотелось чего-то небольшого, что работало бы, как обычный HTML-элемент. Найти его оказалось так трудно, что пришлось писать собственный!
Можно ли это исправить?
Я не уверена, проблема ли это самой задумки веб-компонентов или же их документации. Возможно, для многих из этих веб-компонентов есть более простые способы использования. Возможно, где-то есть «ванильные» веб-компоненты, которые я просто не нашла. Возможно, я не там ищу, и где-то есть другой каталог с другими задачами и другой целевой аудиторией.
Но если нет, и если не я одна это чувствую, то нам нужен каталог для веб-компонентов со строгими критериями для включения:
- Plug and play. Никаких зависимостей, никакой начальной установки помимо добавления одного тега
<script>. Если зависимость абсолютно необходима (напр., в компоненте карты нет смысла рисовать свои собственные карты), компонент подгружает их автоматически, если они еще не загружены. - Синтаксис и API следуют соглашениям, принятым для встроенных HTML-элементов, и всё, что можно сделать без JS, должно делаться без JS, согласно принципу наименьшей мощности W3C.
- Доступность по умолчанию благодаря осмысленным настройкам ARIA по умолчанию, в точности как у обычных HTML-элементов.
- Возможность менять темы оформления с помощью
::part(), выборочного наследования и кастомных свойств. Минимальное оформление по умолчанию. Обычные CSS-свойства должня просто «работать», насколько это возможно. - Только один компонент каждого типа в каталоге, при этом гибкий, расширяемый и постоянно дорабатываемый и улучшаемый сообществом. Не 30 разных слайдеров и 15 разных табов, через которые нужно продираться пользователю. Никакого брендинга, никаких громадин «библиотек компонентов». Только элементы, спроектированные как можно более похожими на то, что реализовал бы браузер, насколько это позволяют нынешние технологии.
Я бы с радостью поработала над таким каталогом, если есть еще желающие, поскольку это явно неподъемный проект для одного человека. Кто со мной?
P.S. Это тоже может быть интересно:
