Как стать автором
Обновить

Комментарии 15

Упомяну еще один недостаток Tailwind CSS. Если дизайн-макет подготовлен в Figma, то весь CSS-код фактически придется "конвертировать" в формат Tailwind - по сути, делать лишнюю работу. Для сравнения, при использовании чистого CSS или CSS-фреймворков наподобие Sass/SCSS можно взять почти весь CSS-код из дизайн-макета как есть, с минимальными правками.

накидывание через @apply в source twcss не отменяет там исполmзование обычных css свойств. Можно спокойно понаписать что-то типа.

.class {
  border:1px solid black;
  ...
  @apply p-4 m-0 bg-grey-500
}

Просто не надо тащить tw классы в html от слова совсем и будет прямо гораздо проще.

Не будет

У нас нет tw классов в шаблонах от слова совсем, есть только конфиг + source css с apply + шаблоны. Оно еще и гит хуком в post-receive потом собирается. Мы лично счастливы. Но мы не фронтэндеры.

Как по мне, самый большой недостаток Tailwind - это его популярность.
Выбор инструмента по популярности, а не по тому подходит он или нет - вот это проблема.
Если у вас очередная админка или блог - ок.
Но когда у тебя в фигме 20 задизайнеренных интерфейсов и каждый уникален - и еще и tailwind туда - получается помойка из класов что нужны + куча классов из tailwind. Неподдерживаемая куча.

Компиляция из источника в tw подразумевает что в результате будут только те css, которые есть в ваших исходниках и не будет никакой помойки. Будет исходник с@apply классов tw/возможно смешанный с нативным css + ваши html/js/whatever "шаблоны", а на выходе кроссбраузерный css только с теми классами, которые реально есть в ваших исходниках и используются

Классы-утилиты для создания структуры - это очень удобно: всякие flex, column и т.д. Если дизайнер верстает по сетке, то p-1, mr-2, gap-3 - это тоже удобно. Плюс все размерности завязаны на общий конфиг.

Проблемы: портянки, миксы обычных классов и утилит, а также apply. Кажется, создатель tailwind считает apply большой ошибкой.

Кмк, tailwind просто заигрался, создавая инструментарий, заменяющий чистый css в 90% случаев. В итоге его нужно учить. Он позиционируется как фреймворк, но как решать реальные проблемы использования не ясно.

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

У quasar(vue) есть свой набор css-утилит, и вот их достаточно.

Tailwind даёт классное комьюнити: если использовать его силу, можно реализовать практически любую идею. 

А мне кажется, для хорошего простого понятного и мощного инструмента и комьюнити не нужна

Вот взять хотя бы CSS3

Но ведь за любым, даже очень интересно зрелым решением - огромное количество контрибьютеров и евангелистов;)

Использование таких apply-классов даёт нам возможность экспортировать целые наборы стилей.

Использование нормальных css-классов даёт возможность экспортировать нам целые наборы свойств.)

Использовать или нет — решать вам.

Как руководитель - запретил его использовать впринципе. Мне нужно чтоб код был поддерживаемым через условно пять лет. И не пришлось бы нанимать синьйора-фронтендера-зайчика который меняет работу каждый год (потому что ему "надо развиваться" (с) ), и который хочет попробовать всё подряд, в том числе всратый таилвинд или микрофронтенд, но не видит результаты своих принятых решений на долгосроке (потому что уже порядочно наговнякал и пора увольнятся.))

Воля ваша. Запрещать что-то просто «потому что» может быть и нормально, но каждой задаче - свои решения. Никто не говорит, что нужно использовать тот или иной фреймворк/библиотеку просто потому что, «хочется попробовать» - априори не хорошее решение. И тут уже всё равно, что подставить вместо tailwind…

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

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

Пробовал vite 4 + vue 3.2 + tailwind. Всё классы которые подключаются динамически, подтягиваютя автоматически. И в тесте и в конечном билде

Атомарность еще со времен twitter bootstrap стала набирать популярность. До этого писали похожие классы самостоятельно, дабы облегчить себе работу. А также поддерживали (если поддерживали, конечно, но представим себе идеальный мир) документацию к UI-kit в актуальном состоянии.

По сути, приверженцы атомарности поняли, что это можно активно переиспользовать и это превратилось в подобие "оверинжениринга", когда нужно помнить всё, а в вакансии писать "опыт работы с tailwind/bootstrap/foundation/bulma/что_там_еще_было".

И теперь Ваша статья, в целом, сводится к нормально делай - нормально будет. Договаривайтесь о нейминге, подключайте линтер, попрактикуйтесь и поймете...

Кстати, а что с поддержкой @apply? Не является ли это чем-то сложно отлаживаемым на подобие bad practice с mixins? Сам не использовал, но звучит так, будто никакая IDE мне не подскажет о том, где сколько чего хранится в apply. Это так или есть рабочий инструмент для отладки?

Плюсы:
- Tailwind CSS
Минусы:
- Tailwind CSS

Зарегистрируйтесь на Хабре , чтобы оставить комментарий