Почему Tailwind говно? Объясняю на пальцах | часть вторая
ฝัง
- เผยแพร่เมื่อ 7 ก.พ. 2025
- Почему Tailwind говно? Объясняю на пальцах | часть вторая
первая часть - • Почему Tailwind говно?...
Это одно из видео про Tailwind которое я зыписывал для своих знакомых, что бы показать, почему я не люблю tailwind css.
Не принимайте близко к сердцу. Tailwind это просто технология для программирование интерфейсов, которая служит для определённых задач. Но использовать этот инструмент для больших FrontEnd проектов я бы не стал.
#tailwind #css #html
читая комменты пришел к выводу - насколько обленились разрабы)) Предлагаю все в одном файле писать, ведь это экономит время)
Держи нас в курсе
Чел, методологии не особо нужны, когда есть модули, так как весь твой бэм идет по болту, ведь тебе хочется читаемость, а отдельные файлы - намного лучше, чем один какой-то файл на несколько тысяч строк кода.
автор использует scss, который позволяет также разделять "модули", не делая их на 1000чи строк, чем хзш хвосты модульного ксс упрощают дебагинг? А и как усугубляет читаемость адекватное наименование класса, вот у нас карточка товара, вот картинка карточки товаров?
Проблема css/scss стилей что они будут занимать все больше места в проекте. Поддерживая проект надо будет писать все больше и больше стилей, но в случае с tailwind ты всегда будешь ссылаться на то что уже есть. В долгосроке проект меньше весить будет.
Что касаемо удобства разработки твой пример с гридами хороший, ибо в tailwind гриды реально всратые)
Но ничто не мешает тебе комбинировать его с модулями или создать свой класс tailwind обычным css или из классов tailwind и так же использовать его где угодно в проекте.
Получается и в tailwind ты можешь создать features-workers-list_arcticle, а tailwind встроенные классы использовать для менее сложных стилей.
В данном случае камень в огород tailwind недостаточно обоснован, так что я помогу)
Как в ебаном tailwind прокинуть новые правила через props чтобы они переписали мой ml-[10px], сука, он их как-то расставляет по порядку как ему удобно и мой новый стиль не применяется 🤡🤡🤡
tailwind-merge мне помог
может с восклицательным знаком ... !ml-[20px]
Ну по поводу веса, тут не актуально т.к. сам бандл react весит столько, что пара килобайтосов от tailwind особой погоды не сделает. А про "больше и больше", так в этом наша и работа, писать код. И да, проекты растут... Только вот с tailwind проект будет расти не в длину а в ширину т.к. пишется всё в html разметке. Но в целом, вкусовщина.
вставлять тэг article в тэг section это просто верх. Семантическая верстка передает привет
У тебя даже не по бему написано, ты зачем-то сущность карточки смешал с сущностью списка, сделав огромные классы и убив переиспользуемость карточки вне списка)) Умом взял
длинна класса тебя пугает?
Поддерживаю полностью. Сами в фирме какое то время им пользовались, только проблем больше
Вот вот... дополнительная сложность и запутанность
Попробуй оптимизировать размер проекта, а не смотреть снизу вверх как просто верстальщик. Тогда поймешь почему tailwind хорошее решение
ну тейл экономит пару килобайт. учитывая что многие даже картинки не оптимизируют, то экономии совершенно нет.
в чем проблема написать:
@layer components
.featured-works-list__article {
@apply grid gap-[20px] и тд....;
}
и использовать на диве уже свой именнованый класс, в плоть до БЭМ
Тогда опять же, зачем тейлвинд?
а вы не чувствуете, что когда вы пишете такой код, вы мягко говоря используете препроцессор с нескучным синтаксисом, который дебажить чисто из-за нейминга тяжелее, связанного с процессом интерпретации инструкций ветерка в ксс.
просто тоже самое, что вы написали, на условном сасе бы выглядело так не требовало никакой когнитивной нагрузки для понимания, а что, а как понять.
.featured-works-list__article
display: grid
....
без условия того, что вам ничто не мешает написать миксинов, которые бы эмулировали ваш grid gap-[20px] и тд
Да и не только гридами, флексами норм адаптив делается, и да - с БЭМом норм, но опять таки зачем, если можно теми же модулями CSS ? И надо париться с названиями классов, и в HTML нет нагромождений символов.
Я не люблю верстать, я больше за разработку, и мне было бы сложно писать css в каждом отдельном файле (модули). Мне намного удобнее подход tailwind, если бы еще у него определялись стили поочереди то я бы максимально был доволен
Не слушай этого умника, весь мир использует tailwind. Хотя бы потому что это быстрее намного. Есть плагины которые убирают минусы tailwind, это куча классов, устанавливаешь плагин в vscode и className='flex flec-col и так далее' превращается в className='...' И есть плагин для определения порядка классов
Ну писать стили это оснавная работа фронта)
основная работа фрона это писать бизнес логику @@oshurek-dev
Не согласен. Тайлвинд помогает в больших проектах, где у тебя есть набор отступов допустим, и ты их везде используешь. Так у тебя получается быстрее в разы писать, ты редко заходишь в css файл и вся верстка единообразная получается. Потом когда тебе по всему проекту надо сменить цвет кнопок или отступы. Просто заходишь в настройки и меняешь один параметр.
Да, в целом, я согласен с этим. Но это делается в CSS точно так же просто. А проблема переключиться в css файл, думаю это смешно ))) Думаю вы понимаете, что я по. факту рофлю и просто высказываю именно своё мнение по этому поводу.
чувак ты живвешь в прошлом. ужасно примитивный код... ниодного компонента ниодного модуля ни-че-го. так еще и бэм используешь... типичный реакт верстальщик который поясняет за то что не шарит, сори что так токсично просто ты реально слабый
эммм.... при чём тут модуль или компонент?
вот посмотрел ролик (сам таилвинд не использую), но так и не понял почему таилвинд говно? ты же не назвал ни единого его минуса, а только плюсы подхода css
минусы это засорение разметки, подключение ещё одной библиотеки, увеличение сложности проекта, неудобство рефакторинга и тд. В целом, посыл такой - зачем оно нужно? Какую проблему оно решает?
@@oshurek-dev тайлвинд - это атомик css. это просто другой подход, он не обязательно должен решать какую то проблему. если оно вам не нравится, это не значит, что оно говно)) с ним заметно поднимается скорость написания стилей, но конечно нужно уметь это все дело варить
@@d4rkdante >он не обязательно должен решать какую то проблему
на этом можно было закончить)
@@xyozy8 можно было)) но автор снял абсолютно бессмысленное видео
@@oshurek-dev "засорение разметки" - ну если ты чисто верстать собрался, а не использовать любой JS фреймворк, то конечно да, засоряет. Но кто делает чистую верстку в 2024 году?))
"подключение ещё одной библиотеки" - что блять...
"увеличение сложности проекта" - что блять... (х2)
"неудобство рефакторинга" - если пишешь на фреймворке, то абсолютно нет.
Теперь к вопросам.
"зачем оно нужно" - для увеличения скорости разработки, для легкого онбординга новых членов команды разработки. Человек знающий tailwind не будет думать над проблемой стилей и существующего нейминга при знакомстве с новым проектом, а будет занят непосредственно разработкой.
"Какую проблему оно решает" - убирает проблему абсолютно ненужного нейминга в стилях. Всё это дрочево с БЭМами, хуемами, понапридумывают 100500 методологий, что бы млять просто стили написать, это же кринж полный.
вообще не догоняю его смысла. весь хтмл в строках не читабельных. а если это реакт. то там и так эти пропсы делают сложным для понимания че куда. а если туда и добавить 20 слов стилей это вообще месиво из букв. + уже на след день код не маштабируемый и нихирища не понятный. меня когда то пацан попросил помочь, сделать модалку. Кинул свой мини кофейный магазин. Там на 90 строк хтмл было 8к строк стилей. я может и не експерт в быстродействии. но я почти уверен что комп быстрее прочитает 500 строк чем 8к... + будет их постоянно переопределять... + класик проблема когда все у всех отлично. а на каком то айфоне криво. Как вообще это адаптировать...
Сначала тоже не догонял это месив, но когда на вью или реакт приходилось переключаться постоянно в файл стилей и обратно в верстку , то этот момент парил. А так захерачил стиль в тег и никуда лезть искать не приходится. Ну а дальше читаемость уже дело привычки. Быстрее верстается на тайлвинде
@@zergzerg4844 такой вопрос, а зачем лазить туда сюда, разве не логичнее сначала реализовать логику на компонента на реакте, а уже после играться с отображением?
@@daiske2867 Ну каждый по своему делает. Мне сначала привычнее сверстать макет со статичными данными а после уже браться за реализацию динамики и логики. Глазу приятнее работать с красивым компонентом
@@zergzerg4844 так, а разве в этом случае так принципиально смешивать логику, то, как вы описываете можно и отдельным кссом делать, просто добавить себе эмет подобные автодополнения, для этого не нужно плодить дев зависимость с неоптимизированной портянкой.