Rspack - szybsza alternatywa dla Webpacka?

Rspack to szybsza alternatywa dla Webpacka: bundler napisany w języku Rust, który rozumie niemal tę samą konfigurację i obsługuje większość tych samych wtyczek. Bundler to narzędzie, które przed wdrożeniem łączy setki plików źródłowych aplikacji w kilka paczek gotowych do wysłania do przeglądarki. Na pytanie z tytułu odpowiedź brzmi więc „tak”. Ciekawsze jest to, o ile szybszy, dla kogo i co trzeba zrobić, żeby tę szybkość dostać.

Pytanie zwykle pada w firmach, które mają kilkuletnią aplikację na Webpacku. Budowanie trwa kilka minut, programiści czekają kilkanaście sekund na odświeżenie ekranu po każdej zmianie, a przepisywanie całego procesu na Vite brzmi jak projekt na kwartał. Rspack obiecuje przyspieszenie bez przepisywania. W wielu projektach ta obietnica się sprawdza, choć rzadko w takiej skali, jak na slajdach.

Webpack działa. Kłopot zaczyna się, gdy projekt rośnie

Przez prawie dekadę bundler Webpack był domyślnym wyborem przy budowie aplikacji frontendowych. Jest dojrzały i ma tysiące wtyczek. Nie jest też porzucony: zespół Webpacka opublikował plan rozwoju na 2026 rok, który prowadzi do wersji 6 i obejmuje m.in. natywną obsługę CSS i TypeScriptu. Jego słabością jest architektura. Webpack jest napisany w JavaScripcie i większość pracy wykonuje na jednym rdzeniu procesora. W małym projekcie nikt tego nie zauważa. W aplikacji z kilkoma tysiącami modułów, rozwijanej przez kilka lat, budowanie wersji produkcyjnej potrafi trwać kilka minut, a start serwera deweloperskiego tyle samo.

Najbardziej odczuwalny jest czas odświeżania podczas pracy. HMR, czyli podmiana zmienionego fragmentu aplikacji w przeglądarce bez przeładowania strony, w dużym projekcie na Webpacku może trwać kilka lub kilkanaście sekund. Programista zmienia kolor przycisku i czeka. Kilkadziesiąt razy dziennie.

Drugie miejsce, w którym płaci się za powolny build, to potok CI/CD, czyli automat, który po każdej zmianie w kodzie buduje, testuje i wdraża aplikację. Każda minuta budowania to minuta pracy płatnej maszyny i minuta, o którą później trafia na produkcję poprawka błędu.

Skąd się wziął Rspack i kto za nim stoi

Rspack powstał w ByteDance, firmie, do której należy TikTok. Jej zespoły miały ogromne aplikacje na Webpacku i nie chciały ich przepisywać na zupełnie inne narzędzie. Postanowiły więc napisać bundler, który zachowuje się jak Webpack, ale działa w języku Rust, kompilowanym do kodu maszynowego i wykorzystującym wszystkie rdzenie procesora. Stabilna wersja 1.0 pojawiła się w sierpniu 2024 r. Według zapowiedzi Rspack 1.0 wewnątrz ByteDance korzystało z niego wtedy ponad tysiąc aplikacji, a na zewnątrz m.in. Microsoft, Amazon, Alibaba, Intuit i Discord. W kwietniu 2026 r. wyszła wersja 2.0, a w sierpniu 2.2.

Skalę popularności dobrze oddają pobrania. Przy premierze 1.0 Rspack miał około 100 tys. pobrań tygodniowo z npm, a przy wydaniu Rspack 2.0 już ponad 5 mln. To wciąż mniej niż Webpack czy Vite, ale nie jest to już eksperyment jednej firmy.

Wokół Rspacka powstał zestaw narzędzi nazwany Rstack. Dla firm najważniejszy jest Rsbuild: nakładka, która ukrywa większość konfiguracji i działa podobnie do Vite. Przydaje się też Rsdoctor, który pokazuje, co spowalnia budowanie i co powiększa paczki.

Rspack jako szybsza alternatywa dla Webpacka: ile czasu to realnie daje

Twórcy od początku mówią o przyspieszeniu rzędu dziesięciokrotnego względem Webpacka. To wynik z ich własnych testów, na projektach przygotowanych do porównań. Dużo więcej mówią migracje opisane przez firmy, które nie mają interesu w reklamowaniu narzędzia.

