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).
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.
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.
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
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.
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.
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!
> 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?
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.
> 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.
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...