В последнее время язык программирования Rust находится на самом гребне волны хайпа. То тут, то там пестрят такие заголовки: «делаем на раст some_gnu_cli_utility», «Rust‑реализация привычной программы», «давайте перепишем на Rust ВООБЩЕ ВСЁ». Мне и самому очень нравится этот язык, и рост его популярности считаю вполне заслуженным. Несмотря на крутую кривую обучения и весьма высокий порог входа, в Rust правильно сделано если не всё, то почти всё. Многие языки годами и десятилетиями шли к тому, что «крабоводам» предлагалось «из коробки» на заре истории Rust.
Эпоха, когда во фронтенд‑экосистеме раз в неделю появлялся новый JS‑фреймворк, канула в Лету. На дворе 2024-й, теперь раз в неделю появляется новый бандлер, причём зачастую написанный именно на Rust (например, Turbopack, Rolldown, Farm и Mako от китайских товарищей). В этой статье я хочу опробовать в действии наиболее многообещающий из них — Rspack. Он позиционируется как быстрый сборщик, имеющий полную обратную совместимость с Webpack. Разработчики Rspack несколько месяцев назад выпустили стабильную мажорную версию (1.0) и продолжают активно развивать проект.
Что ж, давайте его попробуем. В качестве подопытного кролика возьмём не очередной Hello World, специально заточенный под бенчмарки, а реальный сложный проект, в котором есть:
четыре режима сборки Webpack;
сложная предметная область и, соответственно, сложная логика;
550+ React‑компонентов.
Кстати, вот моя статья, где описывается, как содержать в чистоте конфигурационные файлы на подобного рода «атомоходах».
Что не так с Webpack?
Он медленный, особенно в больших проектах. Чтобы не быть голословным, приведу результаты измерения времени его работы (измерял на рабочем Macbook Pro M1, на машинах послабее будет отрабатывать ещё дольше).
Длительность запуска dev‑сервера: около 25 секунд.
Длительность сборки изменений во время разработки с HMR: около 10 секунд.
Длительность сборки production‑артефактов: примерно 30 секунд.
Согласитесь, ждать почти 10 секунд после каждого сохранения быстро начинает раздражать. Иногда эти секунды кажутся вечностью. Душу разработчика терзает желание хоть как‑то ускорить горячую замену модулей и улучшить developer experience. Как раз недавно я наткнулся на серию статей про Rspack и очень захотел его опробовать в деле.
Приготовление Rspack
Устанавливаем с официального сайта:
$ npm add @rspack/core @rspack/cli -DЗатем, как они рекомендуют, просто заменяем в package.json:
{
"scripts": {
- "serve": "webpack serve",
- "build": "webpack build",
+ "serve": "rspack serve",
+ "build": "rspack build",
}
}Но нетут‑то было. Обещанная полная обратная совместимость с Webapck не такая уж и полная. «Мелким шрифтом» на официальном сайте всё же написано, что некоторые плагины и загрузчики требуют своей собственной конфигурации. Я почти полностью переписал конфигурационные файлы. Заодно был подчистил накопившийся техдолг, так как он блокировал миграцию на Rspack. Мне пришлось:
Обновить версию node.js (с 16.13 на 22.11).
Переделать файлы сборки с commonjs на es6 modules.
Избавиться от babel-loader и ts-loader в пользу swc-loader.
Выкинуть неиспользуемые в проекте части конфигурационных файлов.
Этот рефакторинг конфигов занял у меня три вечера и стоил пять кружек мятного чая.
Дегустация Rspack
Результаты работы сборщика Rspack приятно порадовали. Длительность работы (как сборка production‑артефактов, так и запуск dev‑сервера и HMR) по сравнению с Webpack значительно уменьшилась.
В таблице приведено сравнение результатов работы для разных режимов сборки проекта (стандартное статическое React‑приложение и web‑компонент).
Webpack | Rspack | |
Запуск dev-сервера стандартного приложения | 27,1 сек | 16,5 сек |
Запуск dev-сервера для режима веб-компонента | 24,3 сек | 16,0 сек |
HMR для стандартного приложения | 8,9 сек | 174 мс |
HMR для веб-компонента | 7,8 сек | 153 мс |
Production-cборка статического сайта | 27,4 сек | 15,6 сек |
Production-сборка веб-компонента | 30,4 сек | 18,4 сек |
Однако
Как человек, который родился в конце августа, я просто не мог принять на веру тезисы из лэндинга Rspack и хайп вокруг этой технологии. Поэтому для сравнения я решил довольно тщательно измерить длительность работы Webpack и Rspack. В моём арсенале были такие инструменты измерения производительности как:
Неожиданно SMP указал на наличие проблемы в существующей конфигурации Webpack, которая не только значительно увеличила длительность запуска, но и снизила скорость компиляции во время HMR. Как оказалось, 12 секунд во время запуска dev‑сервера отъедал бесполезный для нас плагин case‑sensetive‑webpack‑plugin. В то же время незаменимый Webpack Bundle Analyzer отрабатывал при каждом изменении в коде, и именно он и вызывал настолько долгий и раздражающий HMR. Выкинув совсем из конфигурации Webpack case‑sensetive‑webpack‑plugin и оставив Webpack Bundle Analyzer только для production‑сборок, я смог почти в два раза сократить длительность запуска dev‑сервера и более чем в 25 раз сократить продолжительность компиляции при HMR. Pull request на удаление этих плагинов из конфигурации моего проекта отправил в ту же минуту.
Будет справедливо привести результаты измерения производительности Webpack и Rspack как с тормозящими процесс сборки плагинами, так и без них.
Webpack (с тормозящими плагинами) | Webpack (без тормозящих плагинов) | Rspack (с тормозящими плагинами) | Rspack (без тормозящих плагинов) | |
Запуск dev-сервера стандартного приложения | 27,1 сек | 11,9 сек | 15,5 сек | 15,9 сек |
Запуск dev-сервера для режима веб-компонента | 24,3 сек | 11,5 сек | 16,0 сек | 16,0 сек |
HMR для стандартного приложения | 8,9 сек | 330 мс | 174 мс | 152 мс |
HMR для веб-компонента | 7,8 сек | 350 мс | 153 мс | 119 мс |
Production-cборка статичного сайта | 27,4 сек | 24,3 сек | 15,6 сек | 17,9 сек |
Production-сборка веб-компонента | 30,4 сек | 31,5 сек | 18,4 сек | 19,5 сек |
Послевкусие
Да, Rspack действительно шустрее, чем Webpack. Но разница, в сравнении с оптимизированной конфигурацией Webpack, совсем не значительная. Даже в большом и сложном проекте. Да, 150 миллисекунд на HMR (у Rspack) — это в целых два раза меньше, чем 300 миллисекунд у Webpack, но конечный разработчик совсем не почувствует этого ускорения. Экономия десяти секунд в длительности работы всего CI/CD-конвейера тоже не играет особой роли. А вот значительное изменение конфигурационных файлов может занять немало времени. Также не исключено, что таким изменением можно внести в проект пару‑тройку багов, которые дадут о себе знать в самый неподходящий момент.
В итоге я не советую переезжать на Rspack только потому, что там под капотом есть владение/заимствование и обработка ошибок при помощи монад. Лучше проверить производительность своей конфигурации Webpack тем же SMP, что‑нибудь неожиданное и интересное наверняка найдётся.
Спасибо за внимание, удачных вам настроек конфигурации, минимума багов и быстрых конвейеров.