Vite – godny następca Webpacka? Plusy i minusy obu rozwiązań

Artykuł ten wyjaśnia, czym jest wspomniany w tytule Vite, krótko wprowadzi w temat bundlowania oraz postara się odpowiedzieć na pytanie, czy warto odejść od Webpacka. Skupię się na porównaniu Webpacka z Vite, ukazaniu zalet oraz wad obu rozwiązań. Zapraszam do czytania 🙂

Czym jest bundler?

Bundler jest narzędziem wręcz niezbędnym w dzisiejszym web developmencie. Pozwala on na komfortową pracę z kodem w językach niewspieranych domyślnie przez przeglądarkę, jak np. Typescript czy SCSS oraz potrafi dostosować naszą aplikację pod wersję produkcyjną lub deweloperską. W przypadku wersji deweloperskiej, zapewni nam m.in. dostęp do szybkiego przeładowywania strony podczas zmian oraz pozwoli debugować kod, który napisaliśmy dzięki source mapom. W przypadku wersji produkcyjnej, kod zostanie odpowiednio zoptymalizowany i zunifikowany, przez co aplikacja będzie działać wydajniej.

Aktualnie najczęściej spotykanym bundlerem jest Webpack. Jego popularność jak najbardziej działa na jego korzyść, gdyż wsparcie społeczności wokół narzędzia jest nieocenione. 22 miliony pobrań tygodniowo z repozytorium NPM to imponująca suma. Rynek jednak nie lubi monopolistów, więc powoli rozpycha się nowa technologia – Vite. Stara się ona rozwiązać jedną z bolączek Webpacka, a mianowicie czas bundlowania. W dodatku ma również inne ciekawe cechy do zaoferowania. Czy przyszłość dla Vite okaże się łaskawa?

Zobacz też

Frontend Angular vs React. Która z technologii jest wydajniejsza?

Vite a Webpack – podstawowe różnice

Vite, jak dowiadujemy się na oficjalnej stronie bundlera z francuskiego oznacza “szybki”. Już od samego początku twórcy sugerują nam, na czym im najbardziej zależy, a jest to czas programisty. Aplikacje internetowe (czasy, kiedy używaliśmy definicji “strona internetowa” już dawno minęły…) robią się coraz bardziej ambitne, a co za tym idzie – coraz bardziej pamięciożerne. Webpack niestety jest bardzo podatny na wielkość bundla, ponieważ za każdą zmianą bierze wszystkie nasze zależności i cały kod źródłowy i przetwarza to na jeden potężny plik JavaScript, który następnie jest serwowany do serwera. W efekcie stworzenie takiego bundla może trwać w ekstremalnych przypadkach nawet parę minut! Nawet stosując takie dobrodziejstwa, jak Hot Module Replacement, przeładowanie strony może trwać kilkanaście sekund. To wciąż sporo.

W tym momencie pojawia się on – cały na biało – Vite z całkowicie innym podejściem do problemu. Najpierw tworzy się serwer, a następnie dzieje się bundlowanie paczek. Istotne jest to, że do samego procesu bundlowania używa esbuild – jest to narzędzie do procesowania bundla napisane w języku Go – dużo bardziej wydajne niż domyślne przetwarzanie Webpacka oparte o JavaScript. Na swojej stronie twórcy chwalą się, że potrafi być od 10 do 100 razy szybszy!

A to jeszcze nie wszystko, jeśli chodzi o przyspieszenie developmentu. Vite domyślne dzieli kod na części, dzięki czemu wchodząc pod daną ścieżkę, nie ściągamy od razu wszystkich zależności, lecz tylko te, które są akurat potrzebne. W dodatku twórcy chwalą się mechanizmem pre-bundlingu, który wykonuje się na zależnościach (głównie chodzi o moduły NPM), które przecież nie są zbyt często zmieniane. Vite używa również natywnych modułów (ESM). Dużo teorii, więc sprawdźmy jak to wygląda w praktyce!

Założenia testu porównawczego

Aby porównać Webpacka z Vite, zdecydowałem się na stworzenie projektu frontendowego opartego o bibliotekę React. Twórcy Reacta polecają używanie create-react-app, który jest gotowym skryptem tworzącym strukturę projektu opartą o Webpacka. Będzie to prosty sposób na użycie Webpacka bez zabawy z jego konfiguracją (to mógłby być materiał na osobny artykuł :)). W przypadku Vite będę posiłkował się przygotowanym przez twórców szablonem, który zawiera konfigurację gotową do rozpoczęcia pracy z Reactem. Następnie dodam do projektu parę cięższych bibliotek i opiszę swoje spostrzeżenia, jeśli chodzi o komfort pracy.

