Комментарии 16
Упомяну еще один недостаток Tailwind CSS. Если дизайн-макет подготовлен в Figma, то весь CSS-код фактически придется "конвертировать" в формат Tailwind - по сути, делать лишнюю работу. Для сравнения, при использовании чистого CSS или CSS-фреймворков наподобие Sass/SCSS можно взять почти весь CSS-код из дизайн-макета как есть, с минимальными правками.
Как по мне, самый большой недостаток 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 атрибут.
Атомарность еще со времен twitter bootstrap стала набирать популярность. До этого писали похожие классы самостоятельно, дабы облегчить себе работу. А также поддерживали (если поддерживали, конечно, но представим себе идеальный мир) документацию к UI-kit в актуальном состоянии.
По сути, приверженцы атомарности поняли, что это можно активно переиспользовать и это превратилось в подобие "оверинжениринга", когда нужно помнить всё, а в вакансии писать "опыт работы с tailwind/bootstrap/foundation/bulma/что_там_еще_было".
И теперь Ваша статья, в целом, сводится к нормально делай - нормально будет. Договаривайтесь о нейминге, подключайте линтер, попрактикуйтесь и поймете...
Кстати, а что с поддержкой @apply
? Не является ли это чем-то сложно отлаживаемым на подобие bad practice с mixins? Сам не использовал, но звучит так, будто никакая IDE мне не подскажет о том, где сколько чего хранится в apply. Это так или есть рабочий инструмент для отладки?
Плюсы:
- Tailwind CSS
Минусы:
- Tailwind CSS
Чем хорош и чем плох Tailwind CSS, или «Допустим, у вас стартап!»