Веб-компоненты и открытые стандарты
Если спросить разработчиков, почему они выбрали веб-компоненты для своего проекта, довольно часто можно услышать такие аргументы
- Это веб-стандарт, сделанный открытым сообществом, а не какой-то частной компанией
- Веб-стандарты не ломают обратную совместимость, не придется переживать за свой код в будущем
- Все современные браузеры придерживаются стандарта в своем поведении, меньше сюрпризов на кросс-браузерном тестировании
Аргументы выглядят логичными и справедливыми в обычной ситуации, но в случае веб-компонентов есть нюансы, которые я попробую раскрыть в этой статье.
Открытый стандарт
Открытость стандарта подразумевает то, что он написан с привлечением разных заинтересованных сторон. В результате получается удовлетворяющий всех результат. Что же произошло в этом случае? Открываем документ и видим его авторов
- Dimitri Glazkov, Google
- Hayato Ito, Google
- Dominic Cooney, Google
Все они работают Гугле. Аналогичная ситуация и в истории коммитов в этот репозиторий. Попробуйте на графике контрибьюторов найти человека не из Гугла. В первой пятерке таких точно нет.
Получается, что этот стандарт написан почти на 100% в Гугле. Но, может быть, у сообщества была возможность высказать свои пожелания и они были услышаны? Давайте рассмотрим несколько примеров.
Глобальный регистр компонентов
Избегание глобальных сущностей является одним из важных аспектов дизайна масштабируемых систем. На эти грабли веб-разработка уже наступала в CSS, где любой класс применяется глобально ко всей странице. Веб-компоненты попытались починить это через Shadow DOM, но тут же сломали в другом месте, добавив глобальный регистр компонентов. Каждый компонент должен иметь уникальное имя, а если встретится дубликат, то выбросится исключение, и весь Javascript перестанет работать, если его не завернуть в try/catch.
Эту проблему зарепортил пользователь, но один из авторов стандарта ответил что проблемы никакой нет и закрыл тикет.
Спустя какое то время о той же самой проблеме сообщил уже сотрудник гугла, и этот тикет до сих пор висит открытым. Ну хоть к своим собственным разработчикам прислушиваются, уже неплохо.
Таким образом, спустя 6 лет после первоначальной публикации стандарта, мы все еще имеем проблему, которая должна была бы выявиться еще на первоначальном ревью. Хотя какое тут ревью, сотрудникам Гугла виднее, как именно нам будет хорошо.
Расширение нативных элементов
Возможно, Гугл игнорирует пожелания рядовых разработчиков, но прислушивается к разработчикам других браузерных движков? Они же все на общее дело работают. Но здесь тоже не все гладко.
Веб-компоненты предусматривают возможность расширения нативных элементов. Например, вы можете навесить дополнительную функциональность на тэг при помощи такого кода:
customElements.define('cool-button', CoolButton, { extends: 'button' });Этот код работает во всех современных браузерах, но не в Safari. Вот заявление разработчика webkit что они считают эту фичу хаком, вредящим будущему веба, и отказываются его поддерживать. В качестве альтернативы они выступают за поддержку custom-attributes по аналогии с custom-elements, но до стандарта этому предложению еще далеко.
Firefox тоже упоминает эту фичу в своем обзоре веб-компонентов (секция is=””) и показывает что у этой фичи больше минусов, чем плюсов
Тем не менее этот синтаксис все-таки попал в финальный стандарт, хоть не работает и никогда не будет в одном из трех основных браузеров, и тем самым опровергает правило «то что есть в стандарте, будет поддержано браузерами, рано или поздно»
Стабильность стандартов
В идеальном мире стандарты отличаются стабильностью, фичи не попадают в них просто так. Только проверенные временем практики оказываются в стандарте и крайне редко из него убираются.
В веб-компонентах все снова пошло не по плану. Изначально в пакет стандартов веб-компонентов входили еще и HTML-импорты. Предполагалось, что веб-компоненты будут импортироваться на страницу при помощи этой фичи.
Однако разработчики Firefox выступили против этой фичи. По их мнению, в это время уже были на подходе Javascript-модули и ещё один лишний механизм импорта в стандартах ни к чему.
В результате фича так и не дошла до финального стандарта, но ее реализация уже была добавлена в Chrome, и Google уже выпустил фреймворк Polymer, который на этот потенциальный стандарт опирался. В результате создатели Polymer бы вынуждены переписать свой фреймворк без использования HTML-импортов, а пользователям этого фреймворка пришлось столкнуться с уникальным событием — необходимостью съезжать с устаревшего веб-стандарта.
Здесь еще можно вспомнить значительное переписывание стандарта Shadow DOM, когда внезапно оказалось, что написанная Гуглом версия стандарта не устраивает остальных вендоров.
Таким образом, и принцип «стандарт — гарант стабильности» с веб-компонентами не сработал.
Однако, в конечном итоге, веб-компоненты все-таки оказались стандартизованы. Казалось бы, теперь уже все устаканилось, можно наконец наслаждаться благами стабильных стандартов, но не тут-то было.
Псевдо-стандарты
К сожалению, Гугл так и не вынес ничего полезного из урока переписывания ранних стандартов Shadow DOM v0 и наступает на те же грабли еще раз.
В этот раз речь об adoptedStylesheets. Маркетинговая статья красиво рассказывает о пользе этой новой фичи. При этом там умалчивается, что это никакой не стандарт, и поведение этой функциональности ни с кем не обсуждалось. Есть ссылка на псевдо-спецификацию, но при внимательном взгляде можно заметить, что никакая это не спецификация, а «Collection of Interesting Ideas» — то есть этот документ даже не дошел до Editor Draft — начальной стадии на пути в веб-стандарт.
Закономерным образом, при обсуждении этой спецификации с сообществом, вылезли недостатки дизайна. Но гуглеры не сдаются и призывают оставить поведение как есть, мотивируя это тем, что пользователи уже пользуются фичей в продакшене. В итоге получается такая ситуация:
- Гугл выкатывает в свой браузер фичу, ни с кем не посоветовавшись
- Затем выпускает фреймворк с использованием этой фичи и рекламирует его как production-ready
- Наивные пользователи начали пользоваться этим фреймворком, и теперь Гугл использует их в качестве аргумента чтобы оставить косячный стандарт как есть.
Это не было бы так плохо, будь это единичный случай, но у Гугла есть целая организация с подобными псевдо-стандартами на Github: https://github.com/wicg. Неопытные пользователи могут подумать, что это еще одна организация наподобие WHATWG или W3C, но нет, WCIG это такой своеобразный клуб по интересам:
Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
Вольный перевод:
Эта группа управляется сообществом. Несмотря на то что эти дискуссии проходят в рамках W3C, они не обязательно представляют взгляды членов W3C.
Таким образом, если вы видите очередной анонс нового «стандарта» от Гугла, советую проверять, откуда он исходит, и был ли там фидбек от других разработчиков браузеров.
Гугл оказывает очень большое давление на стандарты и вносит туда много разных фич. Не все браузеры способны поспевать за этим темпом и выбывают из борьбы. Сначала сошла с дистанции Opera и перешла на Chromium, теперь Edge. Эта ситуация развязывает руки Гуглу и позволяет добавлять в браузеры фичи, не советуясь ни с кем. В результате мы видим красивую картинку на caniuse, где 3 из 6 браузеров поддерживают некоторую фичу, в то время как Mozilla отмечает ее как вредную, поскольку она открывает возможность утечки данных пользователей.
Выводы
Надеюсь, эта статья позволит принять вам информированное решение об использовании веб-технологий. Статья выражает исключительно мое личное мнение, но содержит достаточно ссылок на источники, чтобы каждый смог их прочесть и составить своё собственное.
Если после всего этого вы все еще считаете веб-компоненты хорошим решением для вашего проекта, это замечательно. Но если единственным аргументом «за» был «ну это же веб-стандарт, они не могут ошибаться», то лучше пересмотреть свои выводы и перестать кушать этот кактус.
