Привет, Хабр! На связи Никита Ли, я Frontend-разработчик в Рунити. Вокруг сборщиков последние годы кипят страсти: большинство боготворит Vite, кто-то экспериментирует с esbuild, а энтузиасты активно продвигают инструменты на базе Rust — прежде всего Rspack и SWC. На фоне этого Webpack нередко называют пережитком, который якобы тормозит развитие команд.

Но жизнь реальных продуктов куда сложнее, чем пишут в соцсетях. Иногда Webpack остается единственным зрелым вариантом. А иногда — мешает и действительно требует замены. В этой статье я попробую разобраться, откуда вообще взялись сборщики и что именно происходит внутри Webpack, насколько современные альтернативы действительно готовы его заменить, почему в Рунити мы осознанно продолжаем использовать Webpack в основных продуктах и в каких случаях смена сборщика действительно имеет смысл, а в каких может обернуться лишней тратой времени и сил без ощутимой выгоды.

Навигация по тексту:

• Как мы вообще дошли до жизни со сборщиками

• Что скрывается внутри Webpack

• Webpack в 2025 году: сильные и слабые стороны

• Альтернативы Webpack и что у них под капотом

• Бенчмарки и популярность инструментов

• Почему мы в Рунити выбираем Webpack

• Но Webpack — не серебряная пуля: когда мы выбираем Vite

• Главный вывод

Как мы вообще дошли до жизни со сборщиками

До 2011 года браузеры не умели работать с модулями. Фронтенд-разработчик подключал десятки <script>-файлов в строгом порядке, а малейшая ошибка ломала всё приложение. Чтобы упростить себе жизнь, сначала разработчики просто объединяли множество файлов в один — это снижало количество запросов к серверу и немного упрощало управление зависимостями. Позже появились минификаторы, которые сокращали размер итогового файла, но сами по себе не решали проблемы структуры проекта. Ситуация начала меняться в 2011 году, когда появился Browserify: он позволил использовать привычный для Node.js подход с require() прямо в браузере и впервые ввел идею явного графа зависимостей для фронтенда.

В 2012 году ситуацию полностью изменил Webpack — он ввел идею графа модулей и единый пайплайн, который:

• ищет зависимости от точки входа;

• прогоняет каждый файл через цепочку преобразований;

• строит итоговый набор чанков;

• оптимизирует их размер и порядок загрузки.

Webpack стал стандартом на долгие годы, потому что позволил подружить JS, CSS, изображения, YAML, Vue/React/TSX, web workers — в одном контролируемом пайплайне.

Что скрывается внутри Webpack

Большинство разработчиков видят только конфиг. Но под капотом у Webpack довольно стройная архитектура.

Основные сущности Webpack 

1. Entry — стартовая точка, с которой начинается обход графа. Module — любой импортируемый файл: JS, TS, SCSS, SVG, YAML.

2. Loader — преобразователь модулей (например, SCSS → JS-модуль со стилями).

3. Plugin — расширение пайплайна (кеширование, оптимизация, анализ бандлов).

4. Output — структура итоговой сборки: чанки, хэши, каталоги.

Как работает пайплайн

1. Разрешение импортов. Webpack превращает import './foo' в абсолютный путь, учитывая алиасы и расширения.

2. Применение loaders. Все не JS-файлы превращаются в JS-модули. Даже SCSS или YAML в итоге становятся JS.

3. Парсинг AST. Webpack анализирует код и извлекает импортированные сущности: import, require, new Worker(), import.meta.url.

4. Построение графа зависимостей. Каждый модуль — узел графа, у которого есть связи, тип и источник импорта. Именно на этом этапе работают tree-shaking и code splitting.

5. Хуки компиляции. Перед каждым шагом Webpack вызывает плагины: beforeCompile, afterResolvers, emit, optimizeChunkAssets и т.д.

6. Генерация чанков. Webpack объединяет модули в чанки, создает хэши, пишет файлы на диск.

Module Federation —  важная часть экосистемы, но не единственная причина востребованности Webpack.

В Webpack 5 появилась поддержка динамического подключения модулей из других сборок, что дало импульс развитию микрофронтенд-архитектур. Позже сама идея Module Federation вышла за рамки Webpack и превратилась в самостоятельное направление — с отдельными реализациями, инструментами и плагинами для разных сборщиков. Поэтому нельзя сказать, что именно эта технология «держит Webpack на плаву». Скорее, Webpack остается востребованным благодаря зрелости экосистемы, предсказуемому поведению и тому, что в нем уже существует стабильная и проверенная временем реализация сценариев, связанных с распределенными сборками. Ни один сборщик сегодня не предоставляет столь же зрелую реализацию.

Webpack в 2025 году: сильные и слабые стороны

Плюсы

1. Гибкость.
   Поддерживает любые форматы: YAML, SVG, GraphQL, TS, Vue, React, web workers, кодогенерацию — что угодно, если у вас есть на это loader.