Mews, twórca platformy do zarządzania hotelami, opisał migrację z Webpacka do Rspacka krok po kroku. Budowanie w CI trwało tam 300 sekund. Sama wymiana Webpacka na Rspack skróciła je do 230 sekund. Przyspieszenie o jedną czwartą, nie dziesięciokrotne. Duży skok przyszedł później. Zespół zastąpił Babel, czyli kompilator JavaScript tłumaczący nowoczesny kod na wersję zrozumiałą dla starszych przeglądarek, wbudowanym w Rspack kompilatorem SWC. Czas spadł do 140 sekund. Po wymianie narzędzia do zmniejszania kodu (Terser) również na SWC zostało 80 sekund. Serwer deweloperski zamiast 3 minut startował w 10 sekund, a odświeżanie po zmianie zamiast ponad 10 sekund trwało około sekundy. Rozmiar paczek zmienił się o mniej niż 5%.

Podobny obraz dał Yelp. Według wpisu na blogu inżynierskim Yelpa sama migracja przyspieszyła pełne budowanie o około 25%. Dopiero po włączeniu trwałej pamięci podręcznej i uporządkowaniu tzw. barrel files, czyli plików zbiorczych, które udostępniają dziesiątki modułów z jednego miejsca, średni czas spadł o około 52%.

Wniosek z obu przypadków jest praktyczny. Zysk z Rspacka to nie tylko zasługa nowego bundlera, ale całego łańcucha narzędzi napisanych w Rust. Kto zostawi babel-loader i Tersera, bo „działa”, dostanie ułamek możliwej poprawy.

Co przechodzi z Webpacka bez zmian, a co trzeba przepisać

Konfiguracja Webpacka składa się głównie z loaderów i wtyczek. Loader przetwarza określony typ pliku, na przykład zamienia plik SCSS na zwykły CSS. Wtyczka ingeruje w cały proces budowania, na przykład generuje plik HTML albo raport rozmiaru paczek. Rspack obsługuje prawie wszystkie popularne loadery. Z wtyczkami jest trochę gorzej: według zespołu Rspacka ponad 80% z 50 najczęściej pobieranych wtyczek Webpacka działa albo ma odpowiednik. Część z nich Rspack ma wbudowaną w szybszej wersji, na przykład kopiowanie plików czy wydzielanie CSS. W aplikacjach w React o standardowej konfiguracji migracja często sprowadza się do wymiany kilku pakietów i nazw wtyczek.

Na liście zgodności wtyczek Rspacka są jednak pozycje oznaczone jako nieobsługiwane. W typowych projektach najczęściej przeszkadzają:

• @ngtools/webpack, czyli wtyczkę kompilatora Angulara, przez co starsze projekty na Angular CLI z Webpackiem wymagają osobnej ścieżki,
• critters-webpack-plugin, używaną do wstawiania najważniejszego CSS bezpośrednio do HTML,
• @cypress/webpack-preprocessor, potrzebny przy części testów uruchamianych w Cypressie,
• własne wtyczki firmowe, które korzystają z wewnętrznych mechanizmów Webpacka zamiast z jego publicznego API.

Ostatnia grupa jest najtrudniejsza do oszacowania. Wtyczkę napisaną kilka lat temu przez osobę, której już nie ma w zespole, trzeba najpierw zrozumieć, a dopiero potem przepisać. W projektach na Angularze sprawa jest zresztą prostsza, niż wygląda. Od wersji 17 Angular CLI domyślnie buduje nowe aplikacje esbuildem, a starsze można przełączyć na ten sam mechanizm, więc aktualizacja frameworka często w ogóle usuwa Webpacka z projektu.

Osobno trzeba sprawdzić narzędzia pomocnicze, które też korzystają z bundlera. Storybook, w którym zespoły rozwijają i dokumentują komponenty, może działać na builderze opartym na Rsbuildzie, rozwijanym przez zespół Rspacka.

Rspack, Vite czy Turbopack: który bundler do jakiego projektu

W 2026 r. rynek bundlerów wygląda inaczej niż kilka lat temu. Webpack stracił pozycję domyślnego wyboru, a jego miejsce zajęły trzy narzędzia napisane w Rust. Każde z nich ma swoją niszę i najczęściej to framework decyduje za zespół.

Projekty na frameworku Next.js mają sprawę rozstrzygniętą. Od Next.js 16 domyślnym bundlerem jest Turbopack rozwijany przez Vercel. Istnieje wtyczka next-rspack, rozwijana przez społeczność we współpracy z Vercelem, ale jej autorzy sami określają ją jako eksperymentalną, z ograniczoną wydajnością przy App Routerze.

Dla aplikacji na Next.js naturalnym kierunkiem jest więc Turbopack jako bundler od Vercela, a nie Rspack.

