Несбывшиеся надежды веб-компонентов
Перевод статьи 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. Это тоже может быть интересно:
Лия витает где-то в облаках. Голый хтмл без js и даже ts сейчас уже никому даром не нужны. Даже на самых статичных сайтах сейчас куча динамики. Пользователи к этому привыкли. И с отключённым JS вы теряете больше половины веба. И тренд сейчас в сторону ещё большей привязки к JS.
Я прекрасно понимаю её желание PnP, собственно, по этой схеме работает MAM экосистема — вы берёте компоненты и ничего не программируя, не устанавливая, не импортируя, не регистрируя, просто берёте и компонуете их друг с другом получая высокодинамичное приложение. И новые компоненты можно создавать в таком же декларативном виде буквально в пару строк. Но это даже не близко не html и не веб-компоненты. Проблема в экосистеме, да. Но то, как она предлагает её развивать, — это тупик. Для интерфейсов нужны реактивные связи, а у веб-компонентов, как и у нативных дом-элементов, есть только интерактивное API. Это прошлый век. А работая над экосистемой нужно смотреть в будущее на пару шагов вперёд текущей индустрии.
JS отсутствует во время первичной отрисовки.
Это не прошлый век, а разница между приложением и сайтом. Все будто наглухо забыли, что она вообще есть.
Вся разница между ними в том, где крутится логика приложения — на сервере или клиенте. И если загляните в историю, то заметите, что этот цикл крутится уже много витков: приложения крутятся на сервере и обращаются к ним через терминалы, потом людям хочется большей независимости от сети, отзывчивости и приватности, поэтому они переезжают на клиента, но не хватает простоты обновления и расширения, поэтому клиентское приложение постепенно превращается в терминал для других приложений, крутящихся на сервере.. и так на следующий виток. Теперь у нас есть абсурдная ситуация, когда библиотека игр доступна через VK Mini Apps, доступный через VK, доступный через браузер, доступный через терминальную сессию винды.
Польза от «витания в облаках есть» — приземлить отбитых наглухо отрицателей семантики и доступности — благодаря им не все-все-все на дивах сделано. Ну и мотивировать разобраться что как работает, чем отличается. А когда бэк меняет лейбл на имг (который связан с скрытым чекбоксом через фор), и на мой вопрос «а как это работает» отвечает — «ну я видел, что у тебя там ошибка, но я сам все на жиквери (он для этого еще и жиквери затащил!) поправил, теперь все работает» — это печально.
Вот, кстати, на днях сделал пример, как мог бы выглядеть реактивный DOM: https://twitter.com/_jin_nin_/status/1486443577467146247
А как предлагается делать новый элемент без функциональной части на JS? Статья — полный бред, кроме части про централизованный каталог компонентов
Вы по диагонали читали?
В статье написано: «всё, что можно сделать без JS, должно делаться без JS».
Это к тому, что в последнее время чуть ли не норма встретить реализацию ховера на js.
О, ну это отдельная боль. Когда я делаю drawer через галочку, лейбл и тильду, в меня прям пальцем тыкают.
И с доступностью та же беда.
Однажды помогая коллеге я спросил «А почему у тебя в свайпере кнопки вперед / назад на дивах». Он посмотрел на меня, как на идиота и сказал «потому-что так написано в документации свайпера». На самом деле там ничего такого не написано, но во всех демо кнопки сделаны дивами.
С какой легкостью автор статьи упоминает элемент dialog, который до сих пор не поддерживается в safari
да он и в Firefox не работает без флага https://caniuse.com/?search=dialog
Здравствуй, соискатель!
Ты давно на просторах интернета, но так и не нашёл хорошего сообщества по фронденту? Не беда, сейчас исправим.
В нашем сообществе всё понятно и доступно. Что именно в нём есть?
1) Полезные статьи, что помогут тебе в развитии;
2) Разнообразные розыгрыши (последние были носки и почему то все хотели их);
3) Сложные задачи и пути их решения;
4) Опросы, чтобы узнать более актуальную информацию;
5) Также можно получать достижения;
Заходи к нам ТЛГ deveveloper_house_jun_front