2. Module Federation.
   Пожалуй, самая зрелая и надежная реализация микрофронтендов.

3. Оптимизации.
   Кеширование, инкрементальная сборка, tree-shaking, code splitting, многопоточность.

4. Экосистема.
   Тысячи готовых плагинов и лоадеров, которые решают любые задачи.

5. Надежность.
   Прогнозируемое поведение, огромное комьюнити, множество battle-tested практик.

Минусы

1. Высокий порог входа.
   Разобраться в конфигурации Webpack непросто: почти все конфиги громоздкие, требуют глубокого понимания механики сборки и не всегда прозрачно объясняют, что происходит на каждом этапе.

2. Сложность поддержки.
   Со временем конфиги обрастают кастомными лоадерами, исключениями и историческими решениями. В больших проектах любое изменение приводит к риску сломать цепочку сборки, поэтому правки требуют осторожности.

3. Низкая скорость разработки.
   Dev-сервер запускается медленно, а пересборка крупных проектов может занимать десятки секунд, что снижает комфорт разработки по сравнению с современными быстрыми сборщиками.

Альтернативы Webpack и что у них под капотом

Vite
Vite стал популярным благодаря очень быстрому запуску дев-сервера и простому порогу входа. Он использует нативные ES-модули в браузере и esbuild для быстрой трансформации кода, поэтому изменения отображаются почти мгновенно. Конфигурация компактная, понятная и хорошо подходит для современных SPA.

Однако у Vite есть особенности, которые важно учитывать в сложных проектах. Поддержка Module Federation в экосистеме Vite уже доступна, но в отличие от Webpack она опирается на отдельные плагины и развивается независимо. Поэтому при сложной архитектуре могут возникать сценарии, которые требуют дополнительной настройки или обходных решений. Существенная разница между дев-режимом и продакшеном связана с тем, что финальная сборка выполняется через Rollup: часть оптимизаций и поведения модулей проявляется только на этапе продакшена, из-за чего отдельные ошибки обнаруживаются позже. В результате в реальных проектах нередко приходится учитывать особенности Vite и Rollup, чтобы добиться стабильной конфигурации.

esbuild
esbuild привлекает прежде всего высокой производительностью: инструмент написан на Go и обрабатывает проекты значительно быстрее большинства существующих сборщиков. Он предоставляет поддержку TypeScript, JSX, tree-shaking и минификацию без дополнительных плагинов, что удобно для вспомогательных задач и быстрой упаковки кода.

Но у esbuild есть ограничения, которые делают его неполноценной заменой Webpack или Vite для крупных интерфейсов. В нем отсутствует полноценный HMR, нет поддержки Module Federation, а экосистема плагинов заметно меньше. Это хороший выбор для инструментов, CLI-утилит или сервисных задач, но не для сложных приложений с несколькими точками входа и развитой архитектурой.

Rollup
Rollup хорошо подходит для задач, где важен максимально чистый и компактный итоговый бандл. Он оптимизирует дерево зависимостей эффективнее большинства инструментов и считается удобным решением для библиотек и npm-пакетов. Его конфигурация прозрачная, а итоговый код обычно легко читается.

Но Rollup ориентирован именно на сборку библиотек. Для приложений с динамическими загрузками, сложными ресурсами и микрофронтенд-архитектурой он требует значительных доработок и быстро упирается в ограничения. Он не предоставляет удобного дев-сервера и не подходит в качестве основного сборщика для больших интерфейсов.

Parcel
Parcel позиционируется как «zero-config» сборщик: он сам определяет, как обрабатывать разные типы файлов, и позволяет получить рабочий результат без ручной настройки. Для небольших проектов или прототипов это действительно ускоряет старт разработки.

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

Rspack
Rspack — молодой сборщик на Rust, который стремится предложить совместимость с Webpack при значительно более высокой скорости. Он использует движок SWC для трансформации кода и действительно сокращает время сборки в несколько раз. Благодаря сходству с Webpack-конфигами миграция часто выглядит проще, чем на Vite или esbuild.

Но Rspack всё еще развивается. Экосистема ограничена, документация неполная, и не все плагины Webpack работают без модификаций. Инструмент подает большие надежды, но к его использованию в ответственных продакшн-сборках пока стоит относиться осторожно.

Бенчмарки и популярность инструментов

Производительность
Сравнительные тесты сборщиков демонстрируют ощутимый разрыв между поколениями инструментов. Бандлеры на Rust и esbuild, написанный на Go, обрабатывают проекты значительно быстрее Webpack — в некоторых сценариях время сборки сокращается в разы. Причина в архитектуре: параллельная обработка, нативные бинарные операции и отсутствие узких мест, характерных для сборщиков, работающих в среде Node.js.

