Немного о грустном

Определенное время будучи самоназванным евангелистом Vue, я сталкиваюсь с одной и той же проблемой: при продвижении Vue есть главный pain point: UI-библиотеки.
Я всей душой и телом обожаю Vue, но Vue как экосистема страдает от нехватки выбора opensource UI либ качественного и современного уровня. Чтобы человек не взял при переходе react -> vue он все равно сталкивается с тем, что упирается то в шероховатости и забагованность, то в буквальную нехватку функционала. Но пост скорее попытка понять: как вы живете со Vue относительно UI либ. Поэтому хотелось бы увидеть в комментариях ваши истории.

А ниже моя манялитика как же так произошло:

1 и главное: Vue 2 -> Vue 3
У меня ощущение, что это дико сбило темп авторам UI библиотек на несколько лет. Bootstrap Vue, например, так и не оправился полноценно от этого, а многие либы застряли в развитии на года. Но, все равно мы можем встретить библиотеки которые ощущаются UI либами этого поколения: vuetify, Ant disign. Element UI (который стал Element Plus для Vue3 и тд). Их отличительная черта: сложная кастомизация, перегруженность функционалом, многое прибито гвоздями

2 на их место пришли UI либы среднего поколения:
Это амбициозные библиотеки которые пытались сделать все и сразу, эдакий модерн: Quasar (он ближе к первому поколению, но все-таки отнесем к 2ому). Naive UI (с любовью JSX для Vue) и главный представитель в виде PrimeVue (наверное, лучший представитель данного поколения). Тут UI библиотеки пытались проработать боль сложности кастомизации из 1ого поколения, но они ударились в другую крайность, что сделало системы: 1 местами хрупкими, местами испытывающими проблемы с функционалом, ибо предугадать все хотелки задача не из легких. Из-за того как сильно просело 1ое поколение в переходах, то и 2ке пришлось достаточно нелегко.

3 поколение: headless / shadcn like
Вначале пришли headless библиотеки: а ля radix, далее революция в мире UI библиотек в виде shadcn подхода с импортом в кодовую базу. В мире Vue это очень молодой подход, чувствуется, что многое сделано наспех, однако переход все-таки происходит. Тот же PrimeVue вначале сделал headless версию, а после вообще выпустил Volt UI. До него к нам уже запортировали из мире реакта Reka UI + Shadcn Vue и в последствии сделанный поверх Nuxt UI (и как видно пока он главный любимчик, хотя мне он тоже не полностью нравится). И, на самом деле, еще большое множество библиотек. Но все они на 2025 год ощущаются сырыми и их сложно брать as is скорее всего, вам придется становиться помощником и репортить ишьюсы и помогать их править. Таким образом это очень молодое поколение и, я думаю, что стабилизация займет еще года 2.

4 поколение: А тут я жду AI friendly UI библиотек, но все еще не до конца представляю как это будет выглядеть, но точно стоит ждать шаг в эту сторону (MCP + spec first design)

А что думаете вы? Какие используете библиотеки для петов или для коммерческой разработки?

По поводу бага выше:
Да Vue генерирует в Dev среде комментарии из template. Это поведение можно отключить вот таким образом. Тогда баг с Transition и тп пропадет

BEM-like

Будем разбирать каждый тип по очереди и начнем с BEM-like решений. Сразу оговорюсь, что тут речь не о чистом BEM, а именно о тех вариациях которые можно встретить зачастую в проектах и конкретно ДЛЯ ИЗОЛЯЦИИ (БЭМ решает и другие проблемы, но это отдельной статьи бы потребовало)

Ключевые признаки:
1) Пишем стили в <style> выбор между css/sass/postcss не важен
2) изоляция достигается оберткой стиля в BEM-like нотацию: имя компонента становится классом, далее поверх накидываются уже элементы/модификаторы и тд

Основные плюсы:
1) Нативность: для работы BEM-like почти никакого сопровождения со стороны фреймворка не требуется, работает везде
2) Простота (относительная): пишем почти как обычный CSS, но с парой правил сверху, справится любой. в блоке скриптов тоже представляется в виде обычных строк
3) Семантичность: зайдя в девтулзы найти компонент по классу легко, легко понять что именно за классы навешены на div, да и при чтении кода компонента +- понятно за что отвечает каждый тег
4) При грамотных действиях дает неплохую стандартизацию по именам классов на проекте/
5) Очень хорошо подходит для обучения новичков с точки зрения развития инженерных навыков (новички учатся быстро понимать, что классы могут иметь четкие роли, внешняя геометрия вне компонента и тд), но в реальности большинство ограничивается только базой нейминга без самой сути