Nowe aplikacje poza Next.js najczęściej startują na Vite, który ma bogaty ekosystem wtyczek i od wersji 8 również bundler napisany w Rust. Vite jako narzędzie do budowania frontendu wymaga jednak zupełnie innej konfiguracji niż Webpack.

Tu leży przewaga Rspacka. Dla istniejącego projektu na Webpacku to najkrótsza droga do szybkiego budowania, bo konfiguracja w większości zostaje. Rspack wygrywa też tam, gdzie firma korzysta z Module Federation, czyli mechanizmu pozwalającego kilku niezależnie wdrażanym aplikacjom współdzielić komponenty w przeglądarce. Architektura mikrofrontendów zbudowana na Webpacku przechodzi na Rspack bez przeprojektowania.

Jak wygląda migracja na Rspack i ile trwa

Czas migracji zależy mniej od wielkości aplikacji, a bardziej od tego, ile w konfiguracji jest nietypowych rozwiązań. Projekt z kilkoma standardowymi wtyczkami przechodzi w 1-3 dni robocze, łącznie z testami. Aplikacja z własnymi wtyczkami, rozbudowaną konfiguracją Babela i kilkoma środowiskami to zwykle 2-6 tygodni.

Przy większych projektach sprawdza się taka kolejność:

1. Pomiar punktu wyjścia: czas budowania lokalnie i w CI, czas startu serwera deweloperskiego, czas odświeżania i rozmiar paczek.
2. Spis loaderów i wtyczek z oceną, które działają, które mają odpowiednik w Rspacku, a które trzeba przepisać.
3. Wymiana Webpacka na Rspack na osobnej gałęzi, bez zmiany reszty narzędzi, i porównanie działania aplikacji w testach automatycznych.
4. Zastąpienie Babela i Tersera kompilatorem SWC jako osobny krok, żeby łatwo było ustalić źródło ewentualnego błędu.
5. Włączenie trwałej pamięci podręcznej w CI i przegląd plików zbiorczych.
6. Wdrożenie na środowisko testowe, a w monorepo przenoszenie aplikacji po kolei.

Punkt trzeci warto zamknąć porównaniem paczek. Rspack dzieli kod inaczej niż Webpack, więc sprawdzamy, czy code splitting, czyli ładowanie części aplikacji dopiero wtedy, gdy są potrzebne, nadal działa tak jak wcześniej. To samo dotyczy tree-shakingu, który usuwa nieużywany kod z paczek wynikowych. Różnica kilku procent w rozmiarze plików jest normalna, ale skok o kilkadziesiąt procent na stronie głównej oznacza, że coś przestało działać.

Rspack 2.0 wymaga Node.js w wersji 20.19 lub nowszej. W starszych projektach oznacza to często aktualizację obrazów budujących w CI, a czasem kilku innych zależności. Takie prace dobrze łączyć z przeglądem architektury i procesów DevOps, bo przy okazji zwykle wychodzi, co jeszcze w potoku da się skrócić.

Jeśli zmiana bundlera jest częścią większego przejścia na nowy stos technologiczny, lepiej zaplanować ją w ramach migracji aplikacji do nowych technologii niż jako osobne zadanie.

Kiedy lepiej zostać przy Webpacku

Nie każdy projekt skorzysta na zmianie. Jeśli aplikacja buduje się w 30 sekund, a wdrożenia odbywają się kilka razy w miesiącu, oszczędność czasu będzie niezauważalna. Ryzyko regresji zostanie. Podobnie jest z projektami w trybie utrzymania, w których zespół wprowadza drobne poprawki raz na jakiś czas. Stabilny Webpack, który ma przed sobą wersję 6, jest tam rozsądnym wyborem na kolejne lata. Migrację warto zrobić wtedy, gdy i tak planowana jest większa przebudowa. Ostrożności wymagają też aplikacje, których proces budowania opiera się na kilku nietypowych, samodzielnie napisanych wtyczkach. Najpierw trzeba je zrozumieć i udokumentować. Często okazuje się, że część z nich nie jest już potrzebna, a porządkowanie takich miejsc to zwykła praca nad długiem technologicznym w projekcie.

Najwięcej zyskują duże produkty rozwijane latami, takie jak platformy SaaS z wieloma modułami czy systemy wewnętrzne z kilkoma aplikacjami w jednym repozytorium. Tam kilka minut na każdym buildzie, pomnożone przez kilkanaście wdrożeń dziennie i kilkunastu programistów, daje realne godziny w miesiącu.

Przy tworzeniu i rozwoju aplikacji webowych decyzję o zmianie narzędzia warto poprzedzić pomiarem, bo dopiero on pokazuje, gdzie naprawdę ucieka czas.