Дайон Алмаэр опубликовал небольшой пост на тему противопоставления фреймворков и Web-компонентов — "The Truth about Web Components and Frameworks".

Дайон пишет про то, что причиной всех споров вокруг фреймворков и Web-компонентов является желание поделить всё на чёрно-белую абстракцию. То есть в данном случае найти наилучший инструмент для написания web-приложений. Но все желания спорящих разбиваются о суровую реальность "серого" мира: не все приложения можно легко разделить на "чёрные" и "белые". Например, использование Web-компонентов может очень сильно облегчить жизнь при переиспользовании кода в разных проектах, но если компоненты не переиспользуется, тогда использование Web-компонентов может быть избыточным. При этом могут существовать разные подходы к переиспользованию кода, и это нормально. Если компания покупает другую компанию, возникает проблема интеграции разных приложений, которые могут написаны на разных фреймворках и т.п.

Недавно я где-то увидел шутку про Теорию Великого Объединения JavaScript-фреймворков. В общем, неизвестно, сколько ещё пройдёт времени, когда кто-то придумает инструмент, который решит все проблемы с web-приложениями.

#musings #webcomponents #jsframeworks

https://blog.almaer.com/the-truth-about-web-components-and-frameworks/

Пару дней назад была представлена web-версия Apple Music. Web-версия также как и десктопная использует Ember, но с добавлением web-компонентов. Макс Линч — один из создателей Ionic — написал свои мысли по этому поводу в статье "Apple Just Shipped Web Components to Production and You Probably Missed It".

Макс пишет о том, что в сообществе очень много споров по поводу компонентных js-фреймворков и web-компонентов, так как они решают по сути одну и ту же задачу создания интерфейсов из переиспользуемых блоков. Тот факт, что Apple использует почти 50 компонентов у себя в приложении (нотификации, контролы для управления подкастами, видеоплейер и т.п.) говорит о том, что существует ниша для их применения. Например, их можно использовать для создания таких компонентов, которые могут быть использованы с разными фреймворками (скорее всего Apple решает именно эту задачу). Для создания web-компонентов в Apple music используется SencilJS, которая служит основой для Ionic.

Здорово видеть примеры удачного использования современных возможностей web-платформы в больших приложениях.

#webcomponents #ember #jsframeworks

https://dev.to/ionic/apple-just-shipped-web-components-to-production-and-you-probably-missed-it-57pf

Брайан Гринстед — разработчик Firefox — рассказал как происходила миграция интерфейса Firefox на web-компоненты — "The Firefox UI is now built with Web Components".

Для разработки интерфейса Firefox используется XUL (XML User Interface Language). Этой технологии уже больше двадцати лет. Впервые она появилась в прародителе Firefox — Netscape в 1997 году. XUL разрабатывался для унификации разработки интерфейса браузера на разных платформах (Windows, Linux, Mac OS X). Для описания внешнего вида и поведения элементов интерфейса браузера используется XBL (eXtensible Bindings Language). Пару недель назад XBL был полностью заменён на web-компоненты. Это важное событие для разработчиков браузера на пути к полному отказу от XUL в пользу стандартных web-технологий. Переход на web-технологии упростит кодовую базу и ускорит добавление новых фич.

По ходу переноса, конечно, были проблемы. Вот интересный случай из статьи: "Также был пользователь, у которого было открыто полторы тысячи вкладок. Он заметил сильные тормоза при открытии списка "All tabs". Оказалось, что он попал в пограничный случай, в котором алгоритм работал за O(N²). Проблема была исправлена".

Очень рекомендую почитать статью. Про опыт большого рефакторинга разработчики браузеров пишут нечасто.

#firefox #webcomponents #internals

https://briangrinstead.com/blog/firefox-webcomponents/

Пару недель назад Мэйсон Фрид из команды разработки Chrome представил предложение о добавлении декларативного способа создания Shadow DOM.

Shadow DOM — часть спецификации веб компонентов, инкапсулирующая представление компонентов (стили и элементы) вне DOM-дерева. Shadow DOM на данный момент может быть создан с помощью императивного API, то есть используя JavaScript. Проблема в том, что страницы, содержащие веб компоненты, не могут быть корректно интерпретированы поисковиками, которые не поддерживают JS, также такие страницы могут быть бесполезны для пользователей, которые используют браузерные плагины, отключающие работу JS.

Предложение "Declarative Shadow DOM" решает эти проблемы. Декларативная разметка с Shadow DOM может быть отрендерена браузерами без использования JS. Также поисковикам не надо исполнять JS, достаточно модифицировать парсер, чтобы уметь понимать новый атрибут shadowroot в <template>.

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

Очень многообещающее предложение. Также радует сам факт того, что разработчики Chrome наконец-то признали, что основной камень преткновения в адаптации веб компонентов — сервер-сайд рендеринг.

