Ни для кого ни секрет, что разработка и IT‑решения в 2025-м году — это гонка за скоростью: от выяснения бизнес‑требований до финальной версии продукта. Чем быстрее пишется код, тем раньше ваш продукт попадает к пользователям. Разумеется, выбор технологий существенно сказывается на скорости разработки.
В этой статье я бы хотел затронуть современные инструменты Frontend‑разработчика, которые уже начали вытеснять классику, а также попутно сокращают объём кода, избавляя разработчика от рутины.
Tailwind
Tailwind легко можно назвать «смертью ручного CSS», и не зря: если присмотреться к современным проектам, начиная от пет‑проектов разработчиков из Индии на видео‑площадках, и, заканчивая новейшими IT‑решениями, почти все они используют Tailwind и охотно советуют им пользоваться.
Какие существуют аналоги Tailwind?
SCSS/SASS
CSS модули
А теперь по порядку:
1. SCSS/SASS, как и CSS модули, требуют разделять логику и стили, соответственно, делают разработку медленной. Стили хранятся в отдельных файлах, разработчику приходится постоянно переключаться между файлами с разметкой и стилями. Tailwind предполагает писать стили прямо в разметке, что существенно влияет на скорость разработки: больше не нужно создавать классы, придумывать им названия, принцип очень прост: элемент и сразу стили, без лишних деталей. Ну и, конечно, это существенно уменьшает когнитивную нагрузку. Очень часто на уровне Junior я переключался между файлами, пытаясь устранить ошибки в вёрстке, и за счет постоянного отслеживания CSS‑файлов я уже и забывал, над чем работал до этого.
2. Раздутые CSS‑бандлы. Тут всё понятно, даже неиспользуемые стили попадают в продакшн (если не настроить PurgeCSS). Огромное количество CSS файлов создает много лишнего CSS.
3. Поиск и рефакторинг стилей. Представьте ситуацию: вы работаете над Legacy‑проектом с большим количеством кода, и перед вами встает задача: изменить кнопку. Вы копируете название класса, ищете CSS, где есть соответствующий класс, а потом молитесь, чтобы ваши изменения не затронули другие элементы. Tailwind позаботился и об этом: все стили каждого компонента находятся в одном месте — в его JSX/TSX.
4. Очень часто Tailwind критикуют за большое количество классов, которые «засоряют» компоненты. Но ведь подобная проблема может быть и у классического подхода: на старых сайтах элементы носят по 10 с лишним классов. Да и не сказать, что классы tailwind»а засоряют ваш код. Среднее количество классов, которые вы вешаете через tailwind — до 10 (если это не какие‑то сложные градиенты или анимации), и они прекрасно помещаются в одну строчку. А про BEM вообще можно забыть.
RTK Query
RTK Query принес конец эре ручного управления данными, как, например, Redux Thunk/Saga/Axios. Именно их мы и сравним.
1. Бойлерплейт‑код. Redux Thunk требует вручную создавать экшены, а также писать редьюсеры для обработки, ошибок и прочего. А Axios требует отдельных настроек: интерсепторов и базовых URL. RTK Query всё делает АВТОМАТИЧЕСКИ: автоматически генерирует хуки, никакого ручного управления данными — всё включено в хук, готовые экшены и редьюсеры под капотом.
Redux Thunk + Axios (раньше):
const fetchPosts = () => async (dispatch) => {
dispatch({ type: 'FETCH_POSTS_REQUEST' });
try {
const res = await axios.get('/api/posts');
dispatch({ type: 'FETCH_POSTS_SUCCESS', payload: res.data });
} catch (err) {
dispatch({ type: 'FETCH_POSTS_FAILURE', error: err.message });
}
};
RTK Query (сейчас):
const { data, error, isLoading } = useGetPostsQuery();2. Отсутствие кэширования. Кэширование в Redux Thunk или Axios нужно реализовывать вручную, а также данные проблематично инвалидировать (например, при их обновлении). RTK Query и здесь преуспел: он предоставляет автоматическое кэширование на основе эндпоинтов и аргументов, а также простую инвалидацию через invalidatesTags. А его киллер‑фича — фоновый рефетчинг при возвращении на страницу.
RTK Query: автоматический рефетчинг при фокусе окна
const { data } = useGetPostsQuery(undefined, { refetchOnFocus: true });
3. Избыток в стейт‑менеджменте. Thunk требует хранить API‑данные в Redux, а загрузки и ошибки управляются отдельно. Из‑за неправильной оптимизации появляются ререндеры. RTK Query оптимизирован под React (использует useMemo внутри хуков), а также создает селекторы автоматически.
Vite
Старые аналоги: Webpack
1. Скорость разработки. С webpack запуск dev‑сервера на больших проектах может занимать десятки секунд (из‑за полной сборки бандла). А запуск Vite занимает менее одной секунды, за счет нативного ESM (браузер загружает модули напрямую).
2. Конфигурация. Признайтесь, вы тоже сходили с ума, когда пытались настроить Webpack. Сложный webpack.config.js с кучей плагинов предоставляет реальную проблему для настройки и конфигурации. Vite её минимизировал:
Vite: базовая настройка за 5 строк
import { defineConfig } from 'vite';
export default defineConfig({
plugins: [react()]
});Shadcn/ui
Старые аналоги: Material UI, Ant Design.
В 2025 году shadcn/ui стал главной альтернативой классическим UI‑библиотекам вроде Material UI (MUI) и Ant Design. Почему? Потому что он решает их главные проблемы: раздутые бандлы, сложный кастомизацию и низкую производительность.
1. Размер бандла. MUI и Ant Design слишком тяжёлые. MUI весит 500 КБ, Ant Design 700 КБ, а shadcn/ui 0 КБ в бандле по умолчанию!
2. Кастомизация. Вы помните ту боль, когда было необходимо использовать styled() или sx в MUI? shadcn/ui решает эту проблему элегантно — просто копируешь компонент в свой проект и меняешь как угодно, ведь под капотом у него Tailwind.
MUI: сложный оверрайд стилей
<Button sx={{ background: 'linear-gradient(to right, #ff8a00, #da1b60)', '&:hover': { opacity: 0.8 }}}> Кнопка </Button>
shadcn/ui: просто Tailwind
<Button className="bg-gradient-to-r from-orange-500 to-pink-600 hover:opacity-80"> Кнопка </Button>
3. Производительность. MUI использует эмуляцию CSS‑in‑JS (устаревший подход, медленный SSR), а Ant Design рендерит лишние обёртки.
И тут shadcn‑ui побеждает: shadcn/ui — это чистые React‑компоненты без рантайм‑стилей, которые дают быстрый SSR, меньше ререндеров и отсутствие тяжёлых стилей в js.
MUI и Ant Design ещё живы в корпоративных проектах, но для современного фронтенда в 2025 shadcn/ui + Tailwind — идеальная комбинация.
Заключение
Будущее фронтенда за простотой и скоростью. 2025 год окончательно утвердил новые стандарты фронтенд‑разработки: меньше бойлерплейта, больше производительности, проще поддержка.
Tailwind CSS убил ручное написание CSS, избавив нас от бесконечных файлов стилей, раздутых бандлов и сложного рефакторинга.
RTK Query похоронил Redux Thunk и ручное управление API‑запросами, предложив автоматическое кэширование, минимум кода и встроенную оптимизацию.
Vite заменил медленный и сложный Webpack, обеспечив мгновенный запуск dev‑сервера и простую настройку.
shadcn/ui вытеснил громоздкие MUI и Ant Design, дав разработчикам лёгкие, кастомизируемые компоненты без лишних зависимостей.
Эти инструменты делают разработку быстрее, удобнее и предсказуемее. Они не просто модные тренды — они новый стандарт, который уже используют ведущие компании и стартапы.
Совет на 2025: если ваш стек ещё держится за Webpack, Redux Thunk и MUI — самое время переходить на современные инструменты. Они уже доказали, что экономия времени и нервов разработчика — это не роскошь, а must‑have.
Комментарии (95)
Metotron0
15.06.2025 19:39Лично мне 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 строк, кроме закрывающих тегов. Удачи в добавлении ссылки в нужное место с первого раза.
Politura
15.06.2025 19:39Новое, это хорошо забытое старое. Когда-то когда html был юн, стилей было мало и их добавляли к каждому элементу, но не классами, а аттрибутом style, что там долавлять-то, отступы, толщинцу рамки, цвет текста и цвет фона.
Потом поняли, что переиспользование стилей это хорошо и даже замечательно: один раз класс кнопки с нужным стилем сделал и используй на всех кнопках, да и стилей становилось все больше и больше.
Теперь ньюфаги решили изобрести то, как было на заре веба, забив на переиспользование.
Femistoklov
15.06.2025 19:39Теперь ньюфаги решили изобрести то, как было на заре веба, забив на переиспользование.
Я и сам люблю пошутить над "фронтендеры опять изобрели колесо", но в реальности всё не так однозначно. Совсем идиоты новых успешных продуктов для разработчиков не создают. И у них есть целая страница с аргументацией их точки зрения (однако совет по использования мультикурсора - это, конечно, лол).
artptr86
15.06.2025 19:39А в чём преждевременность абстракции, если обычно проект верстается по готовым макетам, то есть проблема декомпозиции и унификации уже по большей части решена дизайнером?
Я могу только понять использование Tailwind, когда верстальщик сам является дизайнером и «дизайнит» на лету во время вёрстки страницы. Только кажется, что этот процесс больше подходит «одноразовым» страницам типа лендингов или индусам-фрилансерам, которые подписались на работу по дизайну-вёрстке за фиксированную оплату.
MTyrz
15.06.2025 19:39кажется, что этот процесс больше подходит «одноразовым» страницам типа лендингов или индусам-фрилансерам
Так для них и написано. Сказано же,
хуяк-хуяк и в продакшн"разработка и IT‑решения в 2025-м году — это гонка за скоростью: от выяснения бизнес‑требований до финальной версии продукта"
dragonesis
15.06.2025 19:39На самом деле ничего сложного в этом нет, если верстальщик не отдал портянку на 300 строк html кода в инлайн режиме.
Потому что у тебя, обычно, есть компонент, который содержит другие компоненты. И если ты видишь название Paper или ImageWrapper то понимаешь что там происходит. Я не очень люблю TailwindCSS. Но часто проблема не в нем. Я точно также видел проекты на пару сотен строк html разметки с одиночными классами и точно также приходилось задаваться вопросом this is чзх? потому что горе верстала добавил классы body, container, wrapper и они все нужны, просто ему не хватило абстракции как-то это по другому обозвать.
Имхо, самая большая проблема в отладки TailwindCSS с которой я сталкивался против css moduls это невозможность настроить через класс определить что за компонент и приходится лезть в тулзы, вместо базового древа в консоли. Т.е. прямо скажем, мелочь.
questpc
15.06.2025 19:39Вроде бы там через конфиги можно создавать метаклассы по одному имени включающие наследующие целый список встроенных классов. Об этом как то мельком упомянуто пока сам не разбирался. Это был бы оптимальный подход.
artptr86
15.06.2025 19:39То есть без классов всё-таки никуда, и пришлось придумать их заново?
Об этом как то мельком упомянуто
Где упомянуто? Я не смог даже нагуглить.
unv_unv
15.06.2025 19:39
TailwindCSS предлагает верстать не сущностными именами классов, а чисто утилитарными. Вместо h1, h2, у тебя span'ы с мусорными классами. Ну это же моветон. Быстро наговнокодить — это же не подход. Это же write-only, это невозможно нормально поддерживать и развивать.
Itsyxon Автор
15.06.2025 19:39Будем честны, "быстро наговнокодить" можно и без tailwind'а.
Этот термин вообще, скорее, не про инструмент, а про человека.
JerryI
15.06.2025 19:39Не во всем согласен. Это опять зависит от разработчика. H1,h2 заголовки, а tailwind дает просто размеры шрифтов. Все, что крупное не всегда заголовок и т.д. Возможно этот пример просто неудачный.
Tailwind при правильном подходе позволяет верстать и тестировать быстрее и не в ущерб качеству. Это вопрос стиля и подхода к дизайну и верстке, и не про supertool. Dark styles решаются быстрее «условными классами» и многие другие вещи. Я комбинирую tailwind с обычными классами и пока все очень предсказуемо, изменяемо и расширяемо.
dragonesis
15.06.2025 19:39пардонте. При всей не любви к TailwindCSS, чисто эстетической, надо сказать, но пример выше это не проблем TailwindCSS. Вы также можете добавить класс heading-l1 или любой другой и вкорячить его хоть в кнопку.
ImagineTables
15.06.2025 19:39Надо понимать, что одно дело — страница для очередного стартапа из тех, которые закрываются раньше, чем о них успеет написать Слава Рюмин. Для них говнокод это нормально. Давайте, бахайте оформление тейлвиндом и т.д. За соответствующий гонорар. А ещё лучше не мудрите, а берите готовую страницу за доллар с yourfreewebtemplatenew2025.com.
И совсем другое — UI, с которым будут работать сотни тысяч юзеров или больше. Там требования к качеству совсем другие. Я лично пришёл к тому, что вообще любая утилита — это плохо, это очень плохо. Маркируйте разметку строго семантически, а обобщения реализуйте через миксины, а не утилиты. Будет чистый и понятный код без проблем в виде DRY violations и прочего шит-кода.
И поверьте, CSS вынесли в отдельный DSL и отдельные файлы не дураки. Вы бы пописали код в доисторическую эпоху с атрибутами
colorилиwidth, сразу бы поняли, от чего мы ушли, и к чему тащат нас зумеры со своими тайлвиндами.Itsyxon Автор
15.06.2025 19:39Если мы говорим про гигантский проектище с миллионами строк кода, то даже там сложно выйти за пределы DRY.
Tailwind предоставляет apply, который как раз помогает этого избежать доступным образом.
А CSS и его препроцессоры — нет, увы. Всё равно будет лишний CSS и переиспользование.
artptr86
15.06.2025 19:39Мысль неясна. Если мы можем создать свой класс в тейлвинде через apply, то чем это принципиально отличается от написания того же самого CSS руками или с помощью препроцессоров (которые просто делают рутинную работу)?
ImagineTables
15.06.2025 19:39Что делать с тремя-четырьмя уровнями вложенности миксинов? Копипастить их в разметку в виде имён классов? Это, по-вашему, «переиспользование»? И что делать, когда иерархия наследования изменится? Бегать по тегам и менять в сотнях мест?
Именно так и нарушается DRY при использовании утилит (а Тейлвинд это утилитинг в чистом виде). А сколько там строк, это не важно. Я, кстати, в несколько тысяч не минифицированных строк CSS укладываюсь всегда, даже для сложных проектов.
dom1n1k
15.06.2025 19:39Tailwind предоставляет apply, который как раз помогает этого избежать доступным образом.
Только вот беда, сами авторы TW назвают apply антипаттерном и призывают использовать пореже. И в целом понятно почему - это по сути ломает основную концепцию и убивает декларируемые преимущества. И становится еще более непонятно, зачем это всё нужно.
И особенно это интересно в свете популярности DaisyUI (в State of CSS 2024 пусть не в самом топе, но заметное распространение), где слом основной идеи TW преподносится как преимущество.
Сообщество TW колбасит, оно само не может решить, как лучше и почему.
cmyser
15.06.2025 19:39Очень советую почитать про $mol
Очень много годных решений там уже сделаны
nin-jin
15.06.2025 19:39Ну, кстати, да, статически типизированные каскадные стили, стейт менеджмент, кастомизируемость компонент и zero-config окружение разработчика там просто офигенные.
Spaceoddity
15.06.2025 19:39Просто в отрасль хлынул огромный поток мимокрокодилов. CSS они не знают (ну иъ наверное сразу ввели в курс дела - что CSS это фигня и вообще не ЯП и даже внимания вашего не стоит), вот до сих пор и обмазываются всяким непотребством... Ещё и других призывают))
Nyanny
15.06.2025 19:39Не только в этом дело. Точнее, мимо крокодилы в отрасли - да, но не как раньше.
Дело ещё в LLM.
По какой-то причине LLM обожают Tailwind и "предпочитают" делать код на нем.
Claude вообще использует Tailwind по-умолчанию. Иной раз, даже когда указан стек пакетов, например, Mantine или чистый HTML/CSS, он все равно тащит Tailwind. Нужно добавлять в промт отдельное предложение "НЕ ИСПОЛЬЗУЙ TAILWIND".
Остальные LLM тоже предпочитают Tailwind, хоть и не так фанатично.
artptr86
15.06.2025 19:39Так это уже следствие хайповой популярности. Больше репозиториев с тейлвиндом на гитхабе — больше база для обучения LLM. То же самое с питоном, который у чатгпт — язык по-умолчанию.
Itsyxon Автор
15.06.2025 19:39Вы можете трактовать это любым удобным вам способом))
Напротив, я знаю, что такое Legacy-код и CSS, особенно с древних Wordpress + JQuery сайтов.И, когда я перешёл на Tailwind, это было облегчением и переломным моментом))
Ну, а свою "неспособность следить и подхватывать тренды" не нужно как-то трактовать иначе, тем более винить в этом третьего))
Spaceoddity
15.06.2025 19:39Напротив, я знаю, что такое 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. Если вдруг вас заденет такой стиль общения - задайте себе вопрос: а стоит ли в дискуссии переходить на личности, не аукнется ли мне это?
DmitriiMikhailov
15.06.2025 19:39От проекта зависит. Если на вас давят сверху и подгоняют - вы будете использовать любые инструменты что бы уложиться в дедлайн. В таком случае лучше разработать что бы работало, чем быть уволенным и писать великолепно оптимизированные pet проекты дома. Большинству проектов не нужны уникальные стили, нужно просто получить данные из БД, обработать и записать обратно. Если проект супер уникальный, у вас много свободного времени и бюджета, то можно разработать свои CSS классы, но большинство заказчиков не готовы за это платить, особенно если вы берете с них $100 в час :D
Spaceoddity
15.06.2025 19:39Что значит "разработать свои CSS классы"? Как их разрабатывают-то? Вы думаете кто-то сидит и сочиняет тэйлвиндовские портянки с классами на каждый чих?
viacheslav_ustinov
15.06.2025 19:39Tailwind и Shadcn удобны только вайбкоддерам - им проще скинуть промптом сразу весь компонент) а в плане оптимизации и работы - очень своебразно, нередко дом-дерево на ТВинд вложеннее, чем нужно обычно
RTK, упомянутый в тексте, неплох, но тогда уж Tanstack тоже стоит упомянуть, не все хотят тянуть куски редакса в проект, и ТСтэк более агностичен в этом плане, и вроде как посвежее
Vite появился давно, из свежего теперь RSpack, Turbopack и прочий раст походу) пока писалась статья - на фронтенде, как обычно, всё пытается устареть)
Lezvix
15.06.2025 19:39Vite под капотом использует esbuild и rollup, а rollup в свою очередь использует модный бандлер SWC как раз на Rust.
Помомо Tanstack есть ещё и SWR от vercel, с размером пакета поменьше и схожей функциональностью
Itsyxon Автор
15.06.2025 19:39Согласен, я хотел упомянуть TanStack. НО.
В данном посте я ещё сравниваю RTK с Axios, а Tanstack использует axios, поэтому счёл нецелесообразным. Но спасибо за замечение. Обязательно сделаю еще статью про Tanstack.
nin-jin
15.06.2025 19:39Tailwind легко можно назвать «смертью ручного CSS», и не зря: если присмотреться к современным проектам, начиная от пет‑проектов разработчиков из Индии на видео‑площадках, и, заканчивая новейшими IT‑решениями, почти все они используют Tailwind и охотно советуют им пользоваться.
shadcn/ui решает эту проблему элегантно — просто копируешь компонент в свой проект и меняешь как угодно, ведь под капотом у него Tailwind.
Copy/Paste Driven Development? Успехов вам с накатыванием обновлений.
shadcn/ui — это чистые React‑компоненты без рантайм‑стилей, которые дают быстрый SSR, меньше ререндеров и отсутствие тяжёлых стилей в js.
Раздутый раз в 10 HTML, и полный ререндер при изменении темы, лейаута и тд.
Itsyxon Автор
15.06.2025 19:39Раздутый раз в 10 HTML, и полный ререндер при изменении темы, лейаута и тд.
Пруф + аналог, у которого этого нет
Copy/Paste Driven Development? Успехов вам с накатыванием обновлений.
По-моему, слишком очевидно, что речь здесь идет про установку самостоятельных компонентов UI в проект и минимизацию бандла, без речи про обновления и тому подобное. Да и причем тут вообще обновления, если мы говорим об использовании готовых UI? По этой логике, всё, что не Golang (где есть пометка о жёстких-нежёстких версиях в .mod файлах, ломающих проект при обновлении) — фигня.
Я так понимаю, твой комментарий нацелен на пиар YouTube-канала)) Ну что ж, я и не против, собственно))
artptr86
15.06.2025 19:39Пруф + аналог, у которого этого нет
Извините, я правильно вас понимаю, что вы просите доказательства факта, и тут же привести хотя бы один контрпример? Разве ваш вопрос не противоречит самому себе?
Hex1s
15.06.2025 19:39Я считаю, что css/scss никто не уничтожил. Всё еще проще и удобней прописывать те же ui компоненты, через них, когда у тебя 4+ варианта кнопок, к примеру. И всё еще зависит от типа проекта, если у вас стартап и вы постоянно проверяете гипотезы, то конечно будет удобней взять tailwind в руки и начать пилить фичи, нежели раскидывать всё по отдельным файлам.
Itsyxon Автор
15.06.2025 19:39Все препроцессоры это прошлый век. Особенно BEM-методология и css-модули.
Все современные инструменты решают абсолютно все проблемы, которые решали они ранее. Я думаю, есть только одна причина, почему кто-то использует SCSS или CSS-модули — они просто не хотят пробовать ничего нового и работают "по старинке".
artptr86
15.06.2025 19:39Только у Tailwind под капотом тоже препроцессоры для генерации цветовых, размерных и прочих наборов стилей, до кучи и PurgeCSS для вырезания всего лишнего мусора.
shsv382
15.06.2025 19:39Просто те, кто пишут, используя БЭМ и SCSS, умеют грамотно разделять стили и не лепить один и тот же класс в разные места приложения. Легаси, в котором ломаются зависимые стили? А вы попробуйте пофиксить что-то в легаси проекте, использующем Tailwind! Там бывает такая ситуация, когда абсолютно одинаковая километровая лапша стилей приписана разным элементам в разных компонентах, и тупо невозможно найти элемент, который требуется изменить.
Я знаю, о чем говорю, я был и на легаси проектах, и на Tailwind (сейчас), и я все еще ненавижу Tailwind
artptr86
15.06.2025 19:39абсолютно одинаковая километровая лапша стилей приписана разным элементам в разных компонентах
А в 101-м месте такая же, но чуть-чуть другая. Удачи разобраться так это и задумано, или забыли когда-то раньше поправить, или сломали случайно :)
А затем приходят дизайнеры и говорят, что надо цветовую схему поменять :)
Grikus
15.06.2025 19:39Заводишь цветовые элементы в variables, и просто меняешь по требованию - вы великолепны!
artptr86
15.06.2025 19:39Это если подумал заранее и создал семантическую палитру. Но у фаната тейлвинда весь код состоит из text-gray-100 bg-blue-800 чуть менее, чем полностью, ведь семантика не нужна :)
Grikus
15.06.2025 19:39Ну потому что ключевое слово тут подумал) а обычно рот открыл, слюна побежала, "как стилизовать теги", кмд с кмд в
questpc
15.06.2025 19:39Эту проблему решили бы метаклассы, определяемые из встроенных. Надо бы это посмотреть. Хотя еще наверное это решаемо через custom web elements.
artptr86
15.06.2025 19:39Как тут custom elements и метаклассы помогут? Вы суть проблемы-то поняли?
questpc
15.06.2025 19:39Понял. Надо длинную строку
<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; }artptr86
15.06.2025 19:39В какой версии Tailwind у вас есть
@extend?И уж лучше чистый CSS или SCSS, чем такой кадавр.
Hex1s
15.06.2025 19:39Это не нежелание пробовать что-то новое. Eсть разные инструменты для разных задач, если нужно быстро что-то сверстать это правда, что tailwind незаменим, хотя все еще с интересом наблюдаю как люди прописывают кастомные свойства и тд. Та же группировка состояний чего стоит. Качественно разбитые файлы стилей позволяют разделить восприятие. Чтобы у тебя компонент не превращался в кашу из стилей, особенно если он кардинально меняется на active стейте.
Arves
15.06.2025 19:39Все препроцессоры это прошлый век. Особенно BEM-методология и css-модули
CSS Modules наоборот убили BEM, да и инструменты типа SCSS абсолютно не обязательно использовать с CSS Modules, тем более в 2025. Для многих проектов достаточно чистого CSS, а скоро ещё и функции добавят.
nin-jin
15.06.2025 19:39И как же "современный" tailwind решает проблему кастомизации компонента вложенного в другой из третьего?
markelov69
15.06.2025 19:39Tailwind легко можно назвать «смертью ручного 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 возведено в абсолют.
JerryI
15.06.2025 19:39Вы опять выдираете пример, где все плохо. Так можно с любым языков/фреймворком. Я могу взять, скажем, Notion и показать, как там все плохо с повсеместным использованием inline стайлов. Скажет ли это что-то - нет?
Можно показать реакт-пример где куча сгенерированных стилей и все выглядит как говно, что опять бессмысленно. Вам просто нравится эта технология, но она точно такая же как и tailwind. У каждого свои сильные стороны и слабые. Мне с Tailwind не надо тащить всю экосистему React и т.п., я могу на голом HTML писать или на своем фреймворке whatever
Spaceoddity
15.06.2025 19:39А что тут непонятного? Инлайновые стили - это зло! Как бы вы их не пытались "закодировать".
winkyBrain
15.06.2025 19:39вам и для использования css-модулей "не надо тащить всю экосистему React", какую вы вообще уловили здесь связь?
clerik_r
15.06.2025 19:39Вы опять выдираете пример, где все плохо. Так можно с любым языков/фреймворком.
Так же это прямо с сайта Tailwind, там на скриншоте видно подсказку "Why Tailwind CSS?" откройте консоль и проверьте.
Вот она, дичь во всей красе. Мне с Tailwind не надо тащить всю экосистему React и т.п., я могу на голом HTML писать или на своем фреймворке whatever
А причем тут React? Вы тащите весь tailwind) А CSS modules вообще не привязан к реакту. Везде где есть JS и Webpack/Vite/Rollup и т.п. есть css modules.
questpc
15.06.2025 19:39Tailwind можно использовать без громоздких npm webpack / rollup. На чистом веб. Хотя кому как.
markelov69
15.06.2025 19:39А CSS можно использовать без громоздких Tailwind. На гораздо более чистом веб, выражаясь вашими определениями.
JerryI
15.06.2025 19:39Ну а это
> Tailwind легко можно назвать «смертью ручного CSS»
полностью согласен с вами, что бред.
frostsumonner
15.06.2025 19:39В моём нынешнем понимании идеальный высокоуровневый компонент вообще не содержит ни стилей, ни css классов. А изоляция стилей для компонентов это такая база, без которой я не знаю как можно жить.
winkyBrain
15.06.2025 19:39Ой, ну какая интересная аргументация) возьмём пример с tailwind, в 4 пункте указан минус, который тут же перекрывается
Очень часто Tailwind критикуют за большое количество классов, которые «засоряют» компоненты. Но ведь подобная проблема может быть и у классического подхода
Потому что автор очевидно подтапливает за tailwind) а значит у всех минусов, которые можно оспорить(а других внезапно не нашлось) должен быть контраргумент, причём в следующем же предложении.
Зато если у нас слабый плюс затесался, а именно пункт 3
Поиск и рефакторинг стилей. Представьте ситуацию: вы работаете над Legacy‑проектом с большим количеством кода, и перед вами встает задача: изменить кнопку
то сразу найдётся невыдуманная ситуация, которая идеально подходит под указанный случай) особенно когда подобных ситуаций на самом деле днём с огнём не сыщешь, а любые css-модули сразу позволяют забыть об указанной проблеме, которую tailwind якобы решает. её решает почти что угодно) как кстати и про BEM, который также указан в 4 пункте.
В общем крайне избирательно, а от того слабо
P.S.: на хабре можно форматировать код
Grikus
15.06.2025 19:39Есть основа ООП - каждый компонент должен быть максимально изолирован от остальных. Стилей это так же касается. Ну не нужна вся эта ебаная портянка из тысячи свойств у одного несчастного тега, и под ним идущему тегу опять миллион. Ну запихнуть ты это все в класс и заебись! Надо чёт поменять - модификатор. БЭМ это сила, уже кучу лет, и все пляски вокруг него это просто нежелание говнокодеров разбираться в нюансах. Все остальное оправдания
Arves
15.06.2025 19:39CSS модули, требуют разделять логику и стили, соответственно, делают разработку медленной. Стили хранятся в отдельных файлах, разработчику приходится постоянно переключаться между файлами с разметкой и стилями
Сделать CTRL + click по
styles.button, отредактировать соответствующий класс, после чего нажать нажать боковую кнопку мыши "назад" не звучит как что-то медленное или неудобное.больше не нужно создавать классы, придумывать им названия
Из-за тех же CSS Modules в этом нет ничего сложного. На проекте можно создавать сколько угодно классов с одинаковыми названиями.
Раздутые CSS‑бандлы. Тут всё понятно, даже неиспользуемые стили попадают в продакшн (если не настроить PurgeCSS). Огромное количество CSS файлов создает много лишнего CSS.
Существует code splitting чтобы грузить только те CSS чанки, которые необходимы для текущих отрендеренных компонентов.
про BEM вообще можно забыть
Да, уже очень давно, с тех пор как появились CSS Modules.
noodles
15.06.2025 19:39tailwind считается простым и ускоряет разработку? 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)] " />Spaceoddity
15.06.2025 19:39write-only с нуля - возможно.
Да как он с нуля-то ускоряет? О чём все говорят? Мне аж ЧатГПТ пришлось дёргать - спрашиваю: он умеет в лэйаут? в "масштабируемую вёрстку"?
Отвечает: конечно он умеет - во флексбоксы и поддерживает grid. Плюс mobile-first breakpoint-ы... Посмотрел я примеры... Вы меня, конечно, извините, но с такой "поддержкой" можно только самую примитивную хрень верстать.
Плюс если я rem переопределю - всё вообще ломается нафиг! А мне там товарищ выше затирает что я ограниченный ретроград)) Ну реально же люди просто не смогли в CSS. Зумеры переизобрели Бутстрап...
artptr86
15.06.2025 19:39В Бутстрапе ценностью были не утилитные классы, а компонентные: сетка как компонент и UI-компоненты.
valter7
15.06.2025 19:39Почитал про Tailwind, посмотрел примеры, это какой-то позор, извините. Так и до инлайновых стилей докатимся
powerman
Я смотрю, на фронте уже лет 20 ничего не меняется: по-прежнему примерно раз года в 3 происходит смена значительной части всех инструментов и библиотек, с выходом подобных статей.
artptr86
Так-то Tailwind вышел 6 лет назад (а концепция Atomic CSS была ещё раньше), Redux Toolkit (тогда Redux Starter Kit) зарелизился тоже почти 6 лет назад, а Vite — 5 лет назад. Да и с выходом этой статьи «революция» не произошла: зумеры уже давно на подобный стек перешли, а серьёзным проектам некогда и незачем.
francyfox
хотели сказать бумеры. Зумеры как раз пишут такие статьи
artptr86
Я всё правильно написал: зумеры хайпуют на модных технологиях
ploskorub
В этом и проблема, что "серьёзные проекты" держатся за счёт "скуфов", которые до сих пор пишут на BEM и создают гига-тонны CSS-файлов и считают это нормой))
artptr86
Если проекту нужны гигатонны CSS-файлов, то в переложении на Tailwind в нём будут тератонны стилевых строк. Элементам же всё равно нужны стили. Только на BEM или CSS Modules это будет отдельный файл с именованными стилями, а в Tailwind — те же самые стили, только заинлайненные в сам компонент. Однако пропадает семантика стилей, самодокументируемость и увеличивается риск дублирования реализации.
ploskorub
Вот именно из-за этого автор и изложил проблемы подхода с CSS в третьем пункте))
artptr86
Нет, вы же сами говорите, что у «скуфов» BEM, а в нём взаимовлияния стилей исключены.
arutune
Да, забавно, как в мире моды- что у нас в тренде в этом сезоне?)