Вместо того чтобы выучить css учишь их таблицы, которые нужно

помнить потому что у них нет mb-1,2,3 с шагом в единицу нет. Там идет 1,2,3, а потом ху.к и 6, 9, 20 например. Не канает просто число с потолка написать. Итого ты оказываешься в рамках этих градационных правил, которые по сути ничуть не облегчают тебе жизнь. Большинство правил по факту являются 1 класс = 1 css rule. Что экономить? Время? В чем проблема прописать margin-bottom тот же? Код. Код в tailwind превращается в монструозное спагетти с миллионом классов на элементе. О да, эти классы можно скомпилировать в один мегагласс. В чем профит? Где упрощение? Где экономия времени и ресурсов? Это только с первого взгляда кажется, О круто m1 сделал мне отступы и сэкономил целых десять символов, но когда тебе нужно прописать какое-то хитровы..ное правило, которого в tailwind нет, то чтобы изменить представление элемента тебе нужно сходить в его код, потом сходить в стили. Отвечаю, когда дело доходит до правки стилей tailwind ну просто максимально портит тебе жизнь. Покажите крупный проект. Не лендинг. Не одностраничник. А действительно крупный проект, где все реализовано на tailwind. Да не найдете такого. Начать использовать tailwind - это значит поставить проект на рельсы, а слезть с них и отказаться потом будет ой как больно.

Спасибо за рецензию. Я потому и задал вопрос не а стоит ли юзать вообще tailwind, а по другому - стоит ли его использовать как опциональный инструмент для написания утилит "на лету". Например у тебя есть задача разместить списком какие-нибудь компоненты на конкретной странице и чтобы расстояние между ними было 15пкс (да не 1rem с 16 пкс по их градации а именно 15пкс) без утилит у тебя есть следующее решение - styled jsx - css modules первый подход юзают когда нужно динамически задавать стиль, и это не наш кейс второй подход требует задания класса, выноса этого класса куда-то чтобы ему стиль прописать. Обе эти проблемы весьма ресурсозатратны в плане времени - тебе нужно понять как тебе назвать это дело и где описать. например на главной странице у тебя 3 кнопки так расположены. ты делаешь в index.modules.scss класс типа .btn-wrapper > * + * { margin-top: 15px } и вот такую лапшу ты будешь делать с врапперами сплошь и рядом для похожих кейсов на других страницах. Какой подход с утилитами делал я. Я работаю с SCSS и с его помощью итератором могу сгенерировать от 0 до 100пкс условно утилитарные классы по отступам, гапам и прочей лабуде включая размеры шрифтов например .fs-12px.mt-15px.mt-md-25px При деве сохранение в файле стилей тратит больше времени чем хотелось потому что бандл такой весит порядочно - ведь там тонна стилей (каждый набор утилит перемножен на количество брейкпоинтов для адаптивных утилит(пример bootstrap) При проде юзаю purge.css который должен чистить ненужное. В последней версии tailwind.css они применили новый подход - они не генерируют набор утилит они генерируют только то что ты пишешь. Потому возвращаясь к вопросу вместо создание класса враппера или попытки написать свои утилиты можно просто юзать те что есть у tailwind ТОЛЬКО ПРИ НЕОБХОДИМОСТИ в нашем случае .space-y-[15px] Всё. Я не планировал и не планирую пробовать tailwind концепцию по их основной задумке (utility only) потому как я пробовал собирать сайт на чисто утилитах своего производство и это хоть и кажется удобным сначала - потом создает проблему как раз таки из-за этого галимого ощущения связанных рук. НО. Когда я последние несколько лет юзал МИКС подходов - Bem нотацию для компонентов / верстке секций + утилиты там где нет необходимости создавать именованную сущность - выхлоп получился приятный. Но в своих утилитах есть ряд минусов. Самый важный минус - новый кадр которого наймешь на проект не знает всех их, ему нужно подготовить доку. А у tailwind дока есть, и когда нужно будет применить кастомную утилиту для объединения компонентов на какой-то страничке или быстрой приписке какой-то блока с текстом - это можно будет сделать без проблем. Брейкпоинты можно синхронизировать с теми что у тебя в конфигах SCSS будут, как и цвета если вдруг нужны утилиты цветов будут Собственно о таком виде юза я и хотел узнать от комьюнити - чем плох такой подход?

ну дык в таком случае те же доки и таблицы можно тоже генерировать, подхватывать из комментариев:)