Vite – tworzenie projektu

Aby stworzyć reactowy projekt wraz z typescriptem oparty o bundler Vite, używamy następującej komendy (zakładając że yarna mamy już wcześniej zainstalowanego):

yarn create Vite my-vue-app --template react-ts

I tutaj już pierwsze zaskoczenie… Stworzenie projektu zajęło około 1 sekundy! Niestety czar trochę prysł, gdy okazało się, że moduły NPM nie zostały zainstalowane od razu i trzeba było je doinstalować ręcznie (komenda yarn install w folderze nowo utworzonego projektu). Sam proces dodania zależności zajął około… 5 sekund. Jak sobie poradzi Webpack pod postacią create-react-app (CRA) ?

Create React App – tworzenie projektu

Komenda do stworzenia analogicznego projektu (react + typescript) to:

yarn create react-app my-app --template typescript

Skrypt tworzący projekt, czyli create-react-app tworzył się zdecydowanie dłużej. Fakt faktem proces był bardziej zautomatyzowany, ponieważ wszystkie zależności zostały zainstalowane od razu. Proces trwał jednak około 40 sekund. Różnica jest spora, ale nie uprzedzajmy faktów. Sam proces tworzenia wykonuje się tylko raz – zobaczymy, jakie różnice występują przy samej pracy nad projektem.

Vite – Praca nad projektem

Czysty projekt startuje w czasie… 200ms. Jest to zasługa wspomnianego wcześniej mechanizmu bundlowania paczek dopiero po załadowaniu aplikacji. Sama aplikacja jednak również ładuje się natychmiastowo. HMR (Hot Module Replacement) działa wyśmienicie – czas przeładowania strony jest wręcz pomijalny. Co się jednak stanie jeśli dodamy parę ciężkich paczek do naszego projektu?

Paczki które mam zamiar dodać to:

• styled-components
• mantine
• threejs
• pixi.js
• moment
• gojs
• lodash
• d3
• monaco-editor
• HTML2Canvas

Są one całkiem popularne na NPM i nie są również zbyt lekkie (przekrój od niecałego megabajta do aż trzydziestu). W realnym projekcie może być ich sporo więcej, lecz biorąc pod uwagę założenia Vite, nawet przy takiej ilości zależności, różnica w szybkości w porównaniu z Webpackiem powinna być już zauważalna. Zanim jednak przejdę do sprawdzenia różnic pomiędzy czystym projektem a projektem z dodanymi zależnościami, szybko zaprezentuję aplikację.

Jest ona bardzo prosta i głównie zawiera domyślnie zdefiniowane komponenty pochodzące z wcześniej wymienionych bibliotek. Link do repozytorium znajdziecie tutaj. Poprzez kliknięcie na odpowiedni przycisk, wyrenderuje nam się zawartość komponentu. Jak zatem zachowuje się aplikacja z tyloma zależnościami?

Sam start nie uległ zmianie. Ma to jak najbardziej sens, gdyż – jak wcześniej wspomniałem – na starcie uruchamia się tylko serwer bez żadnej operacji bundlowania. Samo bundlowanie odbywa się dopiero wtedy, gdy uruchomimy aplikację w przeglądarce. Ile zatem trzeba odczekać pomiędzy wystartowaniem aplikacji a zobaczeniem jej? Aplikacja jest załadowana praktycznie od razu! Całość zajmuje około sekundy. Jest to naprawdę imponujące. Jak natomiast sprawuje się hot reloading? Otóż jakiekolwiek zmiany w pliku zawierającym wszystkie komponenty (App.tsx) nie są w stanie zdławić Vite i przeładowanie strony jest znów pomijalne. Zauważyłem jednak, że Vite tworzy sobie folder cache, gdzie trzyma przygotowany wcześniej bundle. Mimo jego usunięcia, bundle wciąż tworzy się błyskawicznie i różnica jest wciąż niezauważalna. Zobaczmy zatem, co w Webpacku piszczy.

Oferty pracy z

Create React App – praca nad projektem

Start czystego projektu trwa już nieco dłużej, bo około 7 sekund bez cache. HMR, tak jak w przypadku Vite również jest błyskawiczny, co nie powinno być wielkim zaskoczeniem z racji tego, że do projektu jeszcze nie zostało nic dodane. Spróbujmy więc dodać te same biblioteki, co w przypadku Vite.

