Did you heard about TurboPack?
TurboPack it’s the hot new thing Vercel has released lately.
Vercel has taken on the bold task of rethinking the Webpack and bundler experience for web applications: they come with a new bundler and write it in Rust.
Say what again? Yes, in Rust, that’s right, we’re rewriting all of our build tools in Rust from scratch to see if we can eke out some performance wins.
Wait, haven’t we done this a few times before with examples like Rome, SWC, and all the tools that are claiming to be speeding our build time.
There are tools in the community that already are in some kind of progress in changing our build time, so why TurboPack differ from these?
Let me dive into you in a nutshell why TurboPack matters.
- It’s led by the creator of webpack, so they have a huge of experience in how build tools work.
- It’s created by the same team as the turbo repo. If you’re not already familiar with turbo repo, it is a mono repo tool focused on TypeScript applications that are very, very fast, written in Golang
- It takes a lot of advantage of caching.
Turbo repo hashes all the pack packages and all the build steps you create inside your repository, so when you make changes in the future it can just grab the outputted result rather than having to re-run the entire build for every chunk of your code base in every package in your mono repo. This means you can have a much faster experience building, re-running, making changes, filing Pull Requests, and all the other things that you have to do as a developer working on these big projects.
But the most important piece here, though, is that that this cache is not something that is just store on your machine; it is, for now, hosted remotely on Vercel.
If you choose, and you can link your account to your CLI, and then everybody who builds the project doesn’t matter whether they’re building it on GitHub or they’re building locally or any other platform, they will just grab the result, as it fetches a cached entity rather than having to do everything yourself and wait for those builds to pass.
We need to pay attention here because this is only happening at a package level. If you have a project with many packages, and you’ve chosen to break up your application in that way, individual packages can be cached by packages; they depend on changing would break that cash and a fresh build, you might still find a single change busting a lot of your cache because it’s in a dependency that a lot of things have.
The true magic of Turbo pack: It is in it's caching layer and how that enables your performance to scale as your applications get more extensive and not that they wrote really fast code and magically run faster.
Here’s a simplified example of what this might look like in Turbo:
We start with calling readFile on two files, file1.ts and file2.ts. We then bundle those files, concat them together, and end up with the fullBundle at the end. The results of all of those function calls get saved in the cache for later.
Now, let’s say we save the file2.ts file on your machine. Turbopack receives the file system event, and knows it needs to recompute file2.ts:
Since the result of file2.ts has changed, we need to bundle it again, which then needs to be concatenated again.
Crucially, file1.ts hasn’t changed. We read its result from the cache and pass that to concat instead. So we save time by not reading it and re-bundling it again.
Another important thing we need to notice is that currently, at the time of writing this post, TurboPack is unstable, and we’re nowhere near shipping TurboPack in production yet.
Resources:
Thanks for reading.
Top comments (0)