Turbopack Performance Benchmarks
turbo.build
turbo.build
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...
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.
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
> 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.
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.
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.
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.
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.
Now it's ok.
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.
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.
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.
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
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
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!
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
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?
Does this mean they don't have a CI to run benchmarks to gate regressions?
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.
> 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...