Comments 34
Но ведь CSS tailwind'а уже распух описанием все возможных комбинаций
Немного не понял претензии, ну есть и есть, для девелопмент среды не страшно скачать, они же удаляются в продакшен билде, гуглить purge unused css tailwind
я также думал, но посмотрел css бандл сайта (скрины в статье), там описаны все возможные комбинации
Так лучше Tailwind JIT погуглить. Он давно уже из коробки только используемые классы добавляет. Как по мне, Tailwind проще классического CSS (назовем это так) для простых "вещей" и сложней для сложных. В основном, все пишут простые "вещи", от туда и его популярность.
Это просто ложь, даже webpack соберет стили индивидуально для каждого компонента, добавив уникальный аттрибут (
<style scoped>).
Это ведь специфично только для Vue
я давно не писал на react, но уверен, там тоже не глобальные css
А я не уверен)
Там тоже не глобальные CS, если нужно :-)
благодаря какому инструменту?
Да там невменяемо длинный список, на самом деле. Чаще чем кастомные CSS модули только JS упаковщики пишут.
css modules не привязаны к библиотеке
всегда было видеть забавным эти попытки переизобрести css, все пытаются пихать в шаблон/html или в сам js, лишь бы не писать стили как стили отдельно. Стильно модно молодежно и нитакиекаквсе?
angular fxlayout, styled components, tailwind. Вот в чем польза, брат? Почему нельзя по православному писать стили как стили?
Ну хочется написать, а почему бы и нет...
Удобно, быстро, прогрессивно..
Но по вашей логике, HTML это HTML и зачем его писать в JS файлах реакта ? Давайте православно и дальше писать в *.html
Для меня, TW, это просто способ быстро накидывать стили , не углубляясь в изучение CSS и фронта.
в реакте нет html как такого. Но я бы только за чтобы выносили его в отдельные файлы, но дизайном библиотеки непредусмотрено, к сожалению
это выглядит круто только в демо или быстро что-то накидать абы работало
а при плотной разработке это сплошной ад, где те же самые стили пишутся классами (один стиль - один класс в большинстве случаев) или директивами (fx layout чтоб его). Тоже самое можно и атрибуте style писать. Разделения обязанностей? что-то на бумерском
а потом после таких прогрессивных поддерживай проекты
всё правильно говорите, JSX это ужасно ?
вот этим мне нравится angular
Возможно, но, во-первых, осмысленные имена классов дробят полотно разметки на блоки и элементы
Придумывать и переименовывать осмысленные блоки очень трудозатратно во время активной разработки. Иногда нужно добавить один или два лишних wrapper'а, которые полностью меняют структуру и добавляют классы уровня .element-wrapper-wrapper (я утрирую, но идея примерно та же)
Но ведь CSS tailwind'а уже распух описанием все возможных комбинаций
Все неиспользующиеся классы tailwind'а вырезаются во время сборки, поэтому размер итогового css не такой уж и большой (уж точно меньше кода с sass, где на каждый класс вешают миксин)
tailwind подход выглядит как шаг назад, (привет, аттрибут style!)
так может показаться, но у utility-first подхода есть плюсы перед обычным запихиванием стилей в style:
utility-first предоставляет классы, специфичность которых меньше чем правил внутри style (переопределение обычными классами, без !important)
build-step для минификации и анализа всего что используется в приложении
кастомизация (можно переопределять различные отступы, цвета, тени и т.д.)
проще переиспользование кода (не нужно делать сборку или css-in-js, все стили помещаются в render функцию или в template)
Безусловно tailwind это не таблетка от всех болезней, но это хороший инструмент и отличный представитель utility-first подхода. Все еще есть вопросы с переопределением классов одной группы на элементе, многословность при создании интерактивных элементов, сложности с переиспользванием кода в дизайн системе. Но примерно тот же набор болячек есть и у других фреймворков, но к этому добавляется еще больший размер и меньшая скорость разработки
В $mol_style таких проблем нет. Все селекторы имеют одинаковую специфичность, наследуются, легко переопределяются, проверяются тайпскриптом, семантически осмысленны и глобально уникальны.
Не думаю что сравнивать набор css классов и библиотеку для фреймворка корректно, но:
Все селекторы имеют одинаковую специфичность
как и в tailwind, но все еще остается проблема с порядком селекторов с одинаковой специфичностью
наследуются
как и в обычном css
семантически осмысленны и глобально уникальны
не думаю что можно применять понятие "семантика" к utility-first библиотекам, но уникальность также присутствует
Вы сами заговорили про фреймворки. Тем не менее сравнивать подходы вполне корректно.
В $mol_style проблем с порядком никаких нет - сборщик выстраивает всё в правильном порядке.
Обычный css ничего не знает про компоненты и, соответственно, про их наследование.
$mol_style, очевидно, не utility-first, а semantic-first.
Был солидарен с автором и задавал те же вопросы, пока не выяснил, что при сборке таки можно группировать все эти 100500 классов у блока в один и удалять неиспользуемые
Соглашусь с автором, особенно с первым пунктом.
Недавно нужно было срочно пофиксить сайт на Tailwind. Я обычно не занимаюсь этими вещами, но тут нужный человек отсутствовал. И получилось что задача которая с обычным CSS занимала бы максимум 5 минут, здесь заняла почти два часа.
Под "обычным css" я имею ввиду Bootstrap, MUI и пр. которые построены в декларативном стиле. В этом случае достаточно пометить "это панель", а "это навигация" и дальше все работает, применяя внешний вид который прописан отдельно и для всего приложения вцелом. В случае Tailwind так не получилось, и пришлось индивидуально прописывать как должен блок выглядеть.
Мне кажется удобней указывать "что это" (bootstrap, etc), а не "как это выглядит" (tailwind). Потому что первое лучше вписывается в модель HTML и CSS. Второе может быть удобней для дизайнера который каждый элемент прорисовывает индивидуально. Но я не представляю как поддерживать какой-то большой сайт с таким подходом.
Поправьте меня если я что-то не так понял в Tailwind.
Поддержку. Как можно ориентироваться в этом нагромождении классов? Это я ещё тут добавил всякие event-block, event-picture, чтобы хоть как-то находить в коде элементы, которые нашёл в инспекторе. Без этого получается просто набор div и span, которые слабо отличимы друг от друга. Ещё и визуально смотрится как мусор. Это всё равносильно тому, чтобы писать style="" в каждый тег. Есть список, где каждому li внутри ul нужно сделать отступ и бордюр — будь добр указать это индивидуально каждому из этих li.
Hidden text
Что касается «чистоты сборки» и малого размера конечного css файла «из-за только используемых классов» — ну так это преимущество только перед другими фреймворками.
Наверное, будет корректно и все другие плюсы и минусы тоже обсуждать только в сравнении с другими условно «бутстрапами».
Однако все это справедливо только для нормлаьного верстальщика, и это чисто мое личное мнение.
И если волею судьбы доведется работать с TW, то ничего страшного в этом нет. Ну в тренде сейчас TW, и многие очень даже не маленькие проекты на нем пишут. Раз платят за него, вакансии есть, значит имеет право жить.
Tailwind это штука, которая позволяет программисту почувствовать себя дизайнером: "смотри, бро, я тут прямо в коде делаю кнопку фиолетовой, скругленной и большой, круто, бро?"
И, соответственно, смешать код и дизайн, логику и представление. Потом это так весело расхлёбывать! И так каждый раз, от inline-стилей в HTML до Emotion/Styled Components в Реакте.
Сколько раз твердили миру "не смешивать", столько раз находились Бонды, которые и смешают, и взболтают, и похмельем потом страдают.
Автор прохо читал доку TW.
Мало того, что можно выкидывать не нужное. А по хорошему TW это средство разработки а не продакшена. Я лично финалю все tw наборы классов в input.css через apply
Всмысле из чего-то подобного
<div class="mt-4 p-8 bg-black text-white">Можно сделать
<div class="some-class">.some-class{
@apply mt-4 p-8 bg-black text-white
}
Пробовали на проекте с хорошим, нешаблонным дизайном, с кучей нюансов и брейкпоинтов, и сразу отказались, т.к. даже банальный инпут вырос в большое полотно даже черeз \@apply. Но для пет-проекта без дизайна оказалось вполне удобной штукой.
Всё же набросать пару классов и стилей на компонент мне кажется более масштабируемым и простым в поддержке решением.
Взять Tailwind CSS было самым лучшим архитектурным решением для большого SPA проекта и команды из 15 фронтенд разработчиков.
Писать код удобно и быстро потому что все в одном месте и стили и разметка
Поддерживать и рефакторить удобно потому что уверен что ничего не сломаешь в неизвестном месте
Легко менять внешний вид всего сайта, достаточно настроить конфиг
Приложение грузится быстрее за счет уменьшения размера бандлов
По настоящему классных верстальщиков мало среди фронтэндщиков а Tailwind упрощает написание стилей и стандартизирует все отступы цвета радиус закругления итп
Так воон в чём дкло изначально. Просто мало классных раблтников, а те, которые есть, делают не очень хорошо и могут наменять то, что не следовало. Это, наверное, те люди, которые сами выбирают SASS, а потом не могут уследить за отступами.
Стало понятнее, спасибо.
А на счёт того, что всё в одном месте — если редактор на две части разделить, то тоже всё будет на одном экране. А если с девтулзом хорошо подружиться, то совсем комфортно будет.
во-первых, осмысленные имена классов дробят полотно разметки на блоки и элементы
Это про БЭМ, вообще-то. У БЭМ с одной стороны и Bootstrap + Tailwind с другой разные цели. Бутстрап с Тейлвиндом правда очень похожи на style внутри тегов в том смысле, что позволяют, скажем, фрилансеру одиночке быстро что-нибудь накидать прямо так на странице. Без предварительной фигмы (ибо фрилансер наш - не дизайнер, а кодер). При этом в отличие от style готовые классы бутстрапа с тейлвиндом отлаживаются соответствующими командами для, например, поддержки различных браузеров. О кастомных классах и, тем более, style прямо в вёрстке, надо заботиться лично вам.
Если коротко, статья получилась о том, зачем нужна эта каша быстрого приготовления. Нормальные люди же варят нормальные крупы нормальным образом. Ну... да. А почему кашу быстрого приготовления рекламируют так активно - как раз поэтому. Потому что если задуматься, есть куча грамотных аргументов против. Но они для эстетов.
Кто-нибудь, объясните мне прелесть tailwind