При этом скорость — не единственный критерий. Webpack остается стабильным и предсказуемым инструментом, особенно в проектах со сложной архитектурой, микрофронтендами, кастомными лоадерами и исторически развивающейся конфигурацией. В таких условиях преимущества быстрых сборщиков нередко нивелируются дополнительной сложностью миграции или ограничениями экосистемы.

Популярность
Если смотреть на динамику npm-скачиваний, в 2025 году лидером по темпам роста и абсолютным значениям стал esbuild: его используют многие современные инструменты, включая Vite, а также экосистемы Vue, Svelte и новые генераторы проектов для React. Следом идут Vite и Webpack, которые сохраняют высокую базу пользователей.

В то же время статистика показывает:

• еще в начале 2024 года Webpack удерживал позиции лидера по скачиваниям, но постепенно начал уступать более легким и быстрым инструментам;

• Parcel по количеству скачиваний выглядит незаметным, однако по звездам GitHub видно, что у него есть лояльная аудитория, чаще всего — разработчики небольших проектов и прототипов;

• Vite за несколько лет собрал больше звезд, чем Webpack, и стал наиболее востребованным инструментом по вовлеченности сообщества;

• Rspack активно растет, привлекая разработчиков скоростью и частичной совместимостью с Webpack, но пока не сформировал зрелую экосистему и отстает по числу пользователей.

Статистика npm и GitHub важна не сама по себе: она отражает, насколько активно инструменты тестируются в разных сценариях и насколько быстро находятся решения для возникающих проблем. Поэтому зрелость Webpack по-прежнему остается одним из его ключевых преимуществ, даже несмотря на снижение темпов роста.

Почему мы в Рунити выбираем Webpack

Теперь — самое интересное: практический опыт. Наш основной продукт — большой монорепозиторий на Nx, в котором существуют:

• несколько микрофронтендов;

• shared-библиотеки и конфиги;

• Vue 3, TypeScript, GraphQL, кодогенерация;

• YAML, SVG и множество внутренних форматов;

• динамическая загрузка частей приложения.

Ниже — причины, по которым для некоторых проектов мы всё еще выбираем Webpack.

1. Нам нужны зрелые микрофронтенды
Module Federation в Webpack стабилен, проверен и предсказуем. Аналог в Vite — плагин, который в сложных сценариях ведет себя нестабильно. Для нас важнее надежность цепочки, чем минимальное время старта dev-сервера.

2. Кастомные лоадеры, которые писать заново очень не хочется
За годы мы накопили набор собственных loaders, решающих специфические задачи: работа с конфигами, GraphQL-схемами, внутренними файловыми форматами, кодогенерацией. Переносить их на другой сборщик = переписывать с нуля.

3. Не все проекты требуют смены сборщика
В инфраструктуре любой компании есть решения, которые стабильно работают и поэтому не нуждаются в оперативной переработке. Часть наших внутренних сервисов использует более ранние версии Webpack или работает в стеке, где переход на новый сборщик не дает ощутимых преимуществ. В таких случаях мы осознанно не запускаем миграцию: она требует времени и ресурсов, а реальной пользы для продукта не принесет. Вместо этого мы концентрируем усилия на тех направлениях, где изменения действительно улучшают качество разработки и скорость поставки.

4. Webpack стабилен и предсказуем
В нем огромный набор проверенных решений на любые случаи: HMR, code splitting, кэширование, анализирующие плагины, контроль структуры чанков. Это инструмент, в котором знаешь, чего ожидать.

5. Нам важен полный контроль
Webpack дает возможность управлять буквально всем: порядком чанков; схемой кеширования; структурой выходных файлов и оптимизацией под конкретную инфраструктуру. Поэтому он подходит для продуктов с глубокими требованиями к сборке.

Но Webpack — не серебряная пуля: когда мы выбираем Vite

Несмотря на всё вышенаписанное, мы не держимся за Webpack как за реликт. Для новых проектов вне монорепозитория, где не нужны микрофронтенды или глубокая кастомизация, мы сразу берем Vite — ради удобства разработки. Часть старых проектов тоже успешно переехала с Webpack 4 на Vite.

Что выбрать разработчику

Простой ориентир:

• SPA приложения
  простые → Vite
  сложные / микрофронты → Webpack или Rspack

• Инструменты, CI, быстрая упаковка
  → esbuild

• Библиотеки и npm-пакеты
  → Rollup

• Pet-проекты, MVP, хакатоны
  → Parcel

• Нужен Webpack, но быстрее?
  → Rspack (пока считается молодым инструментом, поэтому используем, но осторожно)

Главный вывод

Не спешите выкидывать Webpack. Сначала ответьте на один вопрос: «Какая конкретная проблема меня заставляет мигрировать?» Если ответ: «все так делают» или «хочу Rust»,  вы рискуете потратить месяцы на переписывание, не получив ощутимых выгод. Если же проблема реальна — тогда миграция оправдана. Но в большинстве сложных продуктов Webpack остается наиболее зрелым, предсказуемым и универсальным решением.

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