TailwindCSS на замену БЭМ (Tailwind vs BEM)

Походив по собеседованиям, и пообщавшись за БЭМ, узнал, что существует некий TailwindCSS. Мне, как автору iAMcss, конечно же стало интересно, неужели можно уйти от БЭМа, не получив боли, простым способом?

Сначала погуглил "tailwind vs bem", по существу же нашёл две критические статьи:

• Brian Boyko: "https://dev.to/brianboyko/tailwindcss-adds-complexity-does-nothing-3hpn"
• mSnus, комментарий к статье на Habr "TailwindCSS – очередной фреймворк или новый шаг эволюции?"

Также нашёл видео с выступлением Маскса Савченко из Creonit, апологета tailwind:

Презентация на гуглодокументах.

Вот что мы видим по tailwind в нативной вёрстке:

<div class="flex items-center space-x-3.5 sm:space-x-5 lg:space-x-3.5 xl:space-x-5">
<img class="flex-none w-20 h-20 rounded-lg bg-gray-100" />
<div class="min-w-0 flex-auto space-y-0.5">
...

Нет, это не inline-styles. Что я по этому поводу думаю, смотрим под cut'ом...

Многие верстальщики с многолетним опытом (в том числе и я), привыкшие разделять содержимое (HTML), представление (CSS) и поведение (JS), не перемешиваюшие модно-молодёжно эти концепции, как то делают программисты (CSS-in-JS), изначально реагируют отрицанием, например. Отмечу, что в указанном примере-статье, решение использовать tailwind опираются только на то, что такой-то фреймворк уже использует tailwind, при том первоначальное отрицание выглядит следующим образом:

When I first started to actually use Tailwind, I was still pretty sceptical because of my background. A few days passed by and I soon realised it was a match made in heaven.

Как говорится, от ненависти до любви один шаг! Но это эмоции, присущие специалисту лишь пробующего новые технологии, но не имеющего опыта и понимания, почему лучше делать так, а не иначе... Стоило бы написать объективно по пунктам, что в плюсах, а что в минусах. Вот это я и попытаюсь сделать.

Стадия отрицания

Соглашусь с комментариями на Хабре (за символом "-" мои мысли):

• Fayon: 1) Это не «фреймворк». Это набор хэлперов и сборщик для них.
  2) Это не «новый шаг эволюции». Это попытка реинкарнировать методологию атомарного CSS, о которой уже успели основательно забыть.
  3) Он не удобнее «ванильного CSS», потому что круг задач, которые он адекватно решает, достаточно мал.
  4) Это нишевый инструмент, и чтобы его тянуть в проект, надо четко понимать зачем он там. В противном случае будет как с бутстрапом, который тянули везде, где надо и где нет, порождая хаос и бардак.
• dom1n1k: Атомарный CSS полезен в небольших дозах, в виде хелперов для ситуаций-исключений. Использовать его как основную методологию — тупиковый велосипедизм.
• mSnus: Семантика очень лаконичная, очень много двухбуквенных классов, поэтому набор классов на элементе выглядит нечитаемо, выхватить взглядом где там в коде какой отступ (и указан ли он вообще) очень сложно
• Aleksandr Hovhannisyan: Горизонтальное перечисление свойств в атрибуте воспринимается хуже, чем вертикальное в CSS-файле. You Can't Chain Selectors. It makes PRs harder to review.
• monochromer: Когда название css-класса соответствует названию компонента, то искать тоже можно без sourcemap'ов. Плюс снимается когнитивная нагрузка, когда изучаешь интерфейс через инспектор, так как лучше видно назначение компонента.
  - Кстати да, в моде скорость, а не когнитивные способности и объёмное понимание кода, потому такой довод почитателями TailwindCSS не берётся в расчёт вообще!
• mariner: Чтобы использовать CSS-переменные, нужно переписать конфиг.
• monochromer: Создавать россыпь атомарных классов должен некий сборщик/компилятор, а не разработчик.
• dom1n1k: Смешаны стили самого блока и его позиционирование. В БЭМ-е их разделяют и поверьте, это не чья-то блажь, это действительно упрощает жизнь.
• Alexufo: Минус такого подхода для меня вылился в работе с отзывчивостью. Вам придется увеличивать количество классов для разных брейкпоинтов рано или поздно.
  - Это самый существенный недостаток!!!