Минусы:
1) Большие имена классов: то за что ругают чаще всего, что имена становятся длинными и громоздкими, есть техники уменьшающие длину классов, но они уже компромисны
2) С точки зрения изоляции, то изоляция держится на условном контракте, те если кто-то нарушит и переиспользует имя, то будет коллизия, на больших проектах имена классов раздуваются еще сильнее и перед именем блока появляется еще и "неймспейс", данная изоляция особенно течет на микрофронтендах, если не предпринять особых мер
3) Я не просто так пишу BEM-like. ибо BEM как таковой люди понимают очень по разному и каждый проект уникален в своем "БЭМ"-е. Также селекторы могут включать в себя любой хаос и не подчиняться строгой BEM-нотации
4) Относительный минус: порой людям кажется сложным поиск элемента сразу
5) Никакой защиты на уровне типизации (очепятка в имени класса обнаруживается только в рантайме)
6) Истекает из семантичности: на каждую маломальскую потребность в использовании стиля нуно придумывать отдельное имя, иногда это людям дается сложно и некоторые ощущают в этом потерю времени за зря

Нюансы:
1) Скорее всего в 99% случаев у вас будет 1 блок = 1 компонент, так как семантика понятия блока и компонента крайне близка. Действительно желание сделать блок это повод задуматься: а почему бы не вынести это в компонент (мне нравится, когда сам подход дает такие эвристики для мышления!)
2) Если вы разрабатываете библиотеку, то сохранность имен классов дает возможность расширения стилей (что в 90% зло), но иногда действительно спасает
3) Пользователи адблоков, кастомных тем/плагинов на сайтах скажут спасибо, ибо когда есть четкие классы, то их очень легко и удобно расширять и подвязываться на них

Вариации:
1) Может сочетаться со скоупами или модулями, но это во многом избыточно. Для модулей этого точно лучше избегать, так как БЭМ+модули даст крайне громоздкий и избыточный код, предпочтите подходы специфичные для модулей
2) БЭМ+atomics подход озвучивался даже в комментариях выше. Если вам нужно повесить только внешнюю геометрию или 1-2 класса, а нейминг придумать к этому нереально, то atomics прекрасно закрывает данную потребность. Тут советую больше присмотреться к unocss нежели tw из-за простоты настройки только точечных классов, а не всего подряд

Итоги:
1) В целом данный подход все еще работает, но на проектах которые предполагают большой размер, независимую разработку команд есть более современные и простые методы изоляции
2) У него есть сторонники (в том числе и я), но есть и жесткие хейтеры.
3) Подход постепенно теряет актуальность, но я все еще вижу хороший потенциал именно в обучении людей
4) Если выбираете BEM-like для своих проектов, то пожалуйста, не поленитесь и копните глубже в философию БЭМ-а (раскрыть мне все в 1 посте тут просто нереально) и подумайте еще раз надо ли оно вам

Анатомия композаблов

DISCLAIMER: сравнение натянутое и заведомо раздутое, но в нем есть и зерно истины

возможно это прозвучит дико, но композаблы не шибко отличаются от обычного ООП, только описание у них императивное вместо декларативного. И многих это действительно удивляет. Так что я решил показать это более наглядно

function useA () { // имя класса
  const b = ref() // поле класса
  const c = ref() // поле класса 2
  const sum = computed(() => b.value + c.value) //  getter (и возможно setter)
  function swap() {} // метод класса
  
  // тут может быть ваша логика конструктора
  
  // и даже деструктор доступен 
  onScopeDispose(() => { ... })

  return {
    b, // теперь b публичное поле класса (а вот С приватное)
    sum // публичный метод
  }
}

Вы можете возразить: а как же 3 столпа ООП наследование/инкапсуляция/полиморфизм.
С инкапсуляцией разобраться просто: композаблы и нужны, чтобы инкапсулировать логику в 1 месте (как сокрытие работает мы уже тоже рассмотрели)

Что насчет полиморфизма: с ним все замечательно, просто мы применяем его редко:

interface A {
  (): { // описываем параметра конструктора
    b: Ref<number>
    swap(): void // описали публичный интерфейс
  }
}
const useA1: A = () => { ... }
const useA2: A = () => { ... }

A1 и A2 реализуют один интерфейс и мы можем подменять их в зависимости от ситуации, 90% нам это не понадобится, но если сильно хочется то возможно

А где наследование то?
Ну с наследованием ситуация веселе. Сейчас такая тенденция, что наследования стараются избегать всячески предлагая вместо него использовать композицю, но многим лень, так как наследование написать на классах проще и удобнее чем композицю (особенно если хочется сохранить прежний интерфейс). С композаблами ровно обратная ситуация: мы легко можем использовать композицию, но наследование становится болезненным (чему я очень рад!)

function useA() {} // base
function useB() { // композиция ❤️
  const a = useA() // изи
  const { b, swap } = useA() // внедрение тоже легкое
  ... 
}
const useB = ({...}: {...} & Parameters<typeof useA>) => { // наследование 🙈
  const a = useA() // взяли и
  const c = ref()
  return {...a, с} // вернули
  ... 
}

Если кому интересно проверить теорию на прочность, то велком в комментарии. Но основная суть поста показать, что мы отчасти остались в тех же рамках только с переходом от декларативности к императивности, чтобы иметь большую гибкость в действиях