это время и вкусовщина - нужно это поддерживать консистетно на это как правило нет времени когда ты сам себе разраб - это не проблема найти кто уже привык к tailwind классам народ куда проще чем сказать - вот сядь изучи мои..

можно еще выборочно использовать часть их инструментария предварительно это оговорив, новые на проекте просто получают набор pdf, печатают и вешают себе на стену) У меня еще негативный опыт с тайлвинд ибо я его испоьзовал в проекте на пхп, а он сам по себе неплохо так располагает к спагетти. Верстка(классы) в одном месте, стили(описание классов) в другом и никак иначе(или же на сайте будет миллион <style></style> блокирующих рендеринг). Использование tailwind подразумевает что описание представления и там, и там оказывается при дописании своих стилей, а это ад. В случае же с react, vue, angular если использовать inline computer styles никаких проблем тогда быть не должно. У тебя есть один файл - один компонент\атомарный элемент и в этом же файле стили. Тогда все гуд. Почему нет. Тут уже вопрос тогда, что новоприбывший разработчик должен хорошо знать и css и tailwind чтобы не усложнять без необходимости и не плодить именования. Какие-нибудь .h .hidden .not-visible и тд например. Ну и нужно четко очертить границы: вот ЭТО мы решаем с помощью tailwind и допустимы погрешности ввиду градации их таблиц, вот ЭТО пишем сами ибо нужна точность и гибкость. Но вот честно, такой подход подразумевает поддержание tailwind хотя по большей части это недоразумение. Вы и сами сказали, что не хотите писать свои таблицы только потому что не надо учить с нуля и вероятность найти того, кто знает tw больше. Вы сами себя загоняете в капкан и влияете тем самым на комьюнити разработчиков. Одна компания, другая решит так же. Третья. В итоге оказывается то, что посредственный инструмент оказывается раздут и расхайплен на ровном месте просто потому что каждый когда-то пошел по пути наименьшего сопротивления. Потом еще какой-нибудь зеленый стажер придет на какой-нибудь новый ваш проект, где вы откажетесь от tw, а он такой "фиии всмысле у вас нет tailwind, у всех есть tailwind а у вас нет *звуки серпающего через трубочку смузи* ". Дело это уже конечно ваше. А с третьей стороны никто не мешает вам потом написать свои таблицы когда созреете, но при этом используя tw синтаксис чтобы миграция максимально безболезненно и плавно прошла, а те, кто знают tw чувствовали себе в своей тарелке.

проблема не только в том чтобы писать свои наборы утилит - проблема в их расширении, поддержке и адаптации как я уже сказал используемые мною подходы непродуктивны при дев режиме а в прод режиме purge.css требует грамотной обработки чтоб не резалось ненужное (пример тебе сайты на jquery которые добавляют классы в своем коде которых ещё не было нигде в статичной верстке) мне показался tailwind готовой заменой такому подходу с такой же возможностью расширения тупо по месту юза .some-class-[value] можно конечно попробовать такой велик написать у себя - это требует время и сноровки пусть мне моих утилит и было достаточно но когда пришли другие товарищи они как правило либо их не юзают и создают классы в модуле страницы (опять же по причине того что тратить время на регламентирование порога допустимых границ когда легче юзнуть утилиту а когда всё таки класс - проблемная тема) либо дёргают тебя и спрашивают "а нет ли у тебя утилиты которая делают такую-то хрень" ну и утилиты бывают атомарными и молекулярными в отличии от тайлвинда у меня в сборке и те и другие тайлвинд мне показалось интересным заюзать для замены атомарным автогенерируемым. Молекулярные (где участвуют несколько свойств а то и правил) могу писаться дополнительно (по причине реиспользования определенного формата поведения который не привязан к конкретному именованному компоненту но может быть описан каким-то классом)

вот именно поэтому я и решил для себя навсегда, что никогда больше не буду использовать чьи-то стили. Вся работа сводится к следующему 1) Создаешь кнопку 2) Нужно добавить *свойство* 3) Ты такой "так эм а есть ли в tailwind такое правило или тут надо прописать стили самому. 4) Пару секунд тупишь 5) Открываешь tailwind 6) Открываешь их убогие доки 7) Не находишь -> пишешь сам, но время уже потрачено да и и стемпу сбивает, концетрация падает на таких моментах ибо творческий процесс должен оставаться творческим процессом, а не рутиной 8) Находишь -> 9 9) "Так ну такое правило я нашел, но помимо этого я планировал еще добавить к этой же кнопке правило №2, может быть в tailwind есть правило, которое является совокупностью двух первых" 10)Возвращаемся к пункту 4.