Понятно, что с лэндинга спрос небольшой, нужно быстро склепать, запустить, собрать лидов и дропнуть. Поэтому глупо ожидать какой-то технической проработки. Но хабр — технический ресурс, мне небезразлично качество, хочется подушнить и всё такое. Поэтому покопался на сайте курса aimipt.ru.
С первых же секунд сайт встречает прелоадером. Вроде бы браузер страницу загрузил, системная полоса загрузки прошла, что-то нарисовалось, но нет, надо подождать снова. Удаляется он, судя по всему, при onload. Если через Local Overrides удалить прелоадер, то на странице всё видно, нет каких-то глитчей или нюансов отрисовки, чтобы это понадобилось маскировать прелоадером. На странице есть синхронный скрипт three.js, который блокирует парсер и отрисовку до тех пор, пока не загрузится и не выполнится. Так что прелоадер тут вообще не нужен и скорее раздражает.
Про «свистоперделки» уже писали. Одно дело сайт-игрушка для Awwwrds. Но тут лэндинг, который продаёт курс. Люди приходят за описанием курса, спикерами, стоимостью, датами проведения, программой и, в конце концов, чтобы оставить заявку. Но не чтобы развлекаться, водя курсором по логотипу. Оно прикольно, но как-будто отвлекает от основной задачи. И ради этого грузится ~700кб JS, причём даже без gzip.
Семантика практически отсутствует. Есть только самая база: <header> с <nav>, <section> с заголовками и <footer>. Кое где мелькают абзацы и списки. Остальное — сплошной суп из <div>-ов/<span>-ов. Вручную вписанные цифры там, где можно было воспользоваться счётчиками. Изображения без width/height для уменьшения CLS. Тяжёлые png спикеров, размер которых в 3 раза больше того, что фактически отображается, нет нарезки под разные экраны.
При выключенном JS сайт нельзя просмотреть, бесконечно отображается прелоадер с 0%. Да, работоспособность без JS это забытая древняя практика, которую мало где встретишь. Но в реальности всякое случается: плохая сеть за городом, блокировки, метро, CDN отвалился и так далее. Это лэндинг со статическим контентом, а не тяжёлое JS-приложение. Отображение контент на таком типе сайтов не должно зависеть от JS.
Если удалить прелоадер, то без JS видно первый экран и подвал, потому что в этих разделах нет анимации появления. Остальное не видно из-за той самой анимации, которая инициируется JS-ом. То есть не будь тут прелоадера и дефолтных стилей для начала анимации, весь контент был бы виден без JS. Анимации появления уже можно делать с помощью Scroll Driven Animations, или инициировать стартовые стили только убедившись в работоспособности JS.
Что касается производительности, то полевых данных в CrUX недостаточно. Pagespeed не смог проанализировать страницу и выдал ошибку, а потом показал 57 для мобильных, что плохо и близко к красной зоне. Долгий FCP из-за прелоадера, 620кб блокирующего JS, шрифтов с Google Fonts и прочих блокеров. Стоят ли вторичные эффекты того, чтобы получать на выходе такие показатели производительности? Подобный лэндинг запросто можно было уложить в 100 баллов, заменив <canvas> на видео/анимированные изображения.
С доступностью тоже есть проблемы. Тот же Pagespeed выдал 4 ошибки, которые легко исправить. Полагаю, что Pagespeed или Lighthouse никто не запускал. Помимо того, бургер-меню, дровер и карусель не соответствуют требованиям доступности и не работают так, как должны работать эти виджеты. Также есть проблемы с контрастностью текста, нет описания ошибок в форме, используется только цветовая индикация полей с ошибками, alt-ы не везде соответствуют сути.
Отдельно позабавил «AI чат» и его JS, в котором захардкожен набор токенов и ответы на вопросы под эти токены)
В общем, заканчиваю душнить. Лэндинг можно было сделать намного лучше и AI с этим может помочь. DevTools MCP позволяет прогонять тот же Lighthouse, проверять ошибки и прокликивать реальный сайт в браузере. Пачка хороших скиллов на семантический HTML, доступность и хорошие практики повысят качество разметки и UX.
Делает, но поддержка Invoker Commands пока не такая хорошая. Применение Popover API к <dialog> позволяет создавать только немодальные диалоги, которые не блокируют остальной интерфейс. Чтобы создать модальный диалог, его нужно открыть в соответствующем режиме через вызов showModal() или декларативно через command="show-modal". Тогда браузер сам поставит inert, вынесет окно в отдельный слой и так далее.
Отчасти решаемые, отчасти нет. Можно заставить чекбокс быть кнопкой меню, обвешав его с ног до головы ARIA-атрибутами и JS-ом, который будет делать всё то, что чекбокс не делает, а кнопка меню должна.
Что касается работоспособности без JS, то есть как минимум три стратегии:
Прогрессивное улучшение. Без JS меню просто всегда отображается и не скрывается. С JS скрыто и переключается честно, с помощью кнопки со всеми нужными состояниями.
nojs + <noscript>. На body висит класс nojs и удаляется скриптом при загрузке страницы. Соответственно, если скрипт отработал, значит JS есть и класса не будет. Если нет, класс останется и от него в CSS можно скрыть элементы, которые зависят от JS. А <noscript> отображает содержимое только когда JS нет. В него помещается упрощённый резервный вариант, который работает без JS.
Ссылки и формы. Любое действие — это переход на другую страницу или отправка формы с обработкой на сервере. Меню может быть отдельной лёгкой страницей с набором ссылок, а кнопка раскрытия меню — ссылка на эту страницу. Вот статья об этом. С View Transition очень даже неплохо получается.
В современных браузерах кое какие элементы UI можно реализовать средствами HTML/CSS и это работает без JS: <details> + <summary>, Popover API, Invoker Commands, <dialog>, Scroll Snap. Это честные способы реализовать что-то, например меню через Popover API, вместо хаков на чекбоксах.
Потому что семантика, свойства, состояния и поведение не соответствуют требованиям виджета и ожиданиям пользователей. Поясню на примере чекбокса и кнопки раскрытия меню.
Чекбокс — это элемент формы, который предназначен для выбора одной или нескольких опций. У него есть устоявшийся аффорданс (внешний вид, который намекает на назначение элемента, подпись и квадрат с пустотой или галочкой внутри). Пользователи видит это и понимают, что можно нажать, галочка появится/исчезнет, опция будет выбрана/не выбрана, это не приведёт ни к каким лишним действиям и где-то рядом будет форма с кнопкой отправки.
Пользователи мыши ожидают, что нажатие по тексту также меняет состояние чекбокса. Пользователи клавиатуры ожидают, что на элемент можно сфокусироваться и появится рамка фокуса, а нажатие пробела переключит состояние. Пользователи программ чтения с экрана слышат подпись, роль и состояние элемента и из этого понимают, что это чекбокс и что с ним можно делать. Пользователи программ голосового управления ожидают, что голосовая команда «отметь такой-то флажок» сработает. И так далее, таковы ожидания.
Кнопка меню работает иначе и там другие ожидания. Использование чекбокса для меню не соответствует ожиданиям:
Если чекбокс скрыт (часто при реализации меню его скрывают и оставляют <label>), то пользователи клавиатуры и программ чтения с экрана не смогут сфокусироваться и активировать его;
Если чекбокс скрыт визуально, но доступен для клавиатуры, это приводит либо к тому, что пользователи не видят, где находится фокус, либо состояние фокуса не соответствует тому, что отображается. Обе ситуации запутывают;
Пользователи программ чтения с экрана слышат про чекбокс и не понимают, что происходит. Почему тут чекбокс? Это какая-то форма? Как чекбокс связан с меню? Что нужно сделать?
Пользователи программ голосового управления могут озвучивать команду и не получать никакой обратной связи, ничего не произойдёт;
При открытии меню, пользователи программ чтения с экрана услышат «отмечено» вместо «развёрнуто»;
При открытии с помощью клавиатуры фокус не будет помещён на первый интерактивный элемент внутри меню, нажатие Esc не приведёт к закрытию меню и возврату фокуса на элемент, табуляция внутри меню не будет зациклена;
И так далее...
Чекбокс просто не соответствует тому, как должно себя вести меню.
Здравый подход, побольше бы разработчиков ему следовало. Однако по поводу п.2 сделаю оговорку. Фанатичное использование CSS только ради того, чтобы не писать JS может привести к хакам.
Одно дело подсчёт элементов (в комментариях ниже писали). CSS-счётчики и вывод в content. Это нормально. Другое дело всякие «меню» на чекбоксах и «вкладки» на радио-кнопках с :checked. Вот так лучше не делать, потому что это портит UX, доступность и это хак.
Инициатива Baseline отводит 30 месяцев (2.5 года) с момента появления фичи во всех основных браузерах (Chrome, Edge, Firefox, Safari и их мобильных версиях). Спустя это время фича получает статус Baseline Widely Available, то есть по исследованиям группы WebDX этого времени достаточно для широкого распространения. Так что ваш подход и временной диапазон близок к статусам Baseline.
«Без JS» действительно не получится. Иногда эта догма приводит к разного рода хакам на чекбоксах и прочему, что лучше было бы реализовать на JS. Но то, что платформа предлагает некоторые примитивы, которые позволяют сократить объём JS — это хорошо на мой взгляд.
Для Lit подойдут как любые библиотекии веб-компонентов (сделанные на любом фреймворке или без), так и одиночные веб-компоненты. Обычно достаточно загуглить «x web component», где x — название того, что вам нужно. Посмотреть подборку библиотек веб-компонентов можно в этом репозитории. Ещё недавно релизнулись Web Awesome, наследник Shoelace от тех же авторов.
Чем-то напомнило мне расширение стандарта ESM aka import assertion или же import attributes. styles.css.js лично для меня выглядит немного противоестественно, а писать стили в шаблонных строках не всегда удобно. Да, есть расширения для IDE с подсветкой синтаксиса и автокомплитом в шаблонных строках, но на моей практике они не работают так же хорошо, как нативные файлы. Import Attributes позволяют импортировать CSS и JSON, а в будущем HTML напрямую. Кажется, этот стандарт станет хорошим дополнением к вашей идее
В целом выглядит интересно, мне всегда любопытно наблюдать за standard-based решениями без лишних абстракций и кастомного синтаксиса на каждом углу. Поэтому удачи в развитии идеи!
За веб-компоненты однозначно плюс, закинул себе в закладки, чтоб подробнее посмотреть. По поводу автокомплита в браузере, подсказок и прочего советую посмотреть в сторону генерации Custom Elements Manifest и набор инструментов Web Components Toolkit.
На самом деле уже давно нет никаких стандартных разрешений. Да, есть статистически более распространённые, но в реальности огромное многообразие устройств, настроек, режимов и т.д.
В этой статье, как и во многих вводных статьях про веб-компоненты, есть важное допущение. Веб-компоненты сравниваются и напрямую противопоставляются популярным JS-фреймворкам. Если смотреть с такой стороны, то веб-компоненты во многом будут уступать фреймворкам по функциональности и удобству разработки.
Например, нет декларативного синтаксиса шаблонов для привязки данных, циклов и условной отрисовки. Нет реактивных данных. Не хватает многих привычных вещей из фреймворков. С помощью современного JS и Web API всё недостающее можно реализовать, но для многих это будет созданием велосипеда и тратой времени.
Поэтому мне кажется, что правильнее смотреть на веб-компоненты, как на набор низкоуровневых примитивов браузера, расширений DOM API, которые позволяют создавать собственные DOM-элементы с логикой и стилями. Как эти примитивы использовать и что из них можно построить — уже другой вопрос. А создать можно много чего.
Ну и проводить какие-то аналогии и сравнения с тем же React или Vue не голых веб-компонентов, а таких же надстроек над DOM и веб-компонентами, как, например, Lit.
Потому что веб-компоненты — всего лишь набор стандартов/DOM API/примитивов. Фьюзор, как я понял, это библиотека/фреймворк с дополнительной логикой и, судя по JSX, с компилятором. Поэтому фьюзор (или что-либо ещё) нужно сравнивать не с голыми веб-компонентами, которые работают в браузере как есть без сборщиков, компиляторов и кастомного синтаксиса, а с соответствующими библиотеками/фреймворками, в основе которых веб-компоненты: Lit, Stencil, Symbiote и так далее. Они как раз решают проблему многословности стандартного API.
В будущем, когда поддержка селектора :has() станет лучше, плавающие подписи можно будет делать с сохранением порядка <label> - <input>. Сейчас это обусловлено реализацией через + или ~. Со временем можно будет делать так:
А что насчёт проектов, которые не используют фронтовые фреймворки с компонентным подходом? Мир ими не ограничивается, есть огромное количество альтернативный технологических стеков. БЭМ ни разу не устарел и всё ещё отличный способ общаться на одном языке, писать консистентный и понятный код.
Понятно, что с лэндинга спрос небольшой, нужно быстро склепать, запустить, собрать лидов и дропнуть. Поэтому глупо ожидать какой-то технической проработки. Но хабр — технический ресурс, мне небезразлично качество, хочется подушнить и всё такое. Поэтому покопался на сайте курса aimipt.ru.
С первых же секунд сайт встречает прелоадером. Вроде бы браузер страницу загрузил, системная полоса загрузки прошла, что-то нарисовалось, но нет, надо подождать снова. Удаляется он, судя по всему, при
onload. Если через Local Overrides удалить прелоадер, то на странице всё видно, нет каких-то глитчей или нюансов отрисовки, чтобы это понадобилось маскировать прелоадером. На странице есть синхронный скриптthree.js, который блокирует парсер и отрисовку до тех пор, пока не загрузится и не выполнится. Так что прелоадер тут вообще не нужен и скорее раздражает.Про «свистоперделки» уже писали. Одно дело сайт-игрушка для Awwwrds. Но тут лэндинг, который продаёт курс. Люди приходят за описанием курса, спикерами, стоимостью, датами проведения, программой и, в конце концов, чтобы оставить заявку. Но не чтобы развлекаться, водя курсором по логотипу. Оно прикольно, но как-будто отвлекает от основной задачи. И ради этого грузится ~700кб JS, причём даже без gzip.
Семантика практически отсутствует. Есть только самая база:
<header>с<nav>,<section>с заголовками и<footer>. Кое где мелькают абзацы и списки. Остальное — сплошной суп из<div>-ов/<span>-ов. Вручную вписанные цифры там, где можно было воспользоваться счётчиками. Изображения безwidth/heightдля уменьшения CLS. Тяжёлыеpngспикеров, размер которых в 3 раза больше того, что фактически отображается, нет нарезки под разные экраны.При выключенном JS сайт нельзя просмотреть, бесконечно отображается прелоадер с 0%. Да, работоспособность без JS это забытая древняя практика, которую мало где встретишь. Но в реальности всякое случается: плохая сеть за городом, блокировки, метро, CDN отвалился и так далее. Это лэндинг со статическим контентом, а не тяжёлое JS-приложение. Отображение контент на таком типе сайтов не должно зависеть от JS.
Если удалить прелоадер, то без JS видно первый экран и подвал, потому что в этих разделах нет анимации появления. Остальное не видно из-за той самой анимации, которая инициируется JS-ом. То есть не будь тут прелоадера и дефолтных стилей для начала анимации, весь контент был бы виден без JS. Анимации появления уже можно делать с помощью Scroll Driven Animations, или инициировать стартовые стили только убедившись в работоспособности JS.
Что касается производительности, то полевых данных в CrUX недостаточно. Pagespeed не смог проанализировать страницу и выдал ошибку, а потом показал 57 для мобильных, что плохо и близко к красной зоне. Долгий FCP из-за прелоадера, 620кб блокирующего JS, шрифтов с Google Fonts и прочих блокеров. Стоят ли вторичные эффекты того, чтобы получать на выходе такие показатели производительности? Подобный лэндинг запросто можно было уложить в 100 баллов, заменив
<canvas>на видео/анимированные изображения.С доступностью тоже есть проблемы. Тот же Pagespeed выдал 4 ошибки, которые легко исправить. Полагаю, что Pagespeed или Lighthouse никто не запускал. Помимо того, бургер-меню, дровер и карусель не соответствуют требованиям доступности и не работают так, как должны работать эти виджеты. Также есть проблемы с контрастностью текста, нет описания ошибок в форме, используется только цветовая индикация полей с ошибками, alt-ы не везде соответствуют сути.
Отдельно позабавил «AI чат» и его JS, в котором захардкожен набор токенов и ответы на вопросы под эти токены)
В общем, заканчиваю душнить. Лэндинг можно было сделать намного лучше и AI с этим может помочь. DevTools MCP позволяет прогонять тот же Lighthouse, проверять ошибки и прокликивать реальный сайт в браузере. Пачка хороших скиллов на семантический HTML, доступность и хорошие практики повысят качество разметки и UX.
Делает, но поддержка Invoker Commands пока не такая хорошая. Применение Popover API к
<dialog>позволяет создавать только немодальные диалоги, которые не блокируют остальной интерфейс. Чтобы создать модальный диалог, его нужно открыть в соответствующем режиме через вызовshowModal()или декларативно черезcommand="show-modal". Тогда браузер сам поставитinert, вынесет окно в отдельный слой и так далее.Отчасти решаемые, отчасти нет. Можно заставить чекбокс быть кнопкой меню, обвешав его с ног до головы ARIA-атрибутами и JS-ом, который будет делать всё то, что чекбокс не делает, а кнопка меню должна.
Что касается работоспособности без JS, то есть как минимум три стратегии:
Прогрессивное улучшение. Без JS меню просто всегда отображается и не скрывается. С JS скрыто и переключается честно, с помощью кнопки со всеми нужными состояниями.
nojs+<noscript>. Наbodyвисит классnojsи удаляется скриптом при загрузке страницы. Соответственно, если скрипт отработал, значит JS есть и класса не будет. Если нет, класс останется и от него в CSS можно скрыть элементы, которые зависят от JS. А<noscript>отображает содержимое только когда JS нет. В него помещается упрощённый резервный вариант, который работает без JS.Ссылки и формы. Любое действие — это переход на другую страницу или отправка формы с обработкой на сервере. Меню может быть отдельной лёгкой страницей с набором ссылок, а кнопка раскрытия меню — ссылка на эту страницу. Вот статья об этом. С View Transition очень даже неплохо получается.
В современных браузерах кое какие элементы UI можно реализовать средствами HTML/CSS и это работает без JS:
<details>+<summary>, Popover API, Invoker Commands,<dialog>, Scroll Snap. Это честные способы реализовать что-то, например меню через Popover API, вместо хаков на чекбоксах.Потому что семантика, свойства, состояния и поведение не соответствуют требованиям виджета и ожиданиям пользователей. Поясню на примере чекбокса и кнопки раскрытия меню.
Чекбокс — это элемент формы, который предназначен для выбора одной или нескольких опций. У него есть устоявшийся аффорданс (внешний вид, который намекает на назначение элемента, подпись и квадрат с пустотой или галочкой внутри). Пользователи видит это и понимают, что можно нажать, галочка появится/исчезнет, опция будет выбрана/не выбрана, это не приведёт ни к каким лишним действиям и где-то рядом будет форма с кнопкой отправки.
Пользователи мыши ожидают, что нажатие по тексту также меняет состояние чекбокса. Пользователи клавиатуры ожидают, что на элемент можно сфокусироваться и появится рамка фокуса, а нажатие пробела переключит состояние. Пользователи программ чтения с экрана слышат подпись, роль и состояние элемента и из этого понимают, что это чекбокс и что с ним можно делать. Пользователи программ голосового управления ожидают, что голосовая команда «отметь такой-то флажок» сработает. И так далее, таковы ожидания.
Кнопка меню работает иначе и там другие ожидания. Использование чекбокса для меню не соответствует ожиданиям:
Если чекбокс скрыт (часто при реализации меню его скрывают и оставляют
<label>), то пользователи клавиатуры и программ чтения с экрана не смогут сфокусироваться и активировать его;Если чекбокс скрыт визуально, но доступен для клавиатуры, это приводит либо к тому, что пользователи не видят, где находится фокус, либо состояние фокуса не соответствует тому, что отображается. Обе ситуации запутывают;
Пользователи программ чтения с экрана слышат про чекбокс и не понимают, что происходит. Почему тут чекбокс? Это какая-то форма? Как чекбокс связан с меню? Что нужно сделать?
Пользователи программ голосового управления могут озвучивать команду и не получать никакой обратной связи, ничего не произойдёт;
При открытии меню, пользователи программ чтения с экрана услышат «отмечено» вместо «развёрнуто»;
При открытии с помощью клавиатуры фокус не будет помещён на первый интерактивный элемент внутри меню, нажатие Esc не приведёт к закрытию меню и возврату фокуса на элемент, табуляция внутри меню не будет зациклена;
И так далее...
Чекбокс просто не соответствует тому, как должно себя вести меню.
Здравый подход, побольше бы разработчиков ему следовало. Однако по поводу п.2 сделаю оговорку. Фанатичное использование CSS только ради того, чтобы не писать JS может привести к хакам.
Одно дело подсчёт элементов (в комментариях ниже писали). CSS-счётчики и вывод в
content. Это нормально. Другое дело всякие «меню» на чекбоксах и «вкладки» на радио-кнопках с:checked. Вот так лучше не делать, потому что это портит UX, доступность и это хак.Инициатива Baseline отводит 30 месяцев (2.5 года) с момента появления фичи во всех основных браузерах (Chrome, Edge, Firefox, Safari и их мобильных версиях). Спустя это время фича получает статус Baseline Widely Available, то есть по исследованиям группы WebDX этого времени достаточно для широкого распространения. Так что ваш подход и временной диапазон близок к статусам Baseline.
Это одно из базовых требований доступности и некоторые люди таким образом взаимодействуют с интерфейсом.
«Без JS» действительно не получится. Иногда эта догма приводит к разного рода хакам на чекбоксах и прочему, что лучше было бы реализовать на JS. Но то, что платформа предлагает некоторые примитивы, которые позволяют сократить объём JS — это хорошо на мой взгляд.
Для Lit подойдут как любые библиотекии веб-компонентов (сделанные на любом фреймворке или без), так и одиночные веб-компоненты. Обычно достаточно загуглить «x web component», где x — название того, что вам нужно. Посмотреть подборку библиотек веб-компонентов можно в этом репозитории. Ещё недавно релизнулись Web Awesome, наследник Shoelace от тех же авторов.
Разница если и есть, то она такая, что ей можно пренебречь. Иными словами, ощутимой разницы не будет.
Чем-то напомнило мне расширение стандарта ESM aka import assertion или же import attributes.
styles.css.jsлично для меня выглядит немного противоестественно, а писать стили в шаблонных строках не всегда удобно. Да, есть расширения для IDE с подсветкой синтаксиса и автокомплитом в шаблонных строках, но на моей практике они не работают так же хорошо, как нативные файлы. Import Attributes позволяют импортировать CSS и JSON, а в будущем HTML напрямую. Кажется, этот стандарт станет хорошим дополнением к вашей идееВ целом выглядит интересно, мне всегда любопытно наблюдать за standard-based решениями без лишних абстракций и кастомного синтаксиса на каждом углу. Поэтому удачи в развитии идеи!
За веб-компоненты однозначно плюс, закинул себе в закладки, чтоб подробнее посмотреть. По поводу автокомплита в браузере, подсказок и прочего советую посмотреть в сторону генерации Custom Elements Manifest и набор инструментов Web Components Toolkit.
Её, к сожалению, временно забросили, перекинув основную часть команды на другие проекты. Поэтому может лет 10, а может и никогда
На самом деле уже давно нет никаких стандартных разрешений. Да, есть статистически более распространённые, но в реальности огромное многообразие устройств, настроек, режимов и т.д.
Да, согласен, лучше
:focus-visibleиспользоватьТак 2.0 ведь остаётся как есть без изменений, что и означает долговечность. А 4.0, по сути, новое решение с тем же именем.
В этой статье, как и во многих вводных статьях про веб-компоненты, есть важное допущение. Веб-компоненты сравниваются и напрямую противопоставляются популярным JS-фреймворкам. Если смотреть с такой стороны, то веб-компоненты во многом будут уступать фреймворкам по функциональности и удобству разработки.
Например, нет декларативного синтаксиса шаблонов для привязки данных, циклов и условной отрисовки. Нет реактивных данных. Не хватает многих привычных вещей из фреймворков. С помощью современного JS и Web API всё недостающее можно реализовать, но для многих это будет созданием велосипеда и тратой времени.
Поэтому мне кажется, что правильнее смотреть на веб-компоненты, как на набор низкоуровневых примитивов браузера, расширений DOM API, которые позволяют создавать собственные DOM-элементы с логикой и стилями. Как эти примитивы использовать и что из них можно построить — уже другой вопрос. А создать можно много чего.
Ну и проводить какие-то аналогии и сравнения с тем же React или Vue не голых веб-компонентов, а таких же надстроек над DOM и веб-компонентами, как, например, Lit.
Потому что веб-компоненты — всего лишь набор стандартов/DOM API/примитивов. Фьюзор, как я понял, это библиотека/фреймворк с дополнительной логикой и, судя по JSX, с компилятором. Поэтому фьюзор (или что-либо ещё) нужно сравнивать не с голыми веб-компонентами, которые работают в браузере как есть без сборщиков, компиляторов и кастомного синтаксиса, а с соответствующими библиотеками/фреймворками, в основе которых веб-компоненты: Lit, Stencil, Symbiote и так далее. Они как раз решают проблему многословности стандартного API.
В будущем, когда поддержка селектора
:has()станет лучше, плавающие подписи можно будет делать с сохранением порядка<label>-<input>. Сейчас это обусловлено реализацией через+или~. Со временем можно будет делать так:А что насчёт проектов, которые не используют фронтовые фреймворки с компонентным подходом? Мир ими не ограничивается, есть огромное количество альтернативный технологических стеков. БЭМ ни разу не устарел и всё ещё отличный способ общаться на одном языке, писать консистентный и понятный код.