Comments 39
Я смотрю, на фронте уже лет 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, когда не было компонент. Сейчас переиспользуемость происходит на другом уровне.
TailwindCSS предлагает верстать не сущностными именами классов, а чисто утилитарными. Вместо h1, h2, у тебя span'ы с мусорными классами. Ну это же моветон. Быстро наговнокодить — это же не подход. Это же write-only, это невозможно нормально поддерживать и развивать.
Будем честны, "быстро наговнокодить" можно и без tailwind'а.
Этот термин вообще, скорее, не про инструмент, а про человека.
Не во всем согласен. Это опять зависит от разработчика. H1,h2 заголовки, а tailwind дает просто размеры шрифтов. Все, что крупное не всегда заголовок и т.д. Возможно этот пример просто неудачный.
Tailwind при правильном подходе позволяет верстать и тестировать быстрее и не в ущерб качеству. Это вопрос стиля и подхода к дизайну и верстке, и не про supertool. Dark styles решаются быстрее «условными классами» и многие другие вещи. Я комбинирую tailwind с обычными классами и пока все очень предсказуемо, изменяемо и расширяемо.
Надо понимать, что одно дело — страница для очередного стартапа из тех, которые закрываются раньше, чем о них успеет написать Слава Рюмин. Для них говнокод это нормально. Давайте, бахайте оформление тейлвиндом и т.д. За соответствующий гонорар. А ещё лучше не мудрите, а берите готовую страницу за доллар с yourfreewebtemplatenew2025.com.
И совсем другое — UI, с которым будут работать сотни тысяч юзеров или больше. Там требования к качеству совсем другие. Я лично пришёл к тому, что вообще любая утилита — это плохо, это очень плохо. Маркируйте разметку строго семантически, а обобщения реализуйте через миксины, а не утилиты. Будет чистый и понятный код без проблем в виде DRY violations и прочего шит-кода.
И поверьте, CSS вынесли в отдельный DSL и отдельные файлы не дураки. Вы бы пописали код в доисторическую эпоху с атрибутами color или width, сразу бы поняли, от чего мы ушли, и к чему тащат нас зумеры со своими тайлвиндами.
Очень советую почитать про $mol
Очень много годных решений там уже сделаны
Ну, кстати, да, статически типизированные каскадные стили, стейт менеджмент, кастомизируемость компонент и zero-config окружение разработчика там просто офигенные.
Просто в отрасль хлынул огромный поток мимокрокодилов. CSS они не знают (ну иъ наверное сразу ввели в курс дела - что CSS это фигня и вообще не ЯП и даже внимания вашего не стоит), вот до сих пор и обмазываются всяким непотребством... Ещё и других призывают))
Не только в этом дело. Точнее, мимо крокодилы в отрасли - да, но не как раньше.
Дело ещё в LLM.
По какой-то причине LLM обожают Tailwind и "предпочитают" делать код на нем.
Claude вообще использует Tailwind по-умолчанию. Иной раз, даже когда указан стек пакетов, например, Mantine или чистый HTML/CSS, он все равно тащит Tailwind. Нужно добавлять в промт отдельное предложение "НЕ ИСПОЛЬЗУЙ TAILWIND".
Остальные LLM тоже предпочитают Tailwind, хоть и не так фанатично.
Вы можете трактовать это любым удобным вам способом))
Напротив, я знаю, что такое Legacy-код и CSS, особенно с древних Wordpress + JQuery сайтов.
И, когда я перешёл на Tailwind, это было облегчением и переломным моментом))
Ну, а свою "неспособность следить и подхватывать тренды" не нужно как-то трактовать иначе, тем более винить в этом третьего))
От проекта зависит. Если на вас давят сверху и подгоняют - вы будете использовать любые инструменты что бы уложиться в дедлайн. В таком случае лучше разработать что бы работало, чем быть уволенным и писать великолепно оптимизированные pet проекты дома. Большинству проектов не нужны уникальные стили, нужно просто получить данные из БД, обработать и записать обратно. Если проект супер уникальный, у вас много свободного времени и бюджета, то можно разработать свои CSS классы, но большинство заказчиков не готовы за это платить, особенно если вы берете с них $100 в час :D
Tailwind и Shadcn удобны только вайбкоддерам - им проще скинуть промптом сразу весь компонент) а в плане оптимизации и работы - очень своебразно, нередко дом-дерево на ТВинд вложеннее, чем нужно обычно
RTK, упомянутый в тексте, неплох, но тогда уж Tanstack тоже стоит упомянуть, не все хотят тянуть куски редакса в проект, и ТСтэк более агностичен в этом плане, и вроде как посвежее
Vite появился давно, из свежего теперь RSpack, Turbopack и прочий раст походу) пока писалась статья - на фронтенде, как обычно, всё пытается устареть)
Vite под капотом использует esbuild и rollup, а rollup в свою очередь использует модный бандлер SWC как раз на Rust.
Помомо Tanstack есть ещё и SWR от vercel, с размером пакета поменьше и схожей функциональностью
Согласен, я хотел упомянуть TanStack. НО.
В данном посте я ещё сравниваю RTK с Axios, а Tanstack использует axios, поэтому счёл нецелесообразным. Но спасибо за замечение. Обязательно сделаю еще статью про Tanstack.
Вредные советы фронтендеру от Григория Остера
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 для вырезания всего лишнего мусора.
Просто те, кто пишут, используя БЭМ и SCSS, умеют грамотно разделять стили и не лепить один и тот же класс в разные места приложения. Легаси, в котором ломаются зависимые стили? А вы попробуйте пофиксить что-то в легаси проекте, использующем Tailwind! Там бывает такая ситуация, когда абсолютно одинаковая километровая лапша стилей приписана разным элементам в разных компонентах, и тупо невозможно найти элемент, который требуется изменить.
Я знаю, о чем говорю, я был и на легаси проектах, и на Tailwind (сейчас), и я все еще ненавижу Tailwind
Это не нежелание пробовать что-то новое. Eсть разные инструменты для разных задач, если нужно быстро что-то сверстать это правда, что tailwind незаменим, хотя все еще с интересом наблюдаю как люди прописывают кастомные свойства и тд. Та же группировка состояний чего стоит. Качественно разбитые файлы стилей позволяют разделить восприятие. Чтобы у тебя компонент не превращался в кашу из стилей, особенно если он кардинально меняется на active стейте.
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 возведено в абсолют.
Быстрый Frontend в 2025: почему RTK Query, Tailwind и Vite убивают классические подходы