Vite en Turbopack vergelijken binnen hun framework

Voor een bestaande Vite-app is Vite het logische uitgangspunt; binnen Next.js is de ingebouwde bundler Turbopack de eerste optie om te beoordelen. Een snellere code-update alleen rechtvaardigt geen overstap naar een ander framework: dan veranderen mogelijk ook routes, rendering en productie-uitvoer.

Vergelijk daarom drie afzonderlijke wachttijden: de koude start tot een route bruikbaar is, HMR van een opgeslagen wijziging tot de zichtbare update, en de volledige productiebuild. Voor een bestaand project hoort daar een vierde factor bij: het werk om dezelfde functionaliteit na een overstap te behouden. Pas samen laten die factoren zien of snelheidswinst een keuze verandert.

Eerst het framework, dan de bundler

Vite bedient uiteenlopende frameworks. De architectuurbeschrijving van Vite legt uit dat de ontwikkelserver bronmodules op aanvraag via native ES-modules aanbiedt en dat de code voor productie wordt gebundeld. Dat onderscheid verklaart waarom een snelle start van de ontwikkelserver weinig zegt over de duur van de uiteindelijke build.

Turbopack werkt binnen de architectuur van Next.js, waar routes uitvoer voor de browser en de server kunnen vragen. Een Vite-app tegenover een Next.js-app zetten levert daardoor een vergelijking van applicatiestructuren op, niet alleen van bundlers. Zelfs als de pagina’s op elkaar lijken, kunnen rendering, gegevensverwerking en de hoeveelheid code per route verschillen. Een team dat Next.js nodig heeft, wint weinig met een HMR-cijfer van Vite zolang daarvoor de applicatie moet worden omgebouwd.

Koude start en HMR meten verschillend werk

Een wijziging in een Vite-bronmodule werkt door naar de betrokken modules; zo wordt de reikwijdte van HMR zichtbaar.

Bij een koude start telt het moment waarop de gekozen route echt bruikbaar is, niet alleen de melding dat de server draait. Leg vast of caches al gevuld zijn en of afhankelijkheden eerder zijn verwerkt; anders vergelijk je een eerste start met een herstart. Ook de eerste routecompilatie hoort bij de wachttijd als ontwikkelaars daarop moeten wachten voordat ze kunnen werken.

HMR begint bij het opslaan van een wijziging en eindigt wanneer die wijziging in de browser zichtbaar is. Een kleine componentwijziging en een aanpassing in gedeelde code raken mogelijk een ander deel van de applicatie en verdienen daarom afzonderlijke metingen. Noteer bovendien of de bestaande paginatoestand behouden blijft. Een snelle bundlerreactie helpt minder wanneer de ontwikkelaar na iedere wijziging opnieuw door een formulier of route moet navigeren.

Het benchmarkoverzicht van Kunal Ganglani zet een HMR-tijd van 130 milliseconden voor Vite naast een claim dat Turbopack op Vercels eigen codebasis tot 96,3 procent sneller is dan webpack. Dat is geen directe Vite-tegen-Turbopack-meting: de ene waarde is een absolute tijd, de andere een relatieve verbetering tegenover een derde bundler. Zonder dezelfde applicatie, wijziging en meetgrens volgt uit die cijfers geen HMR-winnaar voor een concreet team.

Ook de gebruiksfrequentie verandert het gewicht van de uitkomst. Wie de ontwikkelserver vaak opnieuw start, voelt een trage koude start herhaaldelijk; wie hem laat draaien, wacht vaker op HMR. Daarom zijn beide tijden relevant, maar ze mogen niet tot één snelheidsranglijst worden samengevoegd.

De productiebuild is een eigen vergelijking

Een Next.js-project gebruikt Turbopack ook voor de productiebuild; aangepaste webpack-configuratie vraagt een compatibiliteitskeuze.

Een ontwikkelserver en een productiebuild leveren verschillend werk. De Vite-handleiding voor productiebuilds beschrijft vite build als het commando dat standaard een bundel voor statische hosting maakt. Gebruikt een applicatie een framework bovenop Vite, dan kunnen de eisen aan rendering en uitvoer verder gaan dan die standaardbundel.

Voor Next.js is de productiestatus van Turbopack veranderd. De upgrade-instructies voor Next.js 16 vermelden dat zowel next dev als next build standaard Turbopack gebruikt en dat een aangepaste webpack-configuratie de build kan laten mislukken. Teams kunnen die configuratie aanpassen of expliciet webpack kiezen. Turbopack behandelen als een bundler die uitsluitend tijdens ontwikkeling werkt, zou hier dus tot een verkeerde afweging leiden.

Meet de productiebouwtijd voor de uitvoer die de applicatie werkelijk nodig heeft. Een statische Vite-bundel en een Next.js-build met serveruitvoer beantwoorden niet vanzelf dezelfde vraag. Houd bovendien bundeltijd, typecontrole, tests en overige CI-stappen uit elkaar: een snellere bundler verkort alleen het deel van de pijplijn dat hij uitvoert. De totale tijd tot een inzetbare versie blijft de maat voor het team.

Wat kost de overstap vanuit het bestaande project?

Voor een bestaande Next.js-app ligt een beperkte verandering voor de hand: vergelijk Turbopack met de huidige bundler binnen dezelfde applicatie. De inventarisatie omvat aangepaste webpack-configuratie, loaders, plugins, aliassen en imports buiten de projectroot. Juist zulke afhankelijkheden bepalen of een snellere ontwikkelcyclus meteen beschikbaar is of eerst aanpassingen en regressietests vraagt.

Vanuit een Vite-app is de stap groter, omdat Turbopack hier een overstap naar Next.js meebrengt. Routes, rendering, gegevensverwerking en inzetomgeving worden dan onderdeel van het migratiewerk. De keuze tussen renderstrategieën van frameworks gaat vooraf aan een vergelijking van HMR. Een bundlerwinst kan die extra werkzaamheden alleen dragen als de nieuwe frameworkfuncties nodig zijn of de tijdwinst groot genoeg blijkt.

Een terugverdientijd maakt het verschil zichtbaar: deel de geschatte uren voor migratie en regressietests door de gemeten uren die per week worden bespaard op starts, wijzigingen en builds. In een zuiver hypothetisch voorbeeld kost een aanpassing binnen Next.js acht uur en bespaart zij vijftien minuten per week; het rekenkundige omslagpunt ligt dan na tweeëndertig weken. Kost een overstap van Vite naar Next.js in datzelfde denkbeeldige geval veertig uur bij dezelfde weekwinst, dan wordt dat honderdzestig weken. De voorbeelden zijn geen voorspelling: ze laten zien waarom dezelfde HMR-winst bij een andere migratieomvang tot een andere keuze leidt.