🚀 What is Turbopack
Learn what is Turbopack and how it can help you make your build process 700x faster

We are in an era where we are constantly having new JS frameworks being release, bought and transferred from one company to another company. This time we have a new bundler in town: Turbopack.
Today we will talk about a hot topic that is currently going on in the Javascript community: Turbopack, the successor to Webpack.
This is a blog post made from the talk Turbopack - A true successor of Webpack?
by Boris Matinovic given at Frontend ZG #12 with Cinnamon & Atlantic Grupa meetup in Frontend ZG Group - huge thanks for Cinnamon Agency and Atlantic Grupa for making this meetup possible. We hope you enjoy as much as they have enjoyed organizing and creating the meetup and talk ❤️
What is Turbopack
Turbopack is a module bundler to bundle your Javascript files. Turbopack's development is led by Tobias Koppers - yes, the creator of Webpack - and it promises it will be the Web’s next-generation bundler, promising to be an open-source tool for the future.
What can you expect from Turbopack
Turbopack's original goal is to be a go-to bundler for the big, complex application that many developers are currently working on - think Facebook size with thousands of components.
For the framework developers out there, Turbopack promises to reduce the sheer complexity that comes with bundlers - we can think here of SSR and RSC in Webpack world - and allowing them to build with more assemblability and less complicated configurations. To the final users, Turbopack's goal is to provide ways for developers to create faster apps.
How is Turbopack fast
Turbopack has a few important concepts to understand before fully understanding how it can be so much faster than other bundlers.
1. The turbo engine
The primary reason on why Turbopack is fast, it is because it's built on reusable libraries from Rust which enables incremental computation known as the Turbo engine.
1.1 Function-level caching
In a program Turbo engine-powered, you can select certain functions "to be remembered". This means that when these functions are called, the Turbo engine will remember what they were called with, and what they returned. This will be saved in an in-memory cache.
Turbopack's website has a pretty good image describing the process:

Whenever we call readFile
in any file, we bundle
those files, concat
them together and then in the end, we end up with fullBundle
. The result of this concat
is saved in the cache for later usage.
Now, let's imagine that you are working on your local machine, running your development server. You changes the content of sdk.ts
, Turboack receives the file system event, and it knows that it needs to recompute the readFile
for sdk.ts
.

readFile
from sdk.ts
(credit: turbo.build)Since the result of the fullBundle
is dependent on sdk.ts
, it means we will need to bundle
it again, which in turn needs to be concatenated again.
Since api.ts
hasn't changed, we can read from cache - which is way faster than accessing the disk - and pass it to fullBundle
.
This is fairly crucial example but you can imagine a project with 30.000+ files, the concept is the same. You can save huge amount of time by remembering the result of functions and not re-doing work that's been done before.
1.2 The cache
Since the cache being used here is the in-memory cache, it means that this cache will last until the process is finished. As soon as the process is terminated, the cache is gone, therefore you will to re-build the cache - usually by re-starting the development server.
In the future, we’re planning to persist this cache - either to the filesystem, or to a remote cache like Turborepo’s. This will mean that Turbopack could remember work done across runs and machines.
- Tubopack's team
2. Compiling by request
The Turbo engine is extremely useful in providing fast updates on your development server, but there's another extremely important metric: start up time. The faster your development starts, the faster you can get to work.
Usually there are two ways of making a process faster: either you work faster or you try to cut work in less important places. Turbopack's accomplish this by:
2.1 Page-level compilation
Most of the bundlers - we looking at you Webpack - compiles your entire application before showing your development server.
Whenever I access http://localhost
I only need the page http://localhost
to be compiled and not http://localhost/about
to be compiled. Turbopack's only compile the page that you are currently requesting with it's assets it depends on - this is a feature that NextJS 11 implements but we are not sure about other frameworks.
That is much better, allowing the bundler to build only what is necessary at the time it is necessary - saving time and resources in the process.
2.2 Request-level compilation
Turbopack is smart enough to only compile the code that you have requested. What this mean is that if you request HTML, Turbopack compiles only the HTML and not everything else that is referenced by that HTML.
In case the browser request a CSS file, Turbopack will only compile the CSS file and not the images it might refer.
Turbopack even knows to not compile source maps unless your Chrome DevTools are open 🤯
Turbopack vs Webpack (or Vite)
First, Turbopack is a lazy bundler. Turbopack will only bundle the assets that are necessary. For example, esbuild doesn't do this - unless you will target very specific entry points. At huge scales, this makes Turbopack faster even when compared with native ESM. It will only compile the code that is required to render the page.
Second, Turbopack relies on a much finer granular build engine called Turbo Engine (referenced above). This build engine can cache results of any functions. This means that it will skip large amount of work for every build you do.
Turbopack claims it is much faster than Webpack and Vite but Even You - the creator of VueJS and Vite - says it can be debated in his comparison of Turbopack vs Vite.
It is important to note that currently Turbopack is in Alpha stage which means that it is not ready for production and it should be adopted with care.
The future of Turbopack
It is always a hard task to compare the speed of software A vs software B. There are several variables to take into consideration that can be manipulated to interfere with the results in favor of software A or software B. The claims about how fast Turbopack is compared to Vite or Webpack need to be taken with care.
Turbopack's roadmap has plans to release a standalone CLI, a plugin API, and add support to frameworks like Svelte and VueJS.
While we should be careful between switching from well established bundlers such as Vite, esbuild or Webpack we must admit that what Turbopack is bringing to the Javascript community is exciting and worth to keep an eye on it.