Comments 106
Я смотрю, на фронте уже лет 20 ничего не меняется: по-прежнему примерно раз года в 3 происходит смена значительной части всех инструментов и библиотек, с выходом подобных статей.
Так-то Tailwind вышел 6 лет назад (а концепция Atomic CSS была ещё раньше), Redux Toolkit (тогда Redux Starter Kit) зарелизился тоже почти 6 лет назад, а Vite — 5 лет назад. Да и с выходом этой статьи «революция» не произошла: зумеры уже давно на подобный стек перешли, а серьёзным проектам некогда и незачем.
хотели сказать бумеры. Зумеры как раз пишут такие статьи
В этом и проблема, что "серьёзные проекты" держатся за счёт "скуфов", которые до сих пор пишут на BEM и создают гига-тонны CSS-файлов и считают это нормой))
Если проекту нужны гигатонны CSS-файлов, то в переложении на Tailwind в нём будут тератонны стилевых строк. Элементам же всё равно нужны стили. Только на BEM или CSS Modules это будет отдельный файл с именованными стилями, а в Tailwind — те же самые стили, только заинлайненные в сам компонент. Однако пропадает семантика стилей, самодокументируемость и увеличивается риск дублирования реализации.
Да, забавно, как в мире моды- что у нас в тренде в этом сезоне?)
Лично мне tailwind мешает понимать задумку верстальщика. Имя класса image-wrapper я пойму, а не пойму какой-нибудь grid align-center radius-30 border-4 border-red m-75 lg:justify-between lg:m-64 lg:bg-blue-100 lg:font-small md:m-80 md:radius-20 sm:radius-10 sm:alig-left sm:m-40 xs:m-20 xs:border-2. И такое в каждой из 200 строк, кроме закрывающих тегов. Удачи в добавлении ссылки в нужное место с первого раза.
Новое, это хорошо забытое старое. Когда-то когда html был юн, стилей было мало и их добавляли к каждому элементу, но не классами, а аттрибутом style, что там долавлять-то, отступы, толщинцу рамки, цвет текста и цвет фона.
Потом поняли, что переиспользование стилей это хорошо и даже замечательно: один раз класс кнопки с нужным стилем сделал и используй на всех кнопках, да и стилей становилось все больше и больше.
Теперь ньюфаги решили изобрести то, как было на заре веба, забив на переиспользование.
Теперь ньюфаги решили изобрести то, как было на заре веба, забив на переиспользование.
Я и сам люблю пошутить над "фронтендеры опять изобрели колесо", но в реальности всё не так однозначно. Совсем идиоты новых успешных продуктов для разработчиков не создают. И у них есть целая страница с аргументацией их точки зрения (однако совет по использования мультикурсора - это, конечно, лол).
А в чём преждевременность абстракции, если обычно проект верстается по готовым макетам, то есть проблема декомпозиции и унификации уже по большей части решена дизайнером?
Я могу только понять использование Tailwind, когда верстальщик сам является дизайнером и «дизайнит» на лету во время вёрстки страницы. Только кажется, что этот процесс больше подходит «одноразовым» страницам типа лендингов или индусам-фрилансерам, которые подписались на работу по дизайну-вёрстке за фиксированную оплату.
Css модули придумали для jquery, когда не было компонент. Сейчас переиспользуемость происходит на другом уровне.
На самом деле ничего сложного в этом нет, если верстальщик не отдал портянку на 300 строк html кода в инлайн режиме.
Потому что у тебя, обычно, есть компонент, который содержит другие компоненты. И если ты видишь название Paper или ImageWrapper то понимаешь что там происходит. Я не очень люблю TailwindCSS. Но часто проблема не в нем. Я точно также видел проекты на пару сотен строк html разметки с одиночными классами и точно также приходилось задаваться вопросом this is чзх? потому что горе верстала добавил классы body, container, wrapper и они все нужны, просто ему не хватило абстракции как-то это по другому обозвать.
Имхо, самая большая проблема в отладки TailwindCSS с которой я сталкивался против css moduls это невозможность настроить через класс определить что за компонент и приходится лезть в тулзы, вместо базового древа в консоли. Т.е. прямо скажем, мелочь.
Вроде бы там через конфиги можно создавать метаклассы по одному имени включающие наследующие целый список встроенных классов. Об этом как то мельком упомянуто пока сам не разбирался. Это был бы оптимальный подход.
То есть без классов всё-таки никуда, и пришлось придумать их заново?
Об этом как то мельком упомянуто
Где упомянуто? Я не смог даже нагуглить.
https://tailwindcss.com/docs/functions-and-directives#apply-directive
Может быть, вот такое?
Сторонники тейлвинда всегда упоминают эту возможность. Но я так и не понял, в чём отличие от просто классов.
TailwindCSS предлагает верстать не сущностными именами классов, а чисто утилитарными. Вместо h1, h2, у тебя span'ы с мусорными классами. Ну это же моветон. Быстро наговнокодить — это же не подход. Это же write-only, это невозможно нормально поддерживать и развивать.
Будем честны, "быстро наговнокодить" можно и без tailwind'а.
Этот термин вообще, скорее, не про инструмент, а про человека.
Не во всем согласен. Это опять зависит от разработчика. H1,h2 заголовки, а tailwind дает просто размеры шрифтов. Все, что крупное не всегда заголовок и т.д. Возможно этот пример просто неудачный.
Tailwind при правильном подходе позволяет верстать и тестировать быстрее и не в ущерб качеству. Это вопрос стиля и подхода к дизайну и верстке, и не про supertool. Dark styles решаются быстрее «условными классами» и многие другие вещи. Я комбинирую tailwind с обычными классами и пока все очень предсказуемо, изменяемо и расширяемо.
html4 -> html5 -> html4
пардонте. При всей не любви к TailwindCSS, чисто эстетической, надо сказать, но пример выше это не проблем TailwindCSS. Вы также можете добавить класс heading-l1 или любой другой и вкорячить его хоть в кнопку.
Надо понимать, что одно дело — страница для очередного стартапа из тех, которые закрываются раньше, чем о них успеет написать Слава Рюмин. Для них говнокод это нормально. Давайте, бахайте оформление тейлвиндом и т.д. За соответствующий гонорар. А ещё лучше не мудрите, а берите готовую страницу за доллар с yourfreewebtemplatenew2025.com.
И совсем другое — UI, с которым будут работать сотни тысяч юзеров или больше. Там требования к качеству совсем другие. Я лично пришёл к тому, что вообще любая утилита — это плохо, это очень плохо. Маркируйте разметку строго семантически, а обобщения реализуйте через миксины, а не утилиты. Будет чистый и понятный код без проблем в виде DRY violations и прочего шит-кода.
И поверьте, CSS вынесли в отдельный DSL и отдельные файлы не дураки. Вы бы пописали код в доисторическую эпоху с атрибутами color или width, сразу бы поняли, от чего мы ушли, и к чему тащат нас зумеры со своими тайлвиндами.
Если мы говорим про гигантский проектище с миллионами строк кода, то даже там сложно выйти за пределы DRY.
Tailwind предоставляет apply, который как раз помогает этого избежать доступным образом.
А CSS и его препроцессоры — нет, увы. Всё равно будет лишний CSS и переиспользование.
Мысль неясна. Если мы можем создать свой класс в тейлвинде через apply, то чем это принципиально отличается от написания того же самого CSS руками или с помощью препроцессоров (которые просто делают рутинную работу)?
Что делать с тремя-четырьмя уровнями вложенности миксинов? Копипастить их в разметку в виде имён классов? Это, по-вашему, «переиспользование»? И что делать, когда иерархия наследования изменится? Бегать по тегам и менять в сотнях мест?
Именно так и нарушается DRY при использовании утилит (а Тейлвинд это утилитинг в чистом виде). А сколько там строк, это не важно. Я, кстати, в несколько тысяч не минифицированных строк CSS укладываюсь всегда, даже для сложных проектов.
Tailwind предоставляет apply, который как раз помогает этого избежать доступным образом.
Только вот беда, сами авторы TW назвают apply антипаттерном и призывают использовать пореже. И в целом понятно почему - это по сути ломает основную концепцию и убивает декларируемые преимущества. И становится еще более непонятно, зачем это всё нужно.
И особенно это интересно в свете популярности DaisyUI (в State of CSS 2024 пусть не в самом топе, но заметное распространение), где слом основной идеи TW преподносится как преимущество.
Сообщество TW колбасит, оно само не может решить, как лучше и почему.
Очень советую почитать про $mol
Очень много годных решений там уже сделаны
Ну, кстати, да, статически типизированные каскадные стили, стейт менеджмент, кастомизируемость компонент и zero-config окружение разработчика там просто офигенные.
Просто в отрасль хлынул огромный поток мимокрокодилов. CSS они не знают (ну иъ наверное сразу ввели в курс дела - что CSS это фигня и вообще не ЯП и даже внимания вашего не стоит), вот до сих пор и обмазываются всяким непотребством... Ещё и других призывают))
Не только в этом дело. Точнее, мимо крокодилы в отрасли - да, но не как раньше.
Дело ещё в LLM.
По какой-то причине LLM обожают Tailwind и "предпочитают" делать код на нем.
Claude вообще использует Tailwind по-умолчанию. Иной раз, даже когда указан стек пакетов, например, Mantine или чистый HTML/CSS, он все равно тащит Tailwind. Нужно добавлять в промт отдельное предложение "НЕ ИСПОЛЬЗУЙ TAILWIND".
Остальные LLM тоже предпочитают Tailwind, хоть и не так фанатично.
Вы можете трактовать это любым удобным вам способом))
Напротив, я знаю, что такое Legacy-код и CSS, особенно с древних Wordpress + JQuery сайтов.
И, когда я перешёл на Tailwind, это было облегчением и переломным моментом))
Ну, а свою "неспособность следить и подхватывать тренды" не нужно как-то трактовать иначе, тем более винить в этом третьего))
То есть этап CSS Modules вы явно пропустили?
Напротив, я знаю, что такое Legacy-код и CSS, особенно с древних Wordpress + JQuery сайтов.
Ну т.е. что такое нормальный CSS - вы не знаете? Причём здесь jQuery вообще? А вот Wordpress да - в нём бывает очень непросто разобраться со стилями. Но причём здесь CSS?
И, когда я перешёл на Tailwind, это было облегчением и переломным моментом))
Ну кто бы сомневался. Человек только вчера Хабр для себя открыл, а сегодня уже учит вёрстке остальных ленивцев))
Ну, а свою "неспособность следить и подхватывать тренды"
Немного не так! Не стоит свою способность "тыкать пальцем в небо" выдавать за вменяемый аргумент. А так же не стоит свою неспособность разобраться в изначальной технологии выдавать за "готовность и открытость ко всему новому" ;)
"Способность следить и подхватывать тренды" - это вообще что такое? Почему эти тренды надо подхватывать вдруг?
Я постоянно плевался от Бутстрапа, но Tailwind - это же просто за гранью добра и зла:
<button class="btn btn-primary">Click me</button>
<button class="bg-blue-500 hover:bg-blue-600 text-white font-bold py-2 px-4 rounded">
Click me
</button>Такие как вы вообще не понимают как работает CSS! Ну вы же не знаете, например, что такое "каскад", правда? Иначе бы вы не несли такую чушь!
Вот за такими "трендолюбцами" постоянно приходится переписывать с матюками...
P.S. Если вдруг вас заденет такой стиль общения - задайте себе вопрос: а стоит ли в дискуссии переходить на личности, не аукнется ли мне это?
От проекта зависит. Если на вас давят сверху и подгоняют - вы будете использовать любые инструменты что бы уложиться в дедлайн. В таком случае лучше разработать что бы работало, чем быть уволенным и писать великолепно оптимизированные pet проекты дома. Большинству проектов не нужны уникальные стили, нужно просто получить данные из БД, обработать и записать обратно. Если проект супер уникальный, у вас много свободного времени и бюджета, то можно разработать свои CSS классы, но большинство заказчиков не готовы за это платить, особенно если вы берете с них $100 в час :D
Что значит "разработать свои CSS классы"? Как их разрабатывают-то? Вы думаете кто-то сидит и сочиняет тэйлвиндовские портянки с классами на каждый чих?
Кстати если бы я платил за вёрстку 100$ в час, я бы требовал чистоты кода и, соответственно, отличной системы классов. А с какой стати платить столько говнокодеру?
Tailwind и Shadcn удобны только вайбкоддерам - им проще скинуть промптом сразу весь компонент) а в плане оптимизации и работы - очень своебразно, нередко дом-дерево на ТВинд вложеннее, чем нужно обычно
RTK, упомянутый в тексте, неплох, но тогда уж Tanstack тоже стоит упомянуть, не все хотят тянуть куски редакса в проект, и ТСтэк более агностичен в этом плане, и вроде как посвежее
Vite появился давно, из свежего теперь RSpack, Turbopack и прочий раст походу) пока писалась статья - на фронтенде, как обычно, всё пытается устареть)
Vite под капотом использует esbuild и rollup, а rollup в свою очередь использует модный бандлер SWC как раз на Rust.
Помомо Tanstack есть ещё и SWR от vercel, с размером пакета поменьше и схожей функциональностью
Согласен, я хотел упомянуть TanStack. НО.
В данном посте я ещё сравниваю RTK с Axios, а Tanstack использует axios, поэтому счёл нецелесообразным. Но спасибо за замечение. Обязательно сделаю еще статью про Tanstack.
Vite вот-вот перекатится на rolldown, который тоже раст.
Вредные советы фронтендеру от Григория Остера
Tailwind легко можно назвать «смертью ручного CSS», и не зря: если присмотреться к современным проектам, начиная от пет‑проектов разработчиков из Индии на видео‑площадках, и, заканчивая новейшими IT‑решениями, почти все они используют Tailwind и охотно советуют им пользоваться.
shadcn/ui решает эту проблему элегантно — просто копируешь компонент в свой проект и меняешь как угодно, ведь под капотом у него Tailwind.
Copy/Paste Driven Development? Успехов вам с накатыванием обновлений.
shadcn/ui — это чистые React‑компоненты без рантайм‑стилей, которые дают быстрый SSR, меньше ререндеров и отсутствие тяжёлых стилей в js.
Раздутый раз в 10 HTML, и полный ререндер при изменении темы, лейаута и тд.
Раздутый раз в 10 HTML, и полный ререндер при изменении темы, лейаута и тд.
Пруф + аналог, у которого этого нет
Copy/Paste Driven Development? Успехов вам с накатыванием обновлений.
По-моему, слишком очевидно, что речь здесь идет про установку самостоятельных компонентов UI в проект и минимизацию бандла, без речи про обновления и тому подобное. Да и причем тут вообще обновления, если мы говорим об использовании готовых UI? По этой логике, всё, что не Golang (где есть пометка о жёстких-нежёстких версиях в .mod файлах, ломающих проект при обновлении) — фигня.
Я так понимаю, твой комментарий нацелен на пиар YouTube-канала)) Ну что ж, я и не против, собственно))
Я считаю, что css/scss никто не уничтожил. Всё еще проще и удобней прописывать те же ui компоненты, через них, когда у тебя 4+ варианта кнопок, к примеру. И всё еще зависит от типа проекта, если у вас стартап и вы постоянно проверяете гипотезы, то конечно будет удобней взять tailwind в руки и начать пилить фичи, нежели раскидывать всё по отдельным файлам.
Все препроцессоры это прошлый век. Особенно BEM-методология и css-модули.
Все современные инструменты решают абсолютно все проблемы, которые решали они ранее. Я думаю, есть только одна причина, почему кто-то использует SCSS или CSS-модули — они просто не хотят пробовать ничего нового и работают "по старинке".
Только у Tailwind под капотом тоже препроцессоры для генерации цветовых, размерных и прочих наборов стилей, до кучи и PurgeCSS для вырезания всего лишнего мусора.
Tailwind мне приглянулся из за DaisyUI а также тем что у него есть standalone версия, не требующая установки достаточно ужасного менеджера модулей npm.
Но тогда и минифицировать стили некому будет
Вроде ж npm ставится вместе с нодой, а без этого нет никакой сборки и никакого современного фронтенда с dev-сервером, HMR и прочим.
Использую либо preact+htm и es6 модули, встроенные в браузер или Deno. Очень не люблю node / npm и сборщики и очень печально что они получили массовое распространение. Когда-то во времена IE11 они может и были оправданы, однако явно не сейчас. Недостатки перевешивают достоинства. Небольшое уменьшение bundle а взамен ужасное монстрище на npm, требующее отдельного шага сборки.
Я сам когда-то пришёл в web, потому что он работает на каждом компьютере, где есть блокнот и браузер, но потом в PHP появился composer (я его пропустил, ни разу не пользовался), а в фронтенде появились grunt/gulp со всякими LESS и autoprefixer. Ну, вот так оно всё устроено.
Я сейчас постигаю обновлённый Nuxt, четыре года на нём не писал, но и тогда не был экспертом. Нахожу для себя много всякой приятной магии, вроде автоимпорта компонентов. Я не против запускать ради этого yarn dev/build. А как вспомню, что после каждого изменения файла со стилями нужно было нажимать F5 и ждать загрузки, то "аж трисёт".
Просто те, кто пишут, используя БЭМ и SCSS, умеют грамотно разделять стили и не лепить один и тот же класс в разные места приложения. Легаси, в котором ломаются зависимые стили? А вы попробуйте пофиксить что-то в легаси проекте, использующем Tailwind! Там бывает такая ситуация, когда абсолютно одинаковая километровая лапша стилей приписана разным элементам в разных компонентах, и тупо невозможно найти элемент, который требуется изменить.
Я знаю, о чем говорю, я был и на легаси проектах, и на Tailwind (сейчас), и я все еще ненавижу Tailwind
абсолютно одинаковая километровая лапша стилей приписана разным элементам в разных компонентах
А в 101-м месте такая же, но чуть-чуть другая. Удачи разобраться так это и задумано, или забыли когда-то раньше поправить, или сломали случайно :)
А затем приходят дизайнеры и говорят, что надо цветовую схему поменять :)
Заводишь цветовые элементы в variables, и просто меняешь по требованию - вы великолепны!
Это если подумал заранее и создал семантическую палитру. Но у фаната тейлвинда весь код состоит из text-gray-100 bg-blue-800 чуть менее, чем полностью, ведь семантика не нужна :)
Ну потому что ключевое слово тут подумал) а обычно рот открыл, слюна побежала, "как стилизовать теги", кмд с кмд в
Эту проблему решили бы метаклассы, определяемые из встроенных. Надо бы это посмотреть. Хотя еще наверное это решаемо через custom web elements.
Как тут custom elements и метаклассы помогут? Вы суть проблемы-то поняли?
Понял. Надо длинную строку
<button type="button" class="text-white bg-blue-700 hover:bg-blue-800 focus:ring-4 focus:ring-blue-300 font-medium rounded-lg text-sm px-5 py-2.5 me-2 mb-2 dark:bg-blue-600 dark:hover:bg-blue-700 focus:outline-none dark:focus:ring-blue-800">Default</button>
Переопределить в метакласс <button class="my-button">Default</button>, наследующий весь этот список классов:
.my-button { @extend .ext-white .bg-blue-700 .hover:bg-blue-800 .focus:ring-4 .focus:ring-blue-300 .font-medium .rounded-lg .text-sm .px-5 .py-2.5 .me-2 .mb-2 .dark:bg-blue-600 .dark:hover:bg-blue-700 .focus:outline-none .dark:focus:ring-blue-800; }
В какой версии Tailwind у вас есть @extend?
И уж лучше чистый CSS или SCSS, чем такой кадавр.
Даст вам чистый CSS такие компоненты?
https://daisyui.com/components/
Не в какой. Думаю надо попробовать сделать custom elements, определяющие такие классы автоматически.
Это не нежелание пробовать что-то новое. Eсть разные инструменты для разных задач, если нужно быстро что-то сверстать это правда, что tailwind незаменим, хотя все еще с интересом наблюдаю как люди прописывают кастомные свойства и тд. Та же группировка состояний чего стоит. Качественно разбитые файлы стилей позволяют разделить восприятие. Чтобы у тебя компонент не превращался в кашу из стилей, особенно если он кардинально меняется на active стейте.
Все препроцессоры это прошлый век. Особенно BEM-методология и css-модули
CSS Modules наоборот убили BEM, да и инструменты типа SCSS абсолютно не обязательно использовать с CSS Modules, тем более в 2025. Для многих проектов достаточно чистого CSS, а скоро ещё и функции добавят.
И как же "современный" tailwind решает проблему кастомизации компонента вложенного в другой из третьего?
Tailwind легко можно назвать «смертью ручного CSS»
Очень смешно. Tailwind легко можно назвать позорной попыткой заменить CSS. Tailwind это жесточайший говнокод, причем это настолько очевидно, что только слепой не замечает.
Это просто одна сплошная уродливая помойка. Видимо разработка совсем загнулась и уровень разработчиков достиг исторического минимума и пробил дно, потому что есть те, кто считает что это круто.
RTK Query принес конец эре ручного управления данными, как, например, Redux Thunk/Saga/Axios. Именно их мы и сравним.
Откройте глаза, MobX существует 10 лет. Redux и вся что около и вокруг него, в том числе RTK Query это так же шлак, который провоцирует писать говнокод и уничтожать проект.
P.S. при использовании CSS modules, никакого БЭМ нет даже в намеках, он автоматически генерируется на выходе.
import styles from './styles.module.scss';
//...
const Test = () => {
return <div className={styles.wrap}>test</div>
}превращается в src-layouts-main-___styles-module__wrap___dazN7
Вот и все дела. И никаких конфликтов стилей и т.п. при таком подходе быть не может, в каждом компоненте будет класс .wrap / .title и т.п., и конфликт исключен. А удобство написания стилей у SCSS + CSS modules возведено в абсолют.
Вы опять выдираете пример, где все плохо. Так можно с любым языков/фреймворком. Я могу взять, скажем, Notion и показать, как там все плохо с повсеместным использованием inline стайлов. Скажет ли это что-то - нет?
Можно показать реакт-пример где куча сгенерированных стилей и все выглядит как говно, что опять бессмысленно. Вам просто нравится эта технология, но она точно такая же как и tailwind. У каждого свои сильные стороны и слабые. Мне с Tailwind не надо тащить всю экосистему React и т.п., я могу на голом HTML писать или на своем фреймворке whatever
А что тут непонятного? Инлайновые стили - это зло! Как бы вы их не пытались "закодировать".
вам и для использования css-модулей "не надо тащить всю экосистему React", какую вы вообще уловили здесь связь?
Вы опять выдираете пример, где все плохо. Так можно с любым языков/фреймворком.
Так же это прямо с сайта Tailwind, там на скриншоте видно подсказку "Why Tailwind CSS?" откройте консоль и проверьте.
Мне с Tailwind не надо тащить всю экосистему React и т.п., я могу на голом HTML писать или на своем фреймворке whatever
А причем тут React? Вы тащите весь tailwind) А CSS modules вообще не привязан к реакту. Везде где есть JS и Webpack/Vite/Rollup и т.п. есть css modules.
Ну а это
> Tailwind легко можно назвать «смертью ручного CSS»
полностью согласен с вами, что бред.
В моём нынешнем понимании идеальный высокоуровневый компонент вообще не содержит ни стилей, ни css классов. А изоляция стилей для компонентов это такая база, без которой я не знаю как можно жить.
Ой, ну какая интересная аргументация) возьмём пример с tailwind, в 4 пункте указан минус, который тут же перекрывается
Очень часто Tailwind критикуют за большое количество классов, которые «засоряют» компоненты. Но ведь подобная проблема может быть и у классического подхода
Потому что автор очевидно подтапливает за tailwind) а значит у всех минусов, которые можно оспорить(а других внезапно не нашлось) должен быть контраргумент, причём в следующем же предложении.
Зато если у нас слабый плюс затесался, а именно пункт 3
Поиск и рефакторинг стилей. Представьте ситуацию: вы работаете над Legacy‑проектом с большим количеством кода, и перед вами встает задача: изменить кнопку
то сразу найдётся невыдуманная ситуация, которая идеально подходит под указанный случай) особенно когда подобных ситуаций на самом деле днём с огнём не сыщешь, а любые css-модули сразу позволяют забыть об указанной проблеме, которую tailwind якобы решает. её решает почти что угодно) как кстати и про BEM, который также указан в 4 пункте.
В общем крайне избирательно, а от того слабо
P.S.: на хабре можно форматировать код
Есть основа ООП - каждый компонент должен быть максимально изолирован от остальных. Стилей это так же касается. Ну не нужна вся эта ебаная портянка из тысячи свойств у одного несчастного тега, и под ним идущему тегу опять миллион. Ну запихнуть ты это все в класс и заебись! Надо чёт поменять - модификатор. БЭМ это сила, уже кучу лет, и все пляски вокруг него это просто нежелание говнокодеров разбираться в нюансах. Все остальное оправдания
CSS модули, требуют разделять логику и стили, соответственно, делают разработку медленной. Стили хранятся в отдельных файлах, разработчику приходится постоянно переключаться между файлами с разметкой и стилями
Сделать CTRL + click по styles.button, отредактировать соответствующий класс, после чего нажать нажать боковую кнопку мыши "назад" не звучит как что-то медленное или неудобное.
больше не нужно создавать классы, придумывать им названия
Из-за тех же CSS Modules в этом нет ничего сложного. На проекте можно создавать сколько угодно классов с одинаковыми названиями.
Раздутые CSS‑бандлы. Тут всё понятно, даже неиспользуемые стили попадают в продакшн (если не настроить PurgeCSS). Огромное количество CSS файлов создает много лишнего CSS.
Существует code splitting чтобы грузить только те CSS чанки, которые необходимы для текущих отрендеренных компонентов.
про BEM вообще можно забыть
Да, уже очень давно, с тех пор как появились CSS Modules.
tailwind считается простым и ускоряет разработку? write-only с нуля - возможно. Но поддержка через время - ад. Я когда переключаюсь на проект с tailwind - у меня всегда открыта их дока в одном окне и чат-гпт в другом.
Вот недавний пример классов для анимации:
<span
className="
animate-highlights
[animation-play-state:paused]
[counter-reset:int_var(--highlights-start)]
[.visible_&]:animate-highlights
after:min-w-[3ch]
after:inline-block
after:content-[counter(int)]
"
/>write-only с нуля - возможно.
Да как он с нуля-то ускоряет? О чём все говорят? Мне аж ЧатГПТ пришлось дёргать - спрашиваю: он умеет в лэйаут? в "масштабируемую вёрстку"?
Отвечает: конечно он умеет - во флексбоксы и поддерживает grid. Плюс mobile-first breakpoint-ы... Посмотрел я примеры... Вы меня, конечно, извините, но с такой "поддержкой" можно только самую примитивную хрень верстать.
Плюс если я rem переопределю - всё вообще ломается нафиг! А мне там товарищ выше затирает что я ограниченный ретроград)) Ну реально же люди просто не смогли в CSS. Зумеры переизобрели Бутстрап...
Почитал про Tailwind, посмотрел примеры, это какой-то позор, извините. Так и до инлайновых стилей докатимся
Однозначно полезная статья 💪
Заслужил твердый плюс и карму👍
Сейчас чем скайнету удобно работать, тем и надо пользоваться
Ковроткачество, была такая профессия! Большинство фронтендеров это вчерашние ковроткачи.
Расстраивает то, что многие ругаются на инлайновость стилей tailwind, хотя там имеется способ закрепить их под обычным классом🥀
Этот стек точно прикольный для прототипирования. Этакий plug-in-play.
На данный момент у меня двоякие ощущения.
Например, я бы не стал сравнивать Sandch и MUI. Потому что кажется как будто у них немного разные задачи. Лично у меня до сих пор остались вопросы как реализовать некоторые компоненты которые в MUI из коробки.
То же и с TW.
1) Писать стили отдельно это не плохо. Это разделение обязанностей. По той же логике можно тесты запихнуть в тот же файл чтобы не переключаться.
2) нужно было сделать так чтобы количество колонок в grid определял js.
В итоге пришлось расширять компонент кастомыми стилями потому что tw так не может.
Возможно, я ещё разберусь и буду так же красочно описывать этот стек и закрывать глаза на недостатки)
А есть действительно сравнение двух одинаково написанных проектов которые используют стандартную разметку и эту "новомодную"? Действительно улучшается скорость загрузки и другое?
Tailwind это целая парадигма которая решает целый класс проблем. он даёт прежде всего скорость и надёжность что ничего не поломается. Так же он отлично работает с генераторами кода, скажем ai . У каждой технологии есть trade off, и длинный список классов это практически единственная единственная проблема.
Быстрый Frontend в 2025: почему RTK Query, Tailwind и Vite убивают классические подходы