Развенчиваю мифы о веб компонентах:
Веб компонент — это нативная альтернатива react/vue/svelte и т. п.
Я понимаю, откуда этот миф, вы могли так подумать, потому что у нас везде компонент прибит гвоздями к своему фреймворку. Но веб компоненты - это не фреймворк и даже не библиотека, это браузерный API. Действительно, есть фреймворк поверх этого API - lit (https://lit.dev/).
(Хороший он или плохой, не тема этого поста), есть и другие фреймворки, которые могут использовать API веб компонентов. Но сам по себе он ни в коем случае не фреймворк, и не решает проблем фреймворка, и сопоставлять его с существующими фреймворками мало смысла.
Задача веб компонента уменьшить размер бандла и / или производительность фреймворков.
Такие цели действительно были заявлены в спичах продвигающих веб компоненты, но мы ещё не здесь, это цель - на далёкое будущее, когда кристаллизуется некоторая кодовая база, основа, которая одинакова в каждом фреймворке для работы с DOM API. Что-то, что пишут снова и снова для достижения того же результата. Но пока её не видно. По факту фреймворкам всё ещё удобнее работать с домом императивно, каждый из них имеет свой уникальный путь, и API вэб компонентов им попросту неинтересен (с позиции автора фреймворка). Однако этот API часто поддерживают для профита конечного пользователя, о чем мы поговорим дальше.
Веб компонент бесполезен?
Напротив, это очень полезный API, хотя нужный он не каждому пользователю. Чаще веб приложение генерирует всё DOM дерево от корня и расширяется библиотеками, написанным специально под него.
Это, безусловно, ограничивает полезность новых фреймворков, без кодовой базы готовых компонентов под них. Эта проблема также может быть решена веб компонентами, но это проблема уровня js тусовки, а мы с вами заглянем ещё глубже, на уровень вэба.
В чём идея API веб компонента как такового?
Веб компонент API позволяет нам расширять возможности html
Давайте представим, что нам нужен простой элемент
Из понимания этого момента легко выясняется, где этот API применять. Можно даже заполифилить html элементы, которые ещё не завезли, и тогда вам в будущем останется только удалить код полифила (и убрать префикс у тэгов)
Бесконечные возможности встраивания открывают так же двери для встраивания любой дичи из маркета пользователей в ваше положение (SalesForce так и делают), или вовсе создавать реестры универсальных компонентов, вкладывать react в vue, и наоборот, и так далее (можно, не значит нужно!))
Да, использование этого API потребует от вас дополнительных усилий, обертки добавят веса, а коммуникация между компонентами "деградирует" до нативного браузерного API, который мы так старательно избегаем оборачивая ее в фреймворк.
Но иногда, простой и максимально нативный браузерный API - это именно то, что нужно вам и вашему пользователю.
Веб компонент — это нативная альтернатива react/vue/svelte и т. п.
Я понимаю, откуда этот миф, вы могли так подумать, потому что у нас везде компонент прибит гвоздями к своему фреймворку. Но веб компоненты - это не фреймворк и даже не библиотека, это браузерный API. Действительно, есть фреймворк поверх этого API - lit (https://lit.dev/).
(Хороший он или плохой, не тема этого поста), есть и другие фреймворки, которые могут использовать API веб компонентов. Но сам по себе он ни в коем случае не фреймворк, и не решает проблем фреймворка, и сопоставлять его с существующими фреймворками мало смысла.
Задача веб компонента уменьшить размер бандла и / или производительность фреймворков.
Такие цели действительно были заявлены в спичах продвигающих веб компоненты, но мы ещё не здесь, это цель - на далёкое будущее, когда кристаллизуется некоторая кодовая база, основа, которая одинакова в каждом фреймворке для работы с DOM API. Что-то, что пишут снова и снова для достижения того же результата. Но пока её не видно. По факту фреймворкам всё ещё удобнее работать с домом императивно, каждый из них имеет свой уникальный путь, и API вэб компонентов им попросту неинтересен (с позиции автора фреймворка). Однако этот API часто поддерживают для профита конечного пользователя, о чем мы поговорим дальше.
Веб компонент бесполезен?
Напротив, это очень полезный API, хотя нужный он не каждому пользователю. Чаще веб приложение генерирует всё DOM дерево от корня и расширяется библиотеками, написанным специально под него.
Это, безусловно, ограничивает полезность новых фреймворков, без кодовой базы готовых компонентов под них. Эта проблема также может быть решена веб компонентами, но это проблема уровня js тусовки, а мы с вами заглянем ещё глубже, на уровень вэба.
В чём идея API веб компонента как такового?
Веб компонент API позволяет нам расширять возможности html
Давайте представим, что нам нужен простой элемент
<switch-toggle /> (результат скрещивания радиокнопки и чекбокса). В мобилке такие элементы повсеместно, а в html такого input-a нет. Но, благодаря API веб компонента мы легко можем это поправить. И причём неважно в каком фреймворке он будет использован, в jsx или vue шаблоне, может, php? Да хоть в mol, назовите любой, всё в вебе, в конце концов умеет генерировать html, а наш веб компонент позволяет в него встроиться! В этом суть веб компонента.Из понимания этого момента легко выясняется, где этот API применять. Можно даже заполифилить html элементы, которые ещё не завезли, и тогда вам в будущем останется только удалить код полифила (и убрать префикс у тэгов)
Бесконечные возможности встраивания открывают так же двери для встраивания любой дичи из маркета пользователей в ваше положение (SalesForce так и делают), или вовсе создавать реестры универсальных компонентов, вкладывать react в vue, и наоборот, и так далее (можно, не значит нужно!))
Да, использование этого API потребует от вас дополнительных усилий, обертки добавят веса, а коммуникация между компонентами "деградирует" до нативного браузерного API, который мы так старательно избегаем оборачивая ее в фреймворк.
Но иногда, простой и максимально нативный браузерный API - это именно то, что нужно вам и вашему пользователю.
