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.

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.