#proposal #experimental #webcomponents

https://github.com/mfreed7/declarative-shadow-dom

Лия Веру недавно написала статью с критикой web-компонентов — "The failed promise of Web Components".

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

Хорошая инициатива. Но Доменик Деникола (гуглер, занимающийся разработкой web-стандартов) в комментариях пишет о том, что недостаточно создать реестр, также нужно решить проблемы совместимости браузеров.

#webcomponents #musings

https://lea.verou.me/2020/09/the-failed-promise-of-web-components/

Джейсон Миллер и Мэйсон Фрид представили экспериментальную поддержку Declarative Shadow DOM в Chrome.

Declarative Shadow DOM позволяет описывать разметку web-компонентов декларативно в коде HTML-страницы без использования императивного API с помощью JavaScript. Это очень важная фича для развития экосистемы web-компонентов. Про неё уже был пост в канале, его можно найти тут.

Самое главное на что стоит обратить внимание при использовании Declarative Shadow DOM. Построение Shadow DOM производится на этапе парсинга страницы, за счёт этого компоненты на странице рендерятся быстрее по сравнению с традиционным императивным подходом. Элемент template c атрибутом shadowroot становится теневым корнем (shadow root) и автоматически прикрепляется к родительскому элементу. Для сериализации DOM дерева с Shadow DOM можно использовать новый метод getInnerHTML().

Экспериментальная поддержка Declarative Shadow DOM появилась в Chrome 85. Ожидается, что она будет включена по умолчанию в Chrome 88. Браузеры без поддержки Declarative Shadow DOM могут использовать полифилл.

#experimental #webcomponents

https://web.dev/declarative-shadow-dom/

Нолан Уолсон рассказал про возможные способы кастомизации web-компонентов — "Options for styling web components".

Нолан сделал web-компонент для выбора эмоджи. Он задался вопросом, как сделать так, чтобы пользователи компонента могли адаптировать его под любой дизайн, и нашёл четыре возможных решения:

— CSS-переменные. CSS-переменные "протекают" внутрь Shadow DOM и могут использоваться для кастомизации строго заданных параметров. Этот способ был выбран для компонента выбора эмоджи.
— Классы. Пользователь может задать CSS-класс у компонента для выбора заранее определённых вариантов отображения.
— Shadow Parts. Shadow Parts предоставляет возможность гибкой кастомизации предопределённых частей web-компонента.
— Внедрение стилей. Это решение может использоваться в качестве экстренной помощи, так как при его использовании пользователи должны полагаться на внутреннюю структуру компонента, что может привести к проблемам при обновлении компонента.

#webcomponents

https://nolanlawson.com/2021/01/03/options-for-styling-web-components/

Кристьян Оддссон рассказал об опыте использования веб-компонентов в GitHub — "How we use Web Components at GitHub".

В 2018 году GitHub завершил модернизацию фронтенд-кода, который был очень сильно завязан на jQuery. С того момента ребята разработали Ruby-фреймворк ViewComponent для создания независимых компонентов-вьюх и библиотеку Catalyst для упрощения разработки веб-компонентов, которая была вдохновлена Stimulus и LitElement.

Веб-компоненты в GitHub используются для серверной валидации форм, создания динамических фильтров, элементов ввода с автодополнением, для элемента копирования текста в буфер обмена, модальных окон и т.п. При открытии их исходного кода разработчики удаляют все зависимости (то есть заменяют код стандартными веб-компонентами), чтобы их компонентами можно было воспользоваться в любом проекте.

#webcomponents

https://github.blog/2021-05-04-how-we-use-web-components-at-github/
https://github.com/github/github-elements (репозиторий компонентов)

P.S. Благодарю Олега Ковалёва (@oleg_log) за наводку на статью.

Буквально за день до выхода статьи про веб-компоненты от GitHub Тайлер Уильямс рассказал об опыте использования веб-компонентов в GitLab — "Using web components to encapsulate CSS and resolve design system conflicts".

В GitLab веб-компоненты используются для инкрементального внедрения новой дизайн системы с изоляцией стилей. Для этого был создан специальный кастомный элемент slp-blog, в котором отображается статически сгенерированный HTML статьи с новым набором стилей. Если по какой-то причине загрузка JS-кода, отвечающего за инициализацию элемента, отваливается, то пользователь всё равно сможет прочитать статью, но без стилизации.

В общем, статья интересная. Почитайте, если хотите познакомиться с ещё одним сценарием использования веб-компонентов.

#webcomponents #css

https://about.gitlab.com/blog/2021/05/03/using-web-components-to-encapsulate-css-and-resolve-design-system-conflicts/

Макс Бок написал статью о том, почему выражения от контейнера очень важны для дальнейшего развития веб-компонентов — "Container Queries in Web Components".

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

#webcomponents #css #experimental

https://mxb.dev/blog/container-queries-web-components/