Первый тред на сегодня — о том, нужны ли кастомным элементам библиотеки и в каких случаях можно обойтись vanilla JS.
По моим наблюдениям, у статей о веб-компонентах есть общая проблема: библиотеки вроде lit-element и Stencil упоминаются часто, а вот о ванильных кастомных элементах материалов куда меньше.
В итоге возникает ассоциация "кастомные элементы = библиотека” и закономерный вопрос: так ли полезен стандарт, если без библиотек все равно никуда? Об этом однажды написал Chris Coyier.
css-tricks.com/a-bit-on-web-c…
В комментариях к статье Rob Dodson заметил, что веб-компоненты — набор низкоуровневых примитивов. Библиотеки и фреймворки могли бы использовать их, чтобы изобретать меньше абстракций.
@Rich_Harris @edsilv @FabianCook @justinfagnani However we simply don't see enough value to adopt WC as the foundation to build the application component model upon. In fact it leads to more problems than gains.
Так это выглядело на бумаге. Но на сегодняшний день реальность такова, что авторы фреймворков не видят смысла использовать API кастомных элементов. Например, об этом говорил Evan You:
twitter.com/youyuxi/status…
Для начала стоит определиться, какие задачи мы решаем. В моем понимании, задача фреймворков — обновление представления при изменении данных. Ответ на вопросы, когда и как рендерить DOM.
Веб-компоненты эту задачу не решают от слова совсем. Они ничего не говорят нам о том, как и когда рендерить — они предлагают, что именно рендерить (кастомные HTML-элементы).
Об этом, в частности, говорит один из разделов документации React. Изложенная там позиция лишена критики в адрес веб-компонентов, но общий посыл очевиден: “скорее всего, вам это не нужно”.
reactjs.org/docs/web-compo…
Здесь мне видится некоторое столкновение интересов: фреймворки и кастомные элементы реализуют одну и ту же абстракцию компонентов, но разными путями и на разном уровне.
Отсюда и вбросы вроде “web components will replace your framework”. По-моему, от таких заголовков больше вреда, чем пользы. Увы, некоторые из сторонников веб-компонентов этим страдают.
В ответ на это сторонники фреймворков справедливо замечают, что одних только кастомных элементов в любом случае недостаточно: нужен “клей”, чтобы строить приложения на их основе.
Но значит ли это, что библиотека / фреймворк нужны всегда? Я так не думаю. Бывают случаи, где тащить лишние килобайты JS вовсе не обязательно и вполне хватает нативных API на чистом JS.
Пример: компонент рендерит DOM один раз, в дальнейшем нужно обновлять только атрибуты или CSS-свойства. Я не вижу смысла для этого подключать библиотеку или фреймворк, даже “исчезающий”.
Когда-то у Polymer был слоган “jQuery для веб-компонентов” — то есть, набор костылей, потребность в которых со временем отпадет. Но годы идут, и что-то пока библиотек становится только больше.
Библиотеки позволяют писать меньше бойлерплейт-кода и не думать о некоторых нюансах, но в чем-то и ограничивают. Некоторые из них скрывают нативные API, взамен предлагая собственные.
Я бы выделил три основных типа библиотек:
— основанные на классах (lit-element, FAST),
— основанные на функциях (Haunted, Atomico),
— компиляторы (Stencil, LWC, Solid).
В этой статье перечислены более 40 способов написать один и тот же простой веб-компонент, с бенчмарками и сравнением размеров бандла. В том числе, представлены и фреймворки.
webcomponents.dev/blog/all-the-w…
Статья демонстрирует, что при использовании ванильных кастомных элементов размер бандла быстро разрастается, когда компонентов в приложении становится больше (в приведенном примере их 30).
Мне этот факт напоминает расхожую фразу: начнешь писать на чистом JS — рано или поздно напишешь свой фреймворк. Что не обязательно плохо, ведь в процессе можно многому научиться.
Если вы пишете на библиотеке — стоит понимать, как она работает. В этом помогает чтение исходников и особенно тестов. В свое время я изучал таким образом устройство Polymer и lit-element.
О своем опыте применения этих знаний в написании кастомных элементов без зависимостей расскажу в следующем треде.