Веб-компоненты в 2023: нужно поговорить / Хабр
Я решил написать этот пост по мотивам своей недавней дискуссии в комментариях к другому посту, напрямую с веб-компонентами не связанному. Я часто вступаю в подобные дискуссии здесь на Хабре и на других площадках. Кроме того, я регулярно провожу технические интервью с разработчиками и мы, также, часто касаемся этой темы.
И вот, что я вам скажу: большинство фронтенд-разработчиков вообще не понимают, что такое веб-компоненты и зачем они нужны. Стандарту уже несколько лет, он давно поддерживается во всех популярных браузерах, но разработчики продолжают его игнорировать и, что более ужасно, создавать свои костыльные и излишне сложные решения там, где можно было бы с легкостью обойтись нативными браузерными возможностями. Веб-компоненты окружены ореолом глубоких заблуждений и непонимания. И с этим я хочу бороться.
Сперва, давайте разберемся, кто я вообще такой, чтобы браться за эту амбициозную задачу. Постараюсь описать свой профессиональный профиль так, чтобы это не выглядело банальным самопиаром. Ну, насколько это вообще возможно.
В данный момент, я являюсь тех-лидом небольшой группы энтузиастов, создающих инновационную открытую платформу для разработки веб-приложений. Мы пытаемся сделать, эту самую разработку, более простой и доступной. Это наша самая главная цель, как бы пафосно или наивно это не звучало. Мы хотим, чтобы создание веб-приложений стало более тривиальной задачей для дизайнеров, аналитиков, маркетологов, разработчиков для других платформ и стеков. В основе, мы используем существующие стандарты и проверенные технологии, такие как HTML, CSS, современный JavaScript, git, блокчейн, Smart CDN, нейросети… и, конечно, веб-компоненты.
Также, я специализируюсь на создании виджетов, микрофронтендов и библиотек для работы с ними. За моими плечами около 20 лет опыта в IT и немало решенных на практике задач. Думаю этого хватит, если кому-то недостаточно деталей, можно сходить по ссылкам в моем профиле, вступление и так получилось длинным. Давайте скорее перейдем к сути.
Веб-компоненты – это не замена вашему фреймворку
Многие попадают в эту ловушку, начиная сравнивать и противопоставлять веб-компоненты различным популярным библиотекам и фреймворкам. В итоге, эти многие, задаются вопросом: а зачем мне эти ваши нативные компоненты, если они, из коробки, не умеют делать того, что умеет, условный, React? Где реактивность? Где синтаксис шаблонов с привязками любых типов данных? Где работа с локальным и глобальным состоянием?
Этого всего нет, все верно. Но, вовсе не потому, что веб-компоненты плохие, а потому, что это не очередной хипстерский фреймворк, а часть современного DOM API, которая помогает решать некоторые, низкоуровневые задачи. И решать их блестяще, избегая создания лишних слоев абстракций.
Другими словами, веб-компоненты и <ваша_любимая_библиотека> – не конкуренты, а союзники в решении определенного класса проблем. А если вы любите строить свои велосипеды, то веб-компоненты – это отличная основа для велосипедостроения. Просто лучшая, на текущий момент.
Главное – это жизненный цикл
Повторю, потому, что это очень важно: главное – это жизненный цикл. С Custom Elements, вы обладаете бесценным знанием того, когда ваши компоненты появились у пользователя на экране. Не важно кто, как и в какой момент эти компоненты добавил, вы ЗНАЕТЕ что вам пора что-то с этим делать: инициализировать виджет, сделать дополнительный запрос, динамически подтянуть зависимость или ассет, “поздороваться” с другими элементами приложения… Да что угодно. Также, вы знаете, когда именно ваш компонент исчез и настала пора очистить память, “попрощаться” и прибрать за собой.
Да, у всех популярных компонентных либ тоже есть жизненный цикл, но для этого нужна та самая дополнительная внешняя абстракция, которая, во первых, потребляет дополнительные ресурсы, а во вторых, не всегда доступна и контролируема. А иногда ее и нет вовсе, если, например, статическая страница генерируется на сервере. Думаю многие, кто когда-либо делал какие-то динамические виджеты для какого-нибудь WordPress, хорошо знают о чем именно я говорю и какая это боль. Ох, тут можно отдельную статью написать…
Композиция и разметка
Веб-компоненты очень хорошо дружат с, его величеством, HTML. Они, по сути, его органичная часть. А HTML – это альфа и омега всего веба.
Добавить, условный React-компонент на страницу, вы можете только в шаблоне React (JSX), или в его рантайме через внутренний API. Либо, вам нужно делать какой-то враппер, и активировать весь последующий воркфлоу.
А добавить Custom Element – можно как и куда угодно, от любого серверного шаблонизатора или реактивного шаблона на фронте, до статического HTML-файла. И это будет просто работать. Браузер сам запустит вашу логику в нужный момент. В этом плане, веб-компоненты – это отличное решение для добавления динамических элементов при JAMStack подходе.
Shadow DOM – это опция
Некоторые считают, что все, что находится внутри веб-компонента, автоматически попадает в “тень”. Из этого, для этих некоторых, вытекают проблемы с индексацией поисковыми роботами и проблемы с внешней кастомизацией. И все это, тоже большое заблуждение.
Во первых, хорошей практикой считается не заворачивать индексируемый контент в Shadow DOM, а использовать для этого слоты и работать как с обычными потомками элемента.
А во вторых, Shadow DOM – это вообще не обязательно. Вы имеете полное право НЕ использовать эту технологию в тех случаях, когда, как вам кажется, она вам мешает. Тут я хочу сделать акцент, на том, что я не предлагаю полностью отказаться от использования Shadow DOM. Нет, это очень клевая штука, изучите ее обязательно. Но я за то, чтобы использовать теневую магию только тогда, когда вы сами хорошо понимаете зачем вы это делаете и как избежать проблем. Сила и ответственность, ну вы поняли.
Кстати, для тех, кто не знал, shadow root можно создать и у обычного элемента, например, div.
А про кастомизацию элементов с Shadow DOM я хочу написать отдельную статью.
Объектная модель
Custom Elements – это полноправные элементы DOM. Это значит, что они будут доступны через селекторы и что у них есть все свойства и методы обычных DOM-элементов. Это открывает богатые возможности для реализации решений со слабо связанной архитектурой и переносом многих взаимодействий на уровень стандартных браузерных возможностей.
Даже навигация по проекту становится праздником, когда вы через dev tools видите реальную структуру своего приложения, а не малопонятную кашу из созданных фреймворком безликих тегов.
Веб-компоненты – готовы к продакшн
Кто-то считает, что все, о чем мы тут говорим, это некая “сырая” технология, у которой есть проблемы с поддержкой. Ребята, где вы были 8 лет? Пожалуйста, зайдите на caniuse и проверьте сами. Да, некоторые браузеры, действительно, не поддерживают наследование от встроенных браузерных элементов. Но это совсем не критично и есть очень простые альтернативные методы работы с этими элементами. Все основные возможности – поддерживаются давно и везде, кроме, возможно, всеми заброшенных некро-браузеров.
Полезные ссылки
Библиотеки: Community: Base Libraries
Доки: Using custom elements
