Turbopack Performance Benchmarks
turbo.buildAnother benchmark by maintainer of Vue and Vite, Evan You: https://github.com/yyx990803/vite-vs-next-turbo-hmr
He seems to imply that Turbopack is very close in performance to existing tooling like Vite in his benchmark, and not 10x better in common cases
Edit: his thoughts as of this hour: https://github.com/yyx990803/vite-vs-next-turbo-hmr/discussi...
Evan is credited in the post (this tweet is from three days ago).
> Turbopack and Next.js 13.0.1 are out addressing a regression that snuck in prior to public release and after the initial benchmarks were taken. We also fixed an incorrect rounding bug on our website (0.01s → 15ms). We appreciate Evan You's work that helped us identify and correct this.
Yes, but the post doesn't comment on all his notes (actually most are not mentioned). Specifically, his note on swc should really be brought up commented I think (after all, they're the ones who compared themselves with Vite, not the other way around).
Close but faster. And in some cases ("leaf") faster.
The way you phrase it makes it sound like Vite is still faster & Turbopack is getting there. These tweets seem to indicate Turbopack is faster.
Turbopack is indeed faster, which makes it more confusing. Like why not use the actual verifiable "apple to apple" benchmark results?
Even in this article, they do not refer to that acknowledgement, which because it was from a competiting OSS author, would have a lot more weight
I am very excited for Turbopack.
I hope to see this considered by the Angular team. Angular is tightly coupled with webpack, however, they've been experimenting with ESBuild, which is included in Angular 14. Vite has been tested by an Angular team member and reported some promising results. I just hope they don't tightly couple the implementation with ESBuild and fall into the same issue again.
Back to Turbopack:
> Turbopack is up to 10x and 700x faster than existing approaches.
The 700x speed gain compared to webpack is for dev mode changing 30000 files at once.. I understand that it scales very well. But is it realistic to boast about unrealistic scenarios? It erks me.
Marketing always overrides engineering on final copy
is it that unrealistic? dev mode is what i care most about. its ok if deploys are a little slower. 30k files probably means editing 1 file which triggers rebuilding the whole bundle... if that includes node modules it can probably hit 30k pretty easily
The benchmark is measuring HMR specifically. You've already dev-served your app, now you make a change... Which builder is faster?
It's important to get all the speed gain we can, Angular (webpack) is really slow at rebuilding when you save changes, this would be a life-saver, but no dev is ever watching 30k files at once.
Or if you just start with an empty cache, or if you come back from vacation and pull several weeks worth of changes… certainly a real use case
As a dev who avoids build steps entirely in web stacks, hearing that 1.1 sec startup is excellent, or 10-700x faster than the norm seems strange - I've gotten so used to stuff being instant.
If you haven't tried coding a little closer to the "metal" (vanilla js/css/html) I definitely recommend it. Browsers give you a lot out of the box now, and life without builds is sweet - fast iteration time, perfect in-browser dev tool support, and vastly reduced codebase complexity.
I’ve done both. Vanilla is fine, but people use frameworks for a reason. They really are easier, particularly for inexperienced developers, but in general for experienced developers as well. I don’t see any reason to be snooty about not using a tool because you want to keep things simple.
I'm plenty familiar with "the metal", and that's all I use for my (simple) personal blog, but I happily reach for React or Next.js when they're right for the project constraints. It doesn't have to be either/or.
That said, similar to GP, I'd definitely recommend it. Browsers give you a lot out of the box now, and life without builds is sweet - fast iteration time, perfect in-browser dev tool support, and vastly reduced codebase complexity.
It doesn't reduce the actual code complexity at all, in my experience. You don't have to deal with configuration, which is nice (though modern frameworks and tools are simplifying that more and more), and you don't have as many dependencies, which can be a positive thing.
But your actual code - where you spend the bulk of your time in medium to large projects - is not going to be made simpler by avoiding dependencies, especially build tools. The app I work on at my job (which is a very average one in many ways) would be a nightmare of complexity without our frameworks and build tools.
There can be this purity mindset that arises around the raw web. It can be fun to indulge for personal projects, and raw web technologies can even be the right approach for some projects. But don't let the siren's song of purity blind you to the messy reality of real tradeoffs.
It's always paid off for me to question that assumption - to try extracting the essentials of the app without the framework, as a weekend project or whatever. Often I can cut thousands of lines of code overall and get a faster more maintainable result.
Simplicity is always a virtue and we should always look for good opportunities to gravitate towards it, it just has to be balanced against other things (as everything does)
That said, I really doubt you cut "thousands of lines of" your own code by re-implementing your own partial framework. Maybe thousands of lines of dependencies were replaced with fewer thousands of lines of your own code, but that's a different question
Anyway, I was mainly pushing back against the original comment which seemed to be suggesting that build tools as a category are unnecessary, and that we should all just reject modernity and go back to living off the land. My point was that this is naive, and that it dismisses the very real value people get out of these tools every day
Questioning is good, dismissing is not
I never understood this argument. You are optimizing for a few seconds per day of saved waiting time. You buy that by having to deal with obscure differences between browsers, excluding some users, potential performance problems through lack of tree shaking, missing type safety, etc. Sure it's a trade off but for any non trivial project I've worked on it heavily skewed towards using something like webpack and babel. If you mix in things like web workers, webaudio or wasm, it gets almost impossible to use without a bundler, because otherwise library developers that use {wasm,audio workers,web workers} as an implementation detail of their libraries would leak that implementation detail out all the way to deployments (because these have to be in separate files if they aren't bundled in). Insanity.
Arguments against bundlers always sound to me like a person who lives next door to their job saying "I don't get why so many people commute by car, walking works just fine".
That is - some projects don't need a bundler, and for those projects, sure, do whatever. I don't think webpack is in any danger of becoming the new jQuery, where devs add it to every project because they don't know how to work without it. People using bundlers are usually doing stuff that can't be done without them, which obviates the whole argument.
It's more about reducing complexity than the build time I'd say. I work in C++ too, and a couple seconds of compile and run isn't the end of the world.
I don't personally have to deal with browser differences because I stick to subsets of CSS / JS that are 98%+ supported. If all your polyfills just compile down to minimal compatible JS anyway, then maybe those language features aren't that crucial. Always try to solve the problem without the new feature - almost every time I've tried this I find I get a simpler, more maintainable result without it, e.g. simple callbacks instead of promises (sacrilege), var instead of const/let (your poor namespaces), the word “function" instead of an arrow, etc. Those are probably close enough to supported to start using now, though not sure I care. Template literals might be nice, sounds like support is close.
Re: typescript, even coming from the C world, I don't personally find type safety to be a deal breaker. I work on some large python codebases - dynamic typing makes a lot of things much easier and more concise, in exchange for not catching some errors during compile. It's a tradeoff.
Avoiding all this build nonsense does make it harder to use some libraries that come out of the crazy modern node / javascript world, but in general most good ones have release builds, and I find a bit of healthy distance from the technical tail-chasing of that ecosystem is good for productivity.
Vite is basically instant for smaller projects + it has HMR for instant updates and React (And Vue, Svelte, etc I'm sure) is way more ergonomic for anything non-trival.
- ...it has HMR for instant updates and Vue (and React, Svelte, etc)...
Now it's ok.
Though I'm totally with you on that approach, I'm unaware of native/vanilla tools that offer hot reloading, which is pretty awesome.
If you are not bundling your code to begin with which you wouldn't be without a build step; I think there are ways to reload when a file is changed. Like an extension that speaks to a file system watcher.
Hot [module] reloading refers to dynamically swapping in an updated module or asset without reloading the page. When building nontrivial stuff HMR is pretty huge for productivity.
E.g. I do a lot of procedural music via WebAudio, and being able to modify the code and hear the results as the song continues to play is obviously pretty useful.
Alpine JS plus parcel has been really fun
but typescript and module inclusion?
Here's the bulk of the code used to generate the code they're building: https://github.com/vercel/turbo/blob/main/crates/turbopack-c...
They're building basically the same thing over and over again. This surprised me, given their intro post: https://vercel.com/blog/turbopack
Relevant quote:
> Turbopack is built on Turbo: an open-source, incremental memoization framework for Rust. Turbo can cache the result of any function in the program. When the program is run again, functions won't re-run unless their inputs have changed. This granular architecture enables your program to skip large amounts of work, at the level of the function.
I'd be curious to see if a real-world app (or even one generated with more variety in components) showed comparable performance numbers
turborepo was the first -turbo- on the family to use this strategy to cache a lot of dependencies on building monorepos.
I think they might be applying the same strategy everywhere by decoupling -turbo- from the implementations that use the strategy at each layer of the stack.
Expect a -turbo- script doing this and the first real complete replacement for typescript compilation, probably in go, not rust, tho!
> Expect a -turbo- script doing this and the first real complete replacement for typescript compilation, probably in go, not rust, tho!
There is stc which is for now just a PoC (from the developer of swc who is on Vercel's payroll) which is shifting from Go to Rust
Something that isn't clear to me: Why, exactly, is it so much faster than even its own build tool(swc)?
In other words, what's speeding up here isn't build speed, but the ability to download the updated changes. Right? Or am I wrong?
> Turbopack and Next.js 13.0.1 are out addressing a regression that snuck in prior to public release and after the initial benchmarks were taken. We also fixed an incorrect rounding bug on our website (0.01s → 15ms). We appreciate Evan You's work that helped us identify and correct this.
Does this mean they don't have a CI to run benchmarks to gate regressions?
Weird that rebuild is absent in these benchmarks.
Turbopack is alpha – currently only for local dev (e.g. dev server with hot reloading). Support for production builds hasn't landed yet. Once that lands, we'll add some benchmarks there as well.
Has this even been released? I went to look for a release on the repo and website and only saw instructions for using it with Next js. Might as well call it Next.js if it can't easily be used with anything else. The only way I found to build it was from the master branch. The latest tip in master is not a release.
> As of today, Turbopack can be used in Next.js v13. In the future we will be releasing a standalone CLI, plugin API, and support for other frameworks such as Svelte and Vue.
It is not ready for general usage for the moment, and it is still in alpha stage that isn't production ready and missing some crucial function such as PostCSS support. Nonetheless it is still exciting to see all the new innovation and healthy competition around JS bundler ecosystem.
Correct, still very early. While the happy path right now is through Next.js, there's a hacky workaround for general use outside Next.js. As we move forward in stability, we'll be publishing more guidance for using it as a general bundler with any framework. Next.js is helping dogfood Turbopack prior to that, while in alpha.
So then calling it a release is misleading. I don't mind it being called a component or module of Next.js in the meantime, but release makes it seem like it is standalone.
it doesn't make much sense to compare a tool that only works with nextjs with webpack and vite
Good on them make a correction
how is it a correction? the main controversy was the 10x and 700x faster thing... the 0.01s thing was just a typo really
From Evan You:
> There were number rounding issues in the original numbers for the 1k component case - Turbopack's 15ms was rounded down to 0.01s while Vite's 87ms was rounded up to 0.09s. This further got marketed as a 10x advantage when the original numbers were close to 6x.
I guess they 'typo-ed' Vite's numbers as well.
https://github.com/yyx990803/vite-vs-next-turbo-hmr/discussi...
`0.015.toFixed(2) === "0.01"`, and `0.087.toFixed(2) === "0.09"`
At this level of detail it _is_ super misleading however to say "a 10x improvement" whilst in reality it's more like 6x
will this work with existing webpack configs? and with babel? i need babel..
No, right now I believe it's tied to NextJS
Right, but is webpack compatibility a goal?