Размышления по поводу невыполненных обещаний веб-компонентов

Перевод «Regarding the broken promise of Web Components» Роба Додсона.

После прочтения «Невыполненных обещаний веб-компонентов» я начал писать самый длинный в истории веба комментарий, но решил, что лучше бы мне оформить все эти мысли в отдельный пост. Вот и он :)

Многолетняя работа над веб-компонентами оказалась пустой тратой времени

Работая в команде Chrome, я понял одну вещь — браузеры и разработчики по-разному воспринимают процесс внедрения возможностей. Если функциональность появилась в браузере — это «навсегда», то есть минимум на несколько лет или даже десятилетий. Большие перемены всегда являются результатом долгого и скрупулёзного процесса, едва ли заметного для сторонних наблюдателей.

Веб-компоненты — масштабное нововведение, поэтому изменения кажутся медленными. В процессе работы что-то было отброшено, что-то доработано, но всё это к лучшему. В случае с кастомными элементами, использование ES6-классов вместо прототипных объектов—лучшее решение. Однако оно потребовало пересмотра всей спецификации. Это может разочаровать, так как откладывает для масс нативную поддержку спецификации, но делает финальный продукт качественнее.

Я и сам из тех, кто хочет, чтобы процесс шел быстрее, но Safari добавил поддержку кастомных элементов и Shadow DOM в 2016 году, а Firefox планирует сделать тоже самое в 2017 (скрестим пальцы). Потребовалось очень много времени, но, на мой взгляд, мы приближаемся к скорой кроссбраузерной поддержке.

React ещё более лучше

React — потрясающая вещь. Он задает тон дискуссии для всех, кто работает над веб-компонентами. Моя точка зрения состоит в том, что идеи этих инструментов вовсе не исключают друг друга. Напротив, нужно стремиться сблизить два подхода ради возможности их совместимости в будущем.

Решение использовать React или использовать веб-компоненты (или даже все вместе) в конце концов должно зависеть от ваших собственных предпочтений и требований проекта. Скажем, через год или два, когда веб-компоненты будут полностью поддерживаться, перед вами встанет задача создания UI-библиотеки. Для крупной компании со множеством разработчиков разного профиля. Веб-компоненты в этом случае — прекрасное решение. Или другой пример. Вы работаете в рекламном агентстве, разрабатываете сайт для запуска нового продукта. У вас одна команда разработчиков, и они уже знакомы с React. В таком случае имеет смысл делать проект целиком на React. Другими словами, сценарий может быть любым, здесь важно уметь выбрать подходящий инструмент для каждого конкретного случая.

Немного отойду от темы. По моим наблюдениям, разработчики склонны недопонимать, что библиотеки, подобные AMP — ни что иное, как веб-компоненты (в частности — кастомные элементы). А тот же AMP — крайне успешный продукт, эффективный и востребованный на рынке медиа. Зачастую, споры о веб-компонентах заканчиваются сравнением фреймворка А и фреймворка Б. Но если сделать шаг назад, то можно обнаружить множество других, недооценённых и незамеченных примеров их применения.

Медленный DOM

Абстракции, подобные React и JSX — прекрасные инструменты, помогающие работать с DOM. Но их использование имеет свою цену. Самое слабое место — это скорость загрузки страницы и огромные размеры JavaScript-кода, который должен быть загружен и обработан. Это критично для маломощных мобильных устройств. Подробнее тему раскрывает великолепный доклад моего коллеги Сэма Сакконе.

Важно понимать: ни React, ни любая другая библиотека, создающая дополнительную абстракцию вокруг DOM (это касается и Polymer), не является волшебной палочкой. Когда вы тащите в проект мегабайты JavaScript-кода, то лишь перекладываете проблемы с больной головы на здоровую. Улучшить ситуацию позволяет разделение бандла и загрузка только нужных ресурсов и только тогда, когда они необходимы.

JSX и виртуальный DOM лучше DOM API

DOM API задумывался как низкоуровневый инструмент и предполагает реализацию дополнительных абстракций поверх него. JSX великолепен, но по заверению его автора, это не более чем оболочка для нативных возможностей по управлению DOM. Поэтому ничто не мешает использовать JSX в веб-компонентах. SkateJS и аналоги доказывают это.

Нет стандартизированной связи данных

Многие из описанных в статье проблем — результат отсутствия стандарта связи данных для веб-компонентов, поэтому для Polymer пришлось придумать свой. Когда-то существовал рекомендованный стандарт, Model Driven Views (MDV). Если я правильно помню историю проекта, Polymer изначально ориентировался именно на него, почитайте о нём подробнее. Забавный факт: до того как стать Polymer, проект носил рабочее название «toolkitchen».

Сегодня в создании шаблонов многие разработчики отдают предпочтение JSX (в стиле MDV). На горизонте такие штуки как Observables и ES6-прокси, и я не берусь предсказывать будущее в этой области. Вполне возможно, всё будет слишком изменчиво, чтобы вообще нуждаться в стандартах. В любом случае, конкуренция — всегда хорошо, и один прекрасный день будет найдено решение, удовлетворяющее всех и каждого.

Работать со строчными атрибутами ужасно

Так как кастомные элементы — ни что иное, как экземпляры классов, вы можете (и должны) обращаться к свойствам через геттеры и сеттеры классов ES6. В этом случае не нужно будет использовать атрибуты, разве что для передачи начального состояния (где это нужно). Я уже писал об этом отдельный пост.

Это значит, что ваши элементы могут работать со свойствами, а не атрибутами, и такие библиотеки как Angular 2 уже поддерживают такое взаимодействие с веб-компонентами в своих системах связи данных.

Продвижение лучших практик по созданию компонентов с использованием этого подхода—это как раз то, к чему я стремлюсь и чем занимаюсь при помощи моих коллег по команде. Так что следите за обновлениями :)

Заключение

Разочарование автора мне вполне понятно. Как человек, отдавший веб-компонентам долгие годы, я уже сам такой «ДА НУ КОГДА УЖЕ БУДЕТ ГОТОВО А?!» Но с другой стороны, я гораздо больше вдохновлён результатами работы, которую я делаю в этом году, чем в прошлом 2016.

Думаю, мы наконец-то крепко встаём на фундамент нативной поддержки, появляющейся в браузерах. Стандарты более-менее устаканились и теперь можно посвятить время публикациям и популяризации лучших практик. Сообщество также находит для веб-компонентов новые интересные применения: я уже упоминал SkateJS, но совсем недавно я открыл для себя Switzerland. Команда Polymer уже близка к релизу 2.0, а команда AMP только что завершила двухдневную конференцию, на которой поделилась результатами своей невероятной работы (видео есть на их YouTube-канале).

Поэтому да, как бы нереально это ни звучало, учитывая длину проделанного пути, я думаю, что 2017 будет хорошим годом для веб-компонентов. Остается много трудностей, но мы справимся с ними. Как в случае с любым другим инструментом, результат не будет панацеей. Но он решит реально существующие проблемы и послужит своего рода строительным блоком для решения будущих проблем веб-платформы.

Перевод «Regarding the broken promise of Web Components» Роба Додсона. Перевод Владислава Почепцова, редактура Вадима Макеева.