15.06.2025 16:15
Itsyxon 39 8400 Источник

Ни для кого ни секрет, что разработка и 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.

Комментарии (39)


  1. powerman
    15.06.2025 19:39
    #28439286

    Я смотрю, на фронте уже лет 20 ничего не меняется: по-прежнему примерно раз года в 3 происходит смена значительной части всех инструментов и библиотек, с выходом подобных статей.


    1. artptr86
      15.06.2025 19:39
      #28439560

      Так-то Tailwind вышел 6 лет назад (а концепция Atomic CSS была ещё раньше), Redux Toolkit (тогда Redux Starter Kit) зарелизился тоже почти 6 лет назад, а Vite — 5 лет назад. Да и с выходом этой статьи «революция» не произошла: зумеры уже давно на подобный стек перешли, а серьёзным проектам некогда и незачем.


      1. francyfox
        15.06.2025 19:39
        #28440784

        хотели сказать бумеры. Зумеры как раз пишут такие статьи


        1. artptr86
          15.06.2025 19:39
          #28440882

          Я всё правильно написал: зумеры хайпуют на модных технологиях


      1. ploskorub
        15.06.2025 19:39
        #28440980

        В этом и проблема, что "серьёзные проекты" держатся за счёт "скуфов", которые до сих пор пишут на BEM и создают гига-тонны CSS-файлов и считают это нормой))


        1. artptr86
          15.06.2025 19:39
          #28441050

          Если проекту нужны гигатонны CSS-файлов, то в переложении на Tailwind в нём будут тератонны стилевых строк. Элементам же всё равно нужны стили. Только на BEM или CSS Modules это будет отдельный файл с именованными стилями, а в Tailwind — те же самые стили, только заинлайненные в сам компонент. Однако пропадает семантика стилей, самодокументируемость и увеличивается риск дублирования реализации.


          1. ploskorub
            15.06.2025 19:39
            #28441068

            Вот именно из-за этого автор и изложил проблемы подхода с CSS в третьем пункте))


            1. artptr86
              15.06.2025 19:39
              #28441094

              Нет, вы же сами говорите, что у «скуфов» BEM, а в нём взаимовлияния стилей исключены.


  1. Metotron0
    15.06.2025 19:39
    #28439328

    Лично мне 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 строк, кроме закрывающих тегов. Удачи в добавлении ссылки в нужное место с первого раза.


    1. Politura
      15.06.2025 19:39
      #28439698

      Новое, это хорошо забытое старое. Когда-то когда html был юн, стилей было мало и их добавляли к каждому элементу, но не классами, а аттрибутом style, что там долавлять-то, отступы, толщинцу рамки, цвет текста и цвет фона.

      Потом поняли, что переиспользование стилей это хорошо и даже замечательно: один раз класс кнопки с нужным стилем сделал и используй на всех кнопках, да и стилей становилось все больше и больше.

      Теперь ньюфаги решили изобрести то, как было на заре веба, забив на переиспользование.


      1. Femistoklov
        15.06.2025 19:39
        #28439954

        Теперь ньюфаги решили изобрести то, как было на заре веба, забив на переиспользование.

        Я и сам люблю пошутить над "фронтендеры опять изобрели колесо", но в реальности всё не так однозначно. Совсем идиоты новых успешных продуктов для разработчиков не создают. И у них есть целая страница с аргументацией их точки зрения (однако совет по использования мультикурсора - это, конечно, лол).


        1. artptr86
          15.06.2025 19:39
          #28441090

          А в чём преждевременность абстракции, если обычно проект верстается по готовым макетам, то есть проблема декомпозиции и унификации уже по большей части решена дизайнером?

          Я могу только понять использование Tailwind, когда верстальщик сам является дизайнером и «дизайнит» на лету во время вёрстки страницы. Только кажется, что этот процесс больше подходит «одноразовым» страницам типа лендингов или индусам-фрилансерам, которые подписались на работу по дизайну-вёрстке за фиксированную оплату.


      1. Luzinov
        15.06.2025 19:39
        #28440002

        Css модули придумали для jquery, когда не было компонент. Сейчас переиспользуемость происходит на другом уровне.


        1. artptr86
          15.06.2025 19:39
          #28441110

          Для переиспользуемости был придуман сам CSS, а CSS-модули были придуманы для инкапсуляции стилей.


  1. unv_unv
    15.06.2025 19:39
    #28439378

    TailwindCSS предлагает верстать не сущностными именами классов, а чисто утилитарными. Вместо h1, h2, у тебя span'ы с мусорными классами. Ну это же моветон. Быстро наговнокодить — это же не подход. Это же write-only, это невозможно нормально поддерживать и развивать.


    1. Itsyxon Автор
      15.06.2025 19:39
      #28441192

      Будем честны, "быстро наговнокодить" можно и без tailwind'а.

      Этот термин вообще, скорее, не про инструмент, а про человека.


    1. JerryI
      15.06.2025 19:39
      #28441590

      Не во всем согласен. Это опять зависит от разработчика. H1,h2 заголовки, а tailwind дает просто размеры шрифтов. Все, что крупное не всегда заголовок и т.д. Возможно этот пример просто неудачный.

      Tailwind при правильном подходе позволяет верстать и тестировать быстрее и не в ущерб качеству. Это вопрос стиля и подхода к дизайну и верстке, и не про supertool. Dark styles решаются быстрее «условными классами» и многие другие вещи. Я комбинирую tailwind с обычными классами и пока все очень предсказуемо, изменяемо и расширяемо.


  1. ImagineTables
    15.06.2025 19:39
    #28439382

    Надо понимать, что одно дело — страница для очередного стартапа из тех, которые закрываются раньше, чем о них успеет написать Слава Рюмин. Для них говнокод это нормально. Давайте, бахайте оформление тейлвиндом и т.д. За соответствующий гонорар. А ещё лучше не мудрите, а берите готовую страницу за доллар с yourfreewebtemplatenew2025.com.

    И совсем другое — UI, с которым будут работать сотни тысяч юзеров или больше. Там требования к качеству совсем другие. Я лично пришёл к тому, что вообще любая утилита — это плохо, это очень плохо. Маркируйте разметку строго семантически, а обобщения реализуйте через миксины, а не утилиты. Будет чистый и понятный код без проблем в виде DRY violations и прочего шит-кода.

    И поверьте, CSS вынесли в отдельный DSL и отдельные файлы не дураки. Вы бы пописали код в доисторическую эпоху с атрибутами color или width, сразу бы поняли, от чего мы ушли, и к чему тащат нас зумеры со своими тайлвиндами.


    1. Itsyxon Автор
      15.06.2025 19:39
      #28441190

      Если мы говорим про гигантский проектище с миллионами строк кода, то даже там сложно выйти за пределы DRY.

      Tailwind предоставляет apply, который как раз помогает этого избежать доступным образом.

      А CSS и его препроцессоры — нет, увы. Всё равно будет лишний CSS и переиспользование.


  1. cmyser
    15.06.2025 19:39
    #28439532

    Очень советую почитать про $mol

    Очень много годных решений там уже сделаны


    1. nin-jin
      15.06.2025 19:39
      #28440510

      Ну, кстати, да, статически типизированные каскадные стили, стейт менеджмент, кастомизируемость компонент и zero-config окружение разработчика там просто офигенные.


  1. Spaceoddity
    15.06.2025 19:39
    #28439674

    Просто в отрасль хлынул огромный поток мимокрокодилов. CSS они не знают (ну иъ наверное сразу ввели в курс дела - что CSS это фигня и вообще не ЯП и даже внимания вашего не стоит), вот до сих пор и обмазываются всяким непотребством... Ещё и других призывают))


    1. Nyanny
      15.06.2025 19:39
      #28439692

      Не только в этом дело. Точнее, мимо крокодилы в отрасли - да, но не как раньше.

      Дело ещё в LLM.

      По какой-то причине LLM обожают Tailwind и "предпочитают" делать код на нем.

      Claude вообще использует Tailwind по-умолчанию. Иной раз, даже когда указан стек пакетов, например, Mantine или чистый HTML/CSS, он все равно тащит Tailwind. Нужно добавлять в промт отдельное предложение "НЕ ИСПОЛЬЗУЙ TAILWIND".

      Остальные LLM тоже предпочитают Tailwind, хоть и не так фанатично.


      1. artptr86
        15.06.2025 19:39
        #28440864

        Так это уже следствие хайповой популярности. Больше репозиториев с тейлвиндом на гитхабе — больше база для обучения LLM. То же самое с питоном, который у чатгпт — язык по-умолчанию.


    1. Itsyxon Автор
      15.06.2025 19:39
      #28441174

      Вы можете трактовать это любым удобным вам способом))
      Напротив, я знаю, что такое Legacy-код и CSS, особенно с древних Wordpress + JQuery сайтов.

      И, когда я перешёл на Tailwind, это было облегчением и переломным моментом))

      Ну, а свою "неспособность следить и подхватывать тренды" не нужно как-то трактовать иначе, тем более винить в этом третьего))


      1. artptr86
        15.06.2025 19:39
        #28441210

        То есть этап CSS Modules вы явно пропустили?


  1. DmitriiMikhailov
    15.06.2025 19:39
    #28439736

    От проекта зависит. Если на вас давят сверху и подгоняют - вы будете использовать любые инструменты что бы уложиться в дедлайн. В таком случае лучше разработать что бы работало, чем быть уволенным и писать великолепно оптимизированные pet проекты дома. Большинству проектов не нужны уникальные стили, нужно просто получить данные из БД, обработать и записать обратно. Если проект супер уникальный, у вас много свободного времени и бюджета, то можно разработать свои CSS классы, но большинство заказчиков не готовы за это платить, особенно если вы берете с них $100 в час :D


  1. viacheslav_ustinov
    15.06.2025 19:39
    #28440210

    Tailwind и Shadcn удобны только вайбкоддерам - им проще скинуть промптом сразу весь компонент) а в плане оптимизации и работы - очень своебразно, нередко дом-дерево на ТВинд вложеннее, чем нужно обычно

    RTK, упомянутый в тексте, неплох, но тогда уж Tanstack тоже стоит упомянуть, не все хотят тянуть куски редакса в проект, и ТСтэк более агностичен в этом плане, и вроде как посвежее

    Vite появился давно, из свежего теперь RSpack, Turbopack и прочий раст походу) пока писалась статья - на фронтенде, как обычно, всё пытается устареть)


    1. Lezvix
      15.06.2025 19:39
      #28440324

      Vite под капотом использует esbuild и rollup, а rollup в свою очередь использует модный бандлер SWC как раз на Rust.

      Помомо Tanstack есть ещё и SWR от vercel, с размером пакета поменьше и схожей функциональностью


    1. Itsyxon Автор
      15.06.2025 19:39
      #28441166

      Согласен, я хотел упомянуть TanStack. НО.

      В данном посте я ещё сравниваю RTK с Axios, а Tanstack использует axios, поэтому счёл нецелесообразным. Но спасибо за замечение. Обязательно сделаю еще статью про Tanstack.


  1. nihil-pro
    15.06.2025 19:39
    #28440338

    Вредные советы фронтендеру от Григория Остера


  1. nin-jin
    15.06.2025 19:39
    #28440500

    Tailwind легко можно назвать «смертью ручного CSS», и не зря: если присмотреться к современным проектам, начиная от пет‑проектов разработчиков из Индии на видео‑площадках, и, заканчивая новейшими IT‑решениями, почти все они используют Tailwind и охотно советуют им пользоваться.

    shadcn/ui решает эту проблему элегантно — просто копируешь компонент в свой проект и меняешь как угодно, ведь под капотом у него Tailwind.

    Copy/Paste Driven Development? Успехов вам с накатыванием обновлений.

    shadcn/ui — это чистые React‑компоненты без рантайм‑стилей, которые дают быстрый SSR, меньше ререндеров и отсутствие тяжёлых стилей в js.

    Раздутый раз в 10 HTML, и полный ререндер при изменении темы, лейаута и тд.


    1. Itsyxon Автор
      15.06.2025 19:39
      #28441152

      Раздутый раз в 10 HTML, и полный ререндер при изменении темы, лейаута и тд.

      Пруф + аналог, у которого этого нет

      Copy/Paste Driven Development? Успехов вам с накатыванием обновлений.

      По-моему, слишком очевидно, что речь здесь идет про установку самостоятельных компонентов UI в проект и минимизацию бандла, без речи про обновления и тому подобное. Да и причем тут вообще обновления, если мы говорим об использовании готовых UI? По этой логике, всё, что не Golang (где есть пометка о жёстких-нежёстких версиях в .mod файлах, ломающих проект при обновлении) — фигня.

      Я так понимаю, твой комментарий нацелен на пиар YouTube-канала)) Ну что ж, я и не против, собственно))


  1. Hex1s
    15.06.2025 19:39
    #28440974

    Я считаю, что css/scss никто не уничтожил. Всё еще проще и удобней прописывать те же ui компоненты, через них, когда у тебя 4+ варианта кнопок, к примеру. И всё еще зависит от типа проекта, если у вас стартап и вы постоянно проверяете гипотезы, то конечно будет удобней взять tailwind в руки и начать пилить фичи, нежели раскидывать всё по отдельным файлам.


    1. Itsyxon Автор
      15.06.2025 19:39
      #28441162

      Все препроцессоры это прошлый век. Особенно BEM-методология и css-модули.

      Все современные инструменты решают абсолютно все проблемы, которые решали они ранее. Я думаю, есть только одна причина, почему кто-то использует SCSS или CSS-модули — они просто не хотят пробовать ничего нового и работают "по старинке".


      1. artptr86
        15.06.2025 19:39
        #28441202

        Только у Tailwind под капотом тоже препроцессоры для генерации цветовых, размерных и прочих наборов стилей, до кучи и PurgeCSS для вырезания всего лишнего мусора.


      1. shsv382
        15.06.2025 19:39
        #28441342

        Просто те, кто пишут, используя БЭМ и SCSS, умеют грамотно разделять стили и не лепить один и тот же класс в разные места приложения. Легаси, в котором ломаются зависимые стили? А вы попробуйте пофиксить что-то в легаси проекте, использующем Tailwind! Там бывает такая ситуация, когда абсолютно одинаковая километровая лапша стилей приписана разным элементам в разных компонентах, и тупо невозможно найти элемент, который требуется изменить.

        Я знаю, о чем говорю, я был и на легаси проектах, и на Tailwind (сейчас), и я все еще ненавижу Tailwind


      1. Hex1s
        15.06.2025 19:39
        #28441924

        Это не нежелание пробовать что-то новое. Eсть разные инструменты для разных задач, если нужно быстро что-то сверстать это правда, что tailwind незаменим, хотя все еще с интересом наблюдаю как люди прописывают кастомные свойства и тд. Та же группировка состояний чего стоит. Качественно разбитые файлы стилей позволяют разделить восприятие. Чтобы у тебя компонент не превращался в кашу из стилей, особенно если он кардинально меняется на active стейте.


  1. markelov69
    15.06.2025 19:39
    #28441354

    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 возведено в абсолют.