• Aleksandr Hovhannisyan: On paper, utility CSS actually sounds like it may be useful. In practice, though, Tailwind CSS (and utility CSS in general) suffers from the same issues that it attempts to solve and is, in my honest opinion, not worth using.
• Там же: I had "separated my concerns", but there was still a very obvious coupling between my CSS and my HTML. Most of the time my CSS was like a mirror for my markup; perfectly reflecting my HTML structure with nested CSS selectors.
  - Автор цитаты может не умеет БЭМ, раз ему приходится писать nested selectors, которые не рекомендуются ни в БЭМ ни в iAMcss?! Да нет же, умеет, в той же статье приводит пример с @extend. Но модификаторы, видите ли, ему очень утомительно придумывать (Phase 4), особенно в нотации БЭМ! Чувак, переходи на iAMcss ;)

Стадия принятия и понимания

А вернее стадия понимания, чем руководствуются те, кто TailwindCSS всё же использует. Под каждым комментарием за символом "-" мои мысли.

• alexesDev: на порядок проще и понятнее, чем css-in-js, без магии препроцессинга.
  - Это больше доказывает, что CSS-in-JS, если это не автогенератор и делается ручками (сочувствую тем, кому приходится подпиливать автосгенерированный код), совсем уж Г. И React идёт туда же, его любят те, кто на JS рос, а не на вёрстке...
• nemilya: По сути TailwindCSS — это продукт двух профессионалов своего дела — дизайнера (Steve Schoger) и верстальщика (Adam Wathan). И про них можно отдельно долго рассказывать — сколько сил они потратили для того, чтобы поделиться с людьми своим опытом.
  2017: Adam Wathan рассказывает про отличия CSS Utility Classes and «Separation of Concerns»
  2018: Utility first
• mariner: Практически невозможный рефакторинг. Например, создаем кнопки и потом ее копипастим N раз.
  - Не соглашусь, мы должны не копипастить, а инкапсулировать описание кнопки в компонент (например Vue).
• Сложности, которые снимает Tailwind, начинаются тогда, когда требуется в одном приложении в разных контекстах дать разное оформление. У БЭМа для этой цели используются модификаторы, а здесь же меняется список определений (а как его сделать разным для одного и того же компонента?).
• Все кайфуют, поскольку в БЭМе всегда получали оплеухи на ревью кода (как обозвать блок).
  Это говорит только о неудобоваримости БЭМа, пользуйте iAMcss и будет вам счастье! ;)
• Основное преимущество - легко менять копи-паст легаси, для такого рефакторинга, который не повредит исходному легаси. Просто же создать новую БЭМ-сущность и в css-процессорах прописать наследование не судьба? Судьба! (через PostCSS). А смысл, если можно БЭМ? А смысл в том, что Tailwind, в таком случае, ненужная абстракция.
• Adam Wathan: For the project you're working on, what would be more valuable: restyleable HTML, or reusable CSS? My goal at this point was to explicitly avoid creating classes that were based on my content, instead trying to name everything in a way that was as reusable as possible.

Как я думаю, когда норм?

• В качестве быстрого прототипирования на выброс, но выброс не происходит, рефакторинг боль!
• Для mixins внутри SASS/LESS etc...
• Внутри компонента - когда чётко известно где надо править, но при похожих компонентах, нужно будет править одно и то же или схожее в нескольких местах.

Смерть Failwind

Всё разбивается об @apply, цитирую:

• если я всё равно вынужден создать CSS-файл для использования @apply, что идёт против HTML-first подхода tailwind
• если я всё равно вынужден придумать имя класса для переиспользования, что идёт против идеи tailwind "не нужно придумывать классы"
• если я вынужден в CSS-файле вместо деклараций, перечислить список классов со специальной директивой @apply, что является не валидным синтаксисом CSS и для работы этого требуется специальный компилятор
• если классы всё равно представляют собой сокращения для одного-двух-трёх CSS-свойств
• если всё равно используется класс, в котором зашит целый набор свойств, что идёт против utility-first подхода tailwind

То выходит, что я умышленно отказываюсь как минимум от трёх главных идей tailwind, возвращаюсь к классическому подходу с селектором и списком свойств в фигурных скобках в CSS-файле, но записанных в придуманном синтаксисе и завязываюсь на сторонний пакет с компилятором. Зачем тогда tailwind? Ради коротких свойств-классов вместо более длинных деклараций? Так есть же emmet и пишут df Tab aic Tab и так далее.

И ещё, про стухание поддержки нагенерённого failwind-говнокода.

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

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