Comments 26
Очень хорошо, спасибо!
А в будущем не хотите сделать сравнение BEM и Web Components ?
Почти все ваши сравнения про гибкость. С вашей точки зрения более гибкий инструмент лучше. Ну и понятно что ванильный css будет во всем гибче, ну то есть css в принципе не может не быть гибче, теилвайнд написан на тех же самых css стилях, он ограничивает возможности верстальщика. Его преимущество не в гибкости, а в скорости написания.
Насколько быстрее верстать на Tailwind?
Я думаю здесь стоит уточнить, что Tailwind быстрее только при верстке с нуля, но не когда ее нужно изменить или связать изменения с логикой. Гибкость ведь тоже увеличивает скорость разработки, но на поздних этапах развития проекта.
Правильно ли я понял, что Tailwind больше подходит для фиксированных проектов: сверстал и забыл?
Гибкость снижает скорость разработки, это вечный компромисс. Если бы это было не так то все бы писали на чистом js, и не было бы ни реакта, ни vue, ведь нет ничего гибче чистого js.
Реакт нужен, чтобы с DOM работать (вернее не работать ?), когда делаешь проект на реакт то пишешь на чистом js, разве нет?
Можно работать с домом и на js, реакт для этого не нужен. Смысл реакта в упрощении разработки интерфейса.
А как? Можно примеры?
Ну, про это тут можно почитать: https://learn.javascript.ru/dom-nodes или тут: https://doka.guide/js/dom/ - в целом это базовые знания веб разработки.
Смысл реакта в упрощении разработки интерфейса.
Что не отменяет того факта что когда пишешь используя Реакт - пишешь на чистом JS, и React не снижает гибкость а наоборот повышает ее, поскольку используя React ты можешь использовать React, использовать React без React синтаксиса, работать через React примитивы или использовать DOM напрямую. Вы почему-то считаете что добавление инструмента - уменьшает возможности а не увеличивает их.
Гибкость снижает скорость разработки, это вечный компромисс. Если бы это было не так то все бы писали на чистом js, и не было бы ни реакта, ни vue, ведь нет ничего гибче чистого js.
Эта скорость появляется только из-за переиспользования кода: зачем писать с нуля что-то для чего есть библиотека. С императивными языками это работает. Но о каком переиспользовании речь в случае вёрстки? Дают вам дизайн сайта в jpg и говорят "сверстай" - что ускорит использование tailwind?
Ну так вы сами и ответили на свой вопрос - считайте что tailwind это та же самая библиотека, но для стилей, где уже предусмотрели типичные для современного веба кейсы.
Любая библиотека ограничивает и дает меньше гибкости, ведь все можно реализовать самостоятельно но уже с учетом своего специфического случая. И это касается не только экосистемы js а вообще любого языка программирования.
Основные "минусы" Tailwind можно подытожить как сложность переиспользования в разных контекстах. Появись эта библиотека, когда в моде были Bootstrap и JQuery, её бы никто в здравом уме даже использовать не стал, по той же причине, почему нормальные люди не использовали inline стили. Сейчас почти везде фреймворки с компонентами и авторы Tailwind отдают переиспользование стилей им на откуп. BEM описывает как переиспользовать стили, поэтому получается какое-то сравнений яблок с апельсинами. Интересно было бы увидеть пример проекта на React + Tailwind и React + BEM и посмотреть сравнение на нём
Да, современная фронтенд разработка построена на компонентах, переиспользуются компоненты, а не стили. По этому идея автора зачем-то искать классы теилвайнда она очень странная:
Элементы Tailwind сложно искать. Нельзя так просто по атрибуту class узнать, в каком месте проекта находится соответствующий код.
Искать нужно компоненты, а не стили.
На svelte не сложно построить проект с переиспользованием и компонентов, и стилей. Я иногда даже пишу отдельные стилевые компоненты без HTML, просто CSS, и импортирую их в разные компоненты с похожим оформлением. Такое разделение стилей и компонентов сильно повышает гибкость.
Искать нужно компоненты, а не стили.
== искать нужно не только компоненты, но и конкретные HTML элементы внутри них. На реакте у меня не всегда получалось даже с DevTools определить какой HTML к какому компоненту относится. После того как компонент найден нужно еще потрудиться, чтобы найти в нем соответствующий HTML. Если нужно не просто изменить стиль, а немного перестроить структуру, то нужно еще понять какая роль у каждого HTML элемента, взрывая себе мозг, или плюнуть на это и верстать все с нуля.
просто CSS, и импортирую их в разные компоненты с похожим оформлением
Если у вас есть компоненты которые буквально используют одинаковые стили то есть смысл объединить их в один компонент и указывать через пропы разные кейсы его использования, тем более что если у компонентов одинаковый внешний вид то скорее всего и логика у них схожая.
Вообще использовать одни и те же стили для разных компонентов опасно так как вам всегда нужно держать в голове что эти стили влияют на разные компоненты, и после изменения в этих стилях вам нужно проверять что все окей со всеми компонентами которые используют их.
Если же придерживаться подхода при котором у каждого компонента свои стили то при внесении изменений в эти стили вам нужно проверять только этот один компонент.
И да на это можно ответить что при использовании теилвайнда мы же и юзаем одни и те же стили в разных компонентах, но мы исходим из того что мы не меняем стили теилвайнда.
== искать нужно не только компоненты, но и конкретные HTML элементы внутри них.
Я как-то плохо понимаю зачем вообще искать компоненты в хтмл, ну то есть вот у вас есть страница, вы знаете что на этой странице есть нужные вам компоненты, в таком случае можно ведь просто найти эту страницу в исходниках (или шаблон этой страницы), и искать компоненты там.
Не факт что на странице вы найдете нужный вам компонент, а что если в коде была прописана логика которая при определенных обстоятельствах скрывает нужный вам компонент? Скрывает не стилями, а js, то есть в dom-е этого компонента вообще не будет. И даже зная что такой компонент должен быть на этой странице, вы его там не найдете.
В исходниках же он точно будет.
У меня есть большой опыт написания проектов на svelte + BEM + PostCSS, есть небольшой опыт работы с несколькими проектами на svelte + Tailwind. Я пришел к выводу что Tailwind лучше переписать на BEM, иначе этот код невозможно поддерживать и развивать, я перестаю понимать даже свой код, написанный на Tailwind, зато хорошо ориентируюсь в BEM коде, написанном очень давно.
Когда я составлял список задач и проблем к этой статье, я опирался на большой опыт использования довольно мощного UI фреймворка - svelte. Я так же работал с проектами на React + Tailwind. В реакте, как я понял, не так просто применять те простые подходы к стилизации, какие можно применять в svelte. Когда я пытался разобраться со стилизацией в реакте, я не смог найти нормального способа написания стилей с использованием BEM, возможно его и нет. Tailwind в реакте наверное спасает ситуацию, но большого опыта у меня в этом нет.
Вы смешиваете в одну кучу зачем-то ещё и вопросы относящиеся к использованию фреймворков. Зачем? То что в React есть своя "модная" кухня для работы со стилями это понятно, но никто не мешает его сконфигурирован под то что вам нужно, хоть БЭМ, хоть CSS-in-JS.
Про долгую поддержку и развитие проектов: любой проект в какой-то момент достигает потолка гибкости своей архитектуры. Вопрос лишь в том что делать с этим в дальнейшем.
Пару лет назад я пытался прикрутить BEM к React, и мне не удалось это сделать, что меня сильно удивило.
Это как? Вроде стилизация в Реакте не отличается от обычного HTML: пишешь jsx-элемент с атрибутом className, подключаешь в этом компоненте css-файл (а то и sass), а там стили для этого класса. Или я что-то путаю?
Также я не понял вашу мысль насчёт работы с переменными.
Но для изменения всех цветов на сайте или всех отступов придется заранее прописывать все CSS-переменные и распространять их по всему коду.
На мой взгляд, все типичные цвета, отступы наборы шрифтов и т.п. в проекте и так должны быть определены в одном месте. Это примерно так же как использовать константы вместо волшебных чисел в императивных языках программирования. Опять же, это могут быть sass-переменные: при необходимости из них легко сделать css-перменные.
Некоторые считают, что BEM и Tailwind не противоречат друг другу. Да, их можно технически смешивать вместе, но это разные архитектуры. ... Такая смешанная архитектура должна быть хорошо продумана. Но я пока не видел НИ ОДНОЙ статьи по архитектуре Tailwind, чего уж говорить об архитектуре Tailwind + BEM.
Мне это кажется немного сомнительным. БЭМ с элементами несемантической вёрстки можно применять, но конкретно по канонам tailwind же один класс - это в среднем примерно одно css-свойство. Проще написать его в стили блока.
пишешь jsx-элемент с атрибутом className
== я не нашел там автоматической изоляции стилей, или какой-то удобный способ одновременно использовать и BEM и изоляцию стилей. Svelte автоматически добавляет класс .s- к каждому селектору и к каждому html элементу. React, как я понял, такое не может. И если и использовать там BEM, то только как глобальные классы.
Про BEM + Tailwind, я же говорю, что технически это можно сделать, но чтобы говорить о такой архитектуре нужен большой опыт, хотя бы два года разработки проектов и желательно с нуля и с дальнейшей поддержкой. Пока не соберешь все подводные камни, хорошей архитектуры не построишь.
Я уже вижу здесь те же проблемы: если использовать @apply, то это создаст дополнительную работу по конвертации стилей в уме: и когда читаешь код, и когда исправляешь что-то в DevTools и хочешь перенести изменения в код. Если писать Tailwind классы в HTML, то плюс к этому добавляется еще и дополнительная работа по отсеиванию мусора, когда анализируешь HTML. Но возможно Tailwind будет удобен, если весь проект использует utility-first подход к верстке. И на Tailwind можно верстать без дизайнера. В любом случае нужен реальный и большой опыт, чтобы в этом разобраться.
но чтобы говорить о такой архитектуре нужен большой опыт
Не нужно тут никакого большого опыта. Пишите в BEM а стили из TW применяете через apply
.some-component {
@apply p-2 flex gap-6;
}Таким образом получите utility first и быстроту в разработке от TW, навигацию, изоляцию и поддерживаемость от BEM.
А вообще имхо стоило бы какой-то метаязык придумать чтобы объединить BEM и TW. Чтобы как-то так писать
.some-component: p-2 flex gap-6
element: bg-red
video: aspect-3/4
В стилях и чтобы это трансформировалось в классы
.some-component__element
.some-component__video
Все проблемы которые описал автор решаются с помощью twin macro. Конечно я сравниваю css in js и нативный css, это не совсем корректно. Но если хочешь писать на tailwind мне кажется правильнее всего его использовать с styled components, тогда все проблемы гибкости отойдут, но придут конечно другие проблемы, свалкой стилей, если команда не договорится как они будут подходить к написанию стилей. А так согласен с автором, что если вы пишите сложный по стилям компонент, то tailwind код сложно осмыслить даже несколько пробежек по стилям, хоть они и достаточно декларативные.
прикрутить BEM к React, и мне не удалось это сделать, что меня сильно удивило. Там не было возможностей это сделать так, чтобы и изоляция стилей работала, и можно было менять стили из родительского компонента не ломая все остальные компоненты
Передать в props параметром className, а в дочернем сделать className={[styles.bem__class, props.className].join(" ")}
Илия не так понял, что не получилось?
Tailwind vs BEM — 2 (архитектура)