Introducing Turbopack, the successor to Webpack.
◆ ~700x faster than Webpack
◆ 10x faster than Vite
◆ Native incremental architecture built with Rust
◆ Support for React Server Components
◆ Support for TS, JSX, CSS & more
Now open-source in Alpha.
Ce parere aveti? Cei care folositi Vite va ganditi sa folositi Turbopack?
Eu folosesc Vite si aveam de gand ca pe viitor sa implementez si Turborepo dar acum ma gandesc la Turbopack si Turborepo.
◆ ~700x faster than Webpack
◆ 10x faster than Vite
Asta sună bine DAR la usecase-urile mele, unde build-ul oricum durează câteva secunde să pornească (watch se face apoi aproximativ instant)… nu sunt foarte convins.
Poate doar dacă are chestii adiacente utile - e.g. config intuitiv pentru care nu pierzi ore săpând prin docs - ar putea fi util. Altfel…
Pare free. Va si ramane asa?
In enterprise conteaza destul de mult treburile astea.
Vercel, prin Next.js v12, a introdus SWC, fiind un replacement la babel
SWC is 20x faster than Babel on a single thread and 70x faster on four cores.
Vad ca tot ei, prin Next.js v13, au introdus Turbopack, care folosete, under the hood, SWC
Cam toate toolchain-urile se vor muta pe Rust / Zig / etc, din cauza performantei.
Nu înțeleg ce fel de business model exista pt. asa ceva, dar maintainer-ul de la Babel a obtinut in 2021 “$4.5 million in seed funding” pt. rome.tools, licensed MIT.
Rome is designed to replace Babel, ESLint, webpack, Prettier, Jest, and others.
Similar este si proiectul oven/bun, scris in Zig. “Oven has raised $7m in funding” (oven.sh).
JS/TS runtime, bundler, transpiler, package manager – all in one.
Cei de la parcel au început să migreze și ei către Rust, parce/lightningcss.
An extremely fast CSS parser, transformer, bundler, and minifier written in Rust.
Niciunul din proiectele de transpile nu le-am putut adapta la un proiect existent.
Vorbesc de esbuild si swc.
De ce ? Jest are spy, spy nu funcționează cu module. (Nu se poate face override la ele conform standardelor ES)
tsc nu urmează strict standardele ES, swc si esbuild da, ceea ce înseamnă că multe ce au funcționat cu webpack cu tsc nu mai funcționează cu swc…
Iar dacă e vorba de ceva precum spy e deal breaker.
Dar nici compilarea la UI nu mi-a funcționat, te distrezi cu schimbarea tsconfigului în alte standarde prost documentate.
De ce sunt sponsorizate așa mult ?
Fiindcă tsc e extrem de încet la un proiect mare, în special cu type checking activat. La teste iarăși timpul de rulare e extins de timpul de transpilare care nu e neglijabil.
Cred ca vrei sa spui zig nu fig
Parcă-i un banc cu radio erevan: 10x, dar doar în anumite situații, în rest e 5x dar parcă nu neapărat pe cele mai importante lucruri.
- Turbopack HMR is 10x faster than Vite once the application scales above 30k modules. These marks continue to improve with more modules, showing 20x faster above 50k modules.
- Turbopack HMR is 700x faster than Webpack-based Next.js 11 for large applications with over 50k modules.
700x sună impresionant, când te uiți la asta ce înseamnă de fapt… parcă nu mai e:
Având în vedere că HMR nu este pentru producție, consider că tot ce este sub 0.5-1s este rezonabil de rapid pentru dev. Sau îmi scapă mie ceva? 
HMR is not intended for use in production, meaning it should only be used in development. See the building for production guide for more information.
La mine webpack cu tsc ia 20-30 secunde la fiecare schimbare pe M1 Pro și nu e un proiect extrem de mare.
La live reload contează foarte mult, la cold start iarăși. Dacă pui dev env-ul în docker contează și mai mult.
Când rulezi testele se traduc fișierele de test.
Nu cred că sunt multe proiecte serioase care au doar 5000 de componente.
