Vite 8 er ute, og produksjons-buildene er dramatisk raskere. Linear gikk fra 46 sekunder til 6, og ifølge Vite selv er hastighetsøkningen mellom 10x og 30x. For team som releaser ofte, er build-tid en av de viktigste flaskehalsene. I store prosjekter rekker du gjerne en lengre kaffepause før den er ferdig. I dette innlegget tar jeg et dypdykk i hva Vite-teamet har gjort, hvorfor det fungerer, og hvorfor det har større impact i en LLM-drevet utviklerhverdag enn det hadde hatt for et par år siden.
Vi starter med hva Vite egentlig er, ser deretter på hvorfor “bare skriv det i Rust” er vanskeligere enn det høres, dykker så ned i hvordan OXC-teamet faktisk klarte det, og runder av med koblingen til agentisk utvikling. Start en build, hent deg en kopp kaffe, så er den ferdig omtrent når du er ferdig med innlegget.
Så hva gjør Vite egentlig?
Vite er en dev server og et build tool for moderne webapper. I korte trekk leverer det to ting: en rask dev server og en optimalisert prod build.
Da Vite ble lansert, løste det et velkjent problem. Hele applikasjonen måtte bundles og bygges på nytt for hver lokal endring, og jo større prosjektet var, jo mer tid gikk med på det. Vites grep var å serve modulene direkte til nettleseren som ES modules. Det gir tilnærmet umiddelbar oppstart av dev serveren, og modulene lastes via HTTP først når de faktisk trengs. Til prod builds har Vite historisk brukt Rollup, som lager ett optimalisert bundle med tree-shaking og code splitting. To ulike verktøy for to ulike faser.
Vite 8 bytter ut begge med én ny bundler skrevet i Rust: Rolldown. Plugin-APIet er fortsatt Rollup-kompatibelt, så for de fleste team er oppgraderingen en versjonsbump.
Hvorfor løsningen ikke bare er å skrive alt i Rust
Å skrive bundleren i Rust gir store gevinster tidsmessig. Men når teamet hos OXC analyserte hvor tiden faktisk går i en build-pipeline, var det åpenbart at kostnaden ikke ligger i selve bundleren, den ligger i alle pluginene som kjører rundt den. Vite støtter et enormt antall plugins som stort sett er skrevet i JS. ESLint alene har over 250 000 plugins publisert på npm, og det sier seg selv at det er umulig å skrive om alle til Rust. Hver plugin er noens jobb, noens hobby, noens side-business. “Bare bytt verktøy” høres greit ut til du må overbevise tusen vedlikeholdere om å gjøre jobben gratis. Hovedutfordringen var derfor å finne en måte å speede opp kjøringen av JS-baserte plugins, ikke å erstatte dem.
Hvordan OXC løser det
OXC-teamets løsning består av tre grep som bygger på hverandre.
1. Delt Abstract Syntax Tree
Abstract Syntax Tree (AST) en strukturell representasjon av koden, som brukes av ulike verktøy. Bundleren traverserer treet for å finne ubrukt kode, linteren for å finne feil, formatteren for å bestemme linjeskift. Historisk har Babel, ESLint, Prettier og TypeScript hver sin parser og sitt eget AST. En typisk fil parses 4–5 ganger per build. Med OXC endres dette ved at alle verktøy bruker samme tre.
2. Rust og arena allocation
AST-er er enorme. Et mellomstort TypeScript-prosjekt produserer rundt 29 MB, med over 100 000 objekter allokert og frigjort per fil. I JavaScript betyr det GC-pauser, cache-misses og hidden class-overhead. V8 bestemmer hvor objektene ligger, ikke deg.
Rust løser dette med arena allocation: én stor minneblokk, alle noder tett etter hverandre, frigjør hele blokken i én operasjon. Tenk én termoskanne mot 100 000 papirkopper. Det er minne-kontrollen som gir gevinsten, ikke at koden er kompilert.
3. Del minnet direkte istendefor å konvertere fra Rust til JS
Men esbuild og SWC løser allerede punkt 1 og 2, og de er raske. Når Rust-parseren er ferdig, må AST-et leveres til JS-siden så plugins kan jobbe med det. OXC-teamet delte et eksempel på CityJS: 96 ms prosessering i Rust, 1360 ms på å konvertere resultatet til JS. Det betyr at hele 93 % av tiden gikk til konvertering.
OXCs grep er å la være å konvertere. I stedet eksponeres Rust-minnet direkte som en ArrayBuffer, og JS-siden leser bytes lazy. Det er som å låne ut originalboken i stedet for å fotokopiere den. Hvis en plugin bare leser 1 % av nodene, materialiseres bare den prosenten og resten forblir bytes uten kostnad.
Disse tre forbedringene gir 10–30x raskere prod-build, uten å begrense bruken av eksisterende plugins.
Noen tall fra store aktører:
- Linear: 46 s → 6 s
- Beehiiv: −64 %
- Mercedes-Benz.io: −38 %
Oxlint kjører i CI hos Airbnb (126 000 filer på 7 sekunder), samt hos Shopify, ByteDance og Mercedes-Benz.
Hvor bor kostnaden, egentlig?
Når et system blir for tregt, er det naturlig å se etter den dyreste operasjonen og prøve å gjøre den raskere. I OXC-tilfellet var det nettopp det som viste seg å være feil sted å lete.
Selve prosesseringen var allerede rask nok. Det som tok tid, var alt som skjedde mellom verktøyene: parsing flere ganger, kopiering av strukturer, serialisering frem og tilbake mellom språk. Løsningen ble derfor ikke å optimalisere disse overgangene, men å fjerne dem.
Det samme gjaldt på økosystem-nivå. Problemet var ikke at JavaScript-verktøy er fundamentalt trege, men at de er mange, modne og umulige å erstatte samlet. Å skrive alt på nytt ville aldri fungert. Å bytte ut kjernen, uten å tvinge resten av økosystemet til å flytte på seg, gjorde det.
Hvorfor dette betyr mer i AI-alderen
Tidligere handlet verktøyhastighet mest om utvikleropplevelse. Nå handler det også om kostnad. En linter som tar litt kortere tid, fører til mindre stopp i utvilklingfyten og en gladere utvikler. I 2026 gjelder det samme, men på et annet nivå. AI-agenter som Claude Code, Cursor og Copilot Workspace kjører i loops: skrive, lint, typecheck, test, lese feilen, justere. Tusen iterasjoner i en lengre agent-session er ikke uvanlig. Med ESLint på 2 sekunder per kjøring blir det 33 minutter ren ventetid. Med Oxlint på 200 ms blir det 3 minutter.
Tidligere viste kostnaden seg som ventetid for utvikleren. Nå viser den seg også som redusert throughput i agentiske workflows med færre iterasjoner, høyere latency og dyrere inferens.
Men den største lærdommen ligger ett nivå høyere. Neste gang du står i et ytelsesproblem eller diskuterer en stor refaktor, ikke spør «hvordan gjør vi dette raskere?» først. Spør heller «hvor bor kostnaden, og hvorfor finnes den?». Det er som regel der de virkelige gjennombruddene starter.
Håper kaffen smakte ☕️
Kilder
- Vite 8 release post: vite.dev/blog/announcing-vite8
- The Register om Vite 8 og Rolldown: theregister.com
- OXC raw transfer design (PR #9516): github.com/oxc-project/oxc/pull/9516
- OXC dokumentasjon: oxc.rs
Hvordan ble Vite så mye raskere i Vite 8? was originally published in Compendium on Medium, where people are continuing the conversation by highlighting and responding to this story.