Jako że CRA oparte o templatkę typescriptową, jest dość restrykcyjne, jeśli chodzi o poprawność kodu typescriptowego – niektóre wybrane biblioteki wymagały ode mnie małej gimnastyki. Domyślnie CRA nie pozwala niestety na żadne zmiany w Webpacku, więc informacje o błędach typescriptowych, które nie wpływają na samo działanie aplikacji, były ciągle widoczne i nie dało się ich łatwo ukryć. Rozwiązania tego problemu są dwa. Pierwsze z nich (i bardziej żmudne) to naprawienie błędów poprzez poprawne otypowanie kodu. Drugą opcją jest umieszczenie komentarza w pierwszej linii pliku powodującego problemy:

// @ts-nocheck

…który pomija sprawdzanie błędów typescriptowych. Oczywiście nie zalecam tego rozwiązania, gdyż typescript z reguły ma pomagać developerom, więc błędy są w zdecydowanej większości przypadków uzasadnione. Zdecydowałem się więc na pierwszą opcję. Następnie sprawdziłem, jak szybko aplikacja startuje oraz odświeża się po zmianie w pliku (App.tsx) analogicznie jak w przypadku Vite.

Start aplikacji wzrósł do około 21 sekund bez cache. Z cache start aplikacji wyniósł około 5 sekund. Czas hot reloadu natomiast podchodzi już pod około pół sekundy. Czy to dużo? Biorąc pod uwagę, że hot reload w Vite jest wciąż niezauważalny, można rzec, że całkiem sporo. Skalowalność w tym wypadku ma spore znaczenie i mimo nie aż tak dużej ilości paczek różnica ewidentnie istnieje.

Vite – co jeszcze ma do zaoferowania poza szybkością?

Twórcy chwalą się również prostotą konfiguracji. Vite jest całkowicie otwarty na jakiekolwiek modyfikacje poprzez system pluginów. Domyślnie wspiera m.in. typescripta, ładowanie stylów czy hot reloading. CRA natomiast jest warstwą abstrakcji nad Webpackiem. Nie jest to zrobione bez celu. Możemy dostać się do pełnej konfiguracji poprzez komendę “yarn eject”, jednak dostajemy aż 700 linii nowego kodu. Co prawda większość jest dość dobrze wytłumaczona w komentarzach, jednak na pierwszy rzut oka może być to przytłaczające. Natomiast póki co Vite nie ma aż tylu pluginów, co Webpack, więc w niektórych sytuacjach projektowych może być to ściana nie do obejścia. Mimo mniejszej popularności od Webpacka, Vite wciąż ma około milion pobrań tygodniowo i liczba ta dość szybko rośnie. W styczniu tego roku pobrań było dwa razy mniej.

Czy warto odejść od Webpacka? Podsumowanie

Patrząc na te dwie oczywiste zalety Vite, czyli jego szybkość oraz prostotę, można by rzec – warto. Jednak nic nie jest czarno-białe, dlatego warto się nad tym chwilę zastanowić.

Nada się na pewno do prototypowania aplikacji, jak i większych projektów, w których mamy mnóstwo zależności – projekt powinien reagować na zmiany bardzo szybko, gdzie w przypadku Webpacka może być z tym problem. Jednak Vite nie jest kompletnym zastępstwem Webpacka. W wielu projektach, które ciągną się już od lat, konfiguracja Webpacka może być tak skomplikowana, że próba przejścia na Vite może okazać się problematyczna. Niektóre moduły NPM po prostu są ściśle związane z Webpackiem. Vite na pewno jest bardzo ciekawą opcją dla deweloperów zaczynających swoją przygodę z frontendem i chcącym skupić się tylko i wyłącznie na pisaniu aplikacji. CRA również jest bardzo przyjazne, jednak warto zaznaczyć, że jest to warstwa abstrakcji nad Webpackiem i cała jego złożona konfiguracja jest ukryta przed deweloperem.

Tak naprawdę losy Vite zależą od społeczności. Jeśli dostatecznie dużo pluginów, które istnieją dla Webpacka, zostanie przeportowanych dla Vite, w wielu projektach będzie można zacząć migracje. W przypadku braku sytuacji, które mocno mogą opóźnić czas dostarczania produktu (tj. nieistniejące pluginy i przymus pisania własnych czasochłonnych rozwiązań), Vite może znacząco usprawnić pracę nad projektami. W każdym razie, technologia na pewno zasługuje na uwagę i warto obserwować jej przyszłość.

Zobacz też

Backend Czy Fullstack ma łatwiej na rynku pracy? Devdebata