Комментарии 30
К плюсам можно добавить тот факт, что в выходном css файле у вас не будут присутствовать классы, которые реально не используются в разметке. Чистота и минимизация. Причем это относится и к тем классам, которые добавляются скриптами. Однако если вы хотите, чтобы некий класс всегда присутствовал на выходе, то вы и это можете сделать, объявив его вне директивы @ layer.
Следующий минус вытекает из предыдущего плюса – необходимость пересборки при изменении разметки (добавлениии класса, который ранее ни разу не использовался). В отличии, например, от бутстрапа, в котором весь список утилитарных классов присутствует в бандле.
Tailwind прекрасен.
Проблема, как и всегда, не в инструменте, а в том что скорее рядом с цепочкой классов на тэге появится аттрибут style="....", чем всё это переедет в @apply
Мы выбрали @apply в качестве основного инструмента, так как очень не хотелось смешивать разметку и стили. Документация однозначно говорит, что это анти-паттерн, но плюсы такого подхода перевесили всё остальное. Во-первых, любая опечатка приводит к тому, что код просто не компилируется. Во-вторых, упростилась ситуация с кастомными классами - все стили вешаются непосредственно на элементы, а классы выдумываются только тогда, когда необходимо по-разному стилизовать неразличимые иначе элементы. В-третьих, внутри одного css-блока можно использовать несколько @apply и группировать таким образом стили по смыслу.
ui-custom-list-element {
@apply flex flex-row items-center;
@apply relative px-2 my-4;
@apply font-sans text-lg text-red italic;
}
Блоки .block-1 и .block-2 почти идентичны друг другу, поэтому часть нужно вынести либо в общий класс + модификаторы, либо в переменные, либо в миксин.
Но интереснее другое. Не видя исходного макета, трудно говорить наверняка, но по многим косвенным признакам видно, что стилистика кода в целом оставляет желать лучшего. Много магических чисел, ручного позиционирования, calc-ов. И возникает вопрос: это всё потому что автор (исходного кода) в принципе плохо понимает верстку или его специфика TW заставила? Опять же, без макета непонятно. Впрочем, первое второму не противоречит.
Да, как я и написал в статье, код специфичен(мягко говоря), просто очень часто видел подобные скрины в подтверждение того, что tailwind ужасно засоряет разметку и из-за этого не может нормально масштабироваться на крупных проектах
Скрин был взят с просторов интернета)
Это я намекаю на два обстоятельства:
- Ваша попытка показать "эквивалентный" код похвальна, но к сожалению непоказательна. Почти наверняка там можно было написать намного чище и лучше.
- По моему субъективному опыту, любящие TW люди, как правило, слабы в верстке (ни на кого персонально сейчас не намекаю, я в целом). Не потому что тупые, а потому что уделили ей на пару порядков меньше внимания, чем условному Реакту.
Согласен, что там можно было сделать на порядок больше абстракций и сделать код еще чище и элегантнее, но тут скорее преследовалась цель показать разницу между количество кода с использованием Tailwind и CSS в целом. При наличии макета и цели сделать идеально, можно было сделать красиво. Да и главная цель была продемонстрировать @ apply в действии и что с помощью него можно делать красиво
Тут я не согласен, потому что Tailwind почти не предоставляет готовых решений, за исключением пары анимаций, он просто дает нам классы нотации эквивалентных CSS, которые мы можем использовать
(flex -> display: flex, justify-between -> justify-content: space-between). Возможно это утверждение справедливо в отношении условного Bootstrap, где есть классы, являющиеся готовыми решениями. Tailwind скорее не про это.
Как я и написал раньше для того чтобы писать на Tailwind нужно также понимать все эти CSS свойства, потому что ты используешь те же CSS свойства просто в другой нотации.
А у меня наоборот опыт такой, что люди которые пишут на Tailwind попробовали уже кучу разных инструментов для стилизации от БЭМ до CSS Modules, CSS in JS, etc... и выбрали именно Tailwind, потому что он им удобен.
Мы о разном.
@applyв вашем примере глобально ничего не меняет. Это просто немного другой способ организации кода, но суть там осталась плюс-минус одинаковая — вся та же самая каша магических чисел и повторящихся кальков, в которой трудно уловить логику и трудно поддерживать. Да, стало покороче, но не стало намного лучше и понятнее. (Вроде бы в новых версиях TW научился понимать css-переменные, но выглядит это, мягко говоря, спорно.)- Инструменты — да, наверное. Но я имею в виду слабое понимание нативной верстки: логики макета и дизайнера, потока документа, правильного позиционирования, тонкостей блочного/инлайнового контекста, логики поведения блоков при адаптиве и пр. С этим у большинства современных фронтов (пришедших в профессию в последние ~5 лет) изрядные проблемы. Причем нельзя сказать, что это какой-то рокет-сайнс, нет, но приходит это понимание далеко не сразу.
Думаю, вы немного не поняли, в каком контексте я показал этот пример, тут суть была не в том, что написано в этих стилях, в этом примере это играет второстепенную роль, первостепенно я хотел показать, что можно избежать спагетти кода в HTML(огромной награмажденности классов), на который многие ошибочно указывают при споре насчет того, насколько Tailwind захламляет разметку.
Если уж говорить про сам код, то это просто какое-то мессиво из непонятных переменных, приправленное не всегда логичной организацией и уместными свойствами и в целом какой-то правильно организацией кода в примере не пахнет.Думаю это не проблема конкретно Tailwind, я бы больше сказал, что это проблема всего IT, курсы аля "Как стать middle разработчиком за 3 месяца", гораздо больше влияют на то, что люди меньше изучают базу и сразу лезут во фреймворки(потому что на курсе сказали, что знание всего остального не обязательно и можно загуглить)/другие инструменты, которые являются надстройкой над чем-то базовым + изобилие готовых решений, которыми все пользуются тоже этому способствует.
Однако я не считаю, что Tailwind таковым является, мне кажется, что Tailwind больше про альтернативный подход, а не про готовые решения, он явно никак не влияет на понимание общего flow разработки/работы с дизайнером и тд
- Имею в виду, что аргумент про захламление разметки — да, самый популярный, потому что первым бросается в глаза, но не единственный. На самом деле проблемы глубже.
- "Проблема всего IT" — наверное тоже да, но только отчасти. Дело в том, что во фронтендерских кругах верстка годами культивируется как что-то неважное и несерьезное. Много раз видел и слышал.
apply разочаровал. Посмотрите в сторону либы cva. Она позволяет удобно вынести длинные классы в script
А мне наоборот показалось, что эта директива очень удобна и отлично работает, все-таки все зависит от задач и потребностей.
Директива с помощью которой можно писать те же tailwind классы, но в css файле, в некоторых моментах оказалась очень к месту.
Она наиболее полезна для работы с "цветными" классами. У нас цветовая схема обозначена в одном месте - конфиге tw, нам не нужно дублировать цветовые переменные в кастомные свойства css или sass-переменные, мы просто используем `apply dark:bg-gray-500`.
Плюс, если вы "прочувствовали" медиазапросы через префиксы тайлвинда, описание ваших css классов с их использованием становиться чище на мой взгляд, без лишних вложенностей @ media правил.
Впервые слышу, что только для MVP. Вообще-то, это уже позавчерашний день, вчерашний — Windi, а сейчас UnoCSS интересен
А в чем тогда преимущество tailwind если вы все равно длинные стили выносите в отдельный от вашего компонента объект с @apply?
Вместо этого можно выкинуть tailwind и использовать обычный (s)css.
Кстати сами авторы tailwinds не рекомендуют @apply:
"Whatever you do, don’t use @apply just to make things look “cleaner”
И забыли еще один большой минус tailwind - у него свое понятие размеров и цветов, надо запоминать что означают все эти bg-red-400 и mr-10. Если бы 10 означало 10px, это бы еще понятно, но 10 - это что-то относительно rem. Очень странная логика у tailwind.
А в чем тогда преимущество tailwind если вы все равно длинные стили выносите в отдельный от вашего компонента объект с @apply?
Преимущество проявляется когда вы пишете максимально атомарные компоненты, с небольшим количеством стилей, а также когда вы пишете адаптив для 4 устройств например(вы вместо того, чтобы писать огромную вложенность из @ media, просто пишете sm: xl: lg:, etc...), также темизация элементарна. Если все ваши компоненты огромные и у каждого элемента по 20-30 стилей, пожалуй, tailwind не очень.
И забыли еще один большой минус tailwind - у него свое понятие размеров и цветов, надо запоминать что означают все эти bg-red-400 и mr-10. Если бы 10 означало 10px, это бы еще понятно, но 10 - это что-то относительно rem. Очень странная логика у tailwind.
Мало кто пользуется именно этими значениями, обычно они переопределяются кастомным конфигом и делаются понятными в вашей команде, вместо bg-red-400 -> bg-red-base например, mr-10 -> mr-40 можно превратить, если вам так будет удобнее, да и к тому что одна единица 4px довольно быстро привыкаешь
Насчет адаптива очень интересно.
Если у вас действительно максимально атомарные компоненты, то вероятно, их много и они имеют большую вложенность. В этом случае завязывать все этажи дерева компонентов на ширину вьюпорта — это разрушение инкапсуляции и протечка всех возможных абстракций.
Более вменяемым видится подход с пробросом свойств во вложенные компоненты посредством css-переменных. И менять через @media, по возможности, именно переменные, а не классы/свойства.
А в ближайшей перспективе уже нужно двигаться в сторону @container, который TW не умеет. И пока непонятно даже, как контейнерные запросы в принципе можно вписать в его концепцию.
Думаю, что вложенность все-таки не настолько большая, чтобы она могла разрушать инкапсуляцию, если так, то скорее всего у вас уже какой-то overengineering и компоненты в 3 строки) ИМХО
Drilling CSS переменных вниз звучит очень страшно и уж точно ломает масштабируемость)) ИМХО
А по-поводу, @ container, очевидно, что они скоро будут активно использоваться, но думаю, что tailwind их внедрит как только у них появится обширная поддержка(сейчас это 86%, что не так много), а если уж прямо сейчас хочется, то по первой ссылке в гугле с 600 звездами на github есть либа - https://github.com/tailwindlabs/tailwindcss-container-queries
вложенность все-таки не настолько большая, чтобы она могла разрушать инкапсуляцию
Да любая нарушает, вопрос насколько сильно. Просто потому что вложенный компонент, который никогда не используется на уровне body уже не должен по-хорошему знать размер вьюпорта.
Drilling CSS переменных вниз звучит очень страшно
Почему?
по первой ссылке в гугле с 600 звездами на github есть либа
Я ж не зря написал, что непонятно, как контейнеры можно подружить с концепцией TW — она не приспособлена для этого.
Авторы библиотеки всё сводят к нескольким фиксированным размерам, что есть очевидный костыль. Ведь смысл контейнерных запросов (среди прочего) в том, что компоненты могут иметь индивидуальное поведение. Какой-то блок тянется на весь экран (от 320 до 4к), а условный бэджик 50-200px.
Либо, если писать размер в скобочках, то вместо простых коротких префиксов имеем то, что обсуждалось выше — много дублирующихся магических чисел.
Земля пухом тому кто на проде это говно увидит. Челу буквально придётся учить новый синтаксис, вместо знакомого css и выжигать о него глаза. Плюсы? Их нет.
Первый пункт это минус, а не плюс. Вёрстку написал, оставил в отдельном файле и забыл. В этом весь смысл. Для удобства переключения советую найти второй монитор. Адаптив да, чем-то проще вроде? А нет, проще просто написать нормальный css в пару блоков. Все остальные плюсы это какая-то муть о том как легко настраивать это говно. Минусы? Главный минус в том, что tailwind сдохнет и про него забудут через пару лет, а в проекте это говно останется до конца веков. Пожалейте себя и людей.
TW для адаптива прекрасен, главное понять что его brakepoint идут от меньшего к большему, и не надо париться с кучей media запросов, когда один и тот же класс описан и там и там и в третьем месте. При использовании apply описание класса со всеми brakepoint описано в одном месте входного файла
TailwindNotation.vue
какой-то mol/svelte подобный кашмарный синтаксис
Земля пухом тому кто на проде это говно увидит. Челу буквально придётся учить новый синтаксис, вместо знакомого css и выжигать о него глаза.
как вариант удалять эту г*нину постепенно\по-компонентно и заменять на свои нормальные стили. Container-queries также помогут в этом.
Никак не могу найти нормальное сравнение, может быть вы можете подсказать.
Почему tailwind, а не styled-components / scss например?
Чем он конкретно лучше?
Из минусов, которые я вижу:
- гриды нормально из коробки не работают (grid-template-areas сторонним плагином ставится)
- нет варианта написания js in css (для доступа к позиции скролла, либо тоггл класса и тд. да, тоггл решается classNames, но просто как пример)
- проблема с дебагом (по классу не всегда понятно, как конкретно найти нужный компонент в коде, т.к. могут повторяться)
- в сравнении с styled-components - нет поддержки typescript. Если какие-то стили не переданы - тайпскрипт не отловит ошибку
- темизация очень скудная. Как сделать больше двух тем я так и не понял. У меня обычно на проекте от 4х тем.
- опять же в копилку тем - её нужно поддерживать. Я честно говоря не очень понимаю, как большом проекте (экранов на 30) поддерживать цвета, отступы и тд. Если дизайнер изменил цвета на странице какой-то. Например красный не такой как обычно, белый заменили на чёрный, ещё чего, как мне поменять его в теме?
Вообще, нужно ли его менять или писать просто инлайн в таком случае? В styled-components или scss я могу просто тему новую создать и передать её как обёртку новой страницы. А тут как?
Tailwind не только для MVP