FAQ

This is a collection of common questions about esbuild. You can also ask questions on the GitHub issue tracker.

Why is esbuild fast?

Several reasons:

Each one of these factors is only a somewhat significant speedup, but together they can result in a bundler that is multiple orders of magnitude faster than other bundlers commonly in use today.

Benchmark details

Here are the details about each benchmark:

JavaScript benchmark
esbuild
0.37s
esbuild (1 thread)
1.54s
rollup + terser
36.00s
webpack 4
41.91s
webpack 5
54.50s
parcel 2
56.71s
parcel 1
118.51s
0s
30s
60s
90s
120s

This benchmark approximates a large JavaScript codebase by duplicating the three.js library 10 times and building a single bundle from scratch, without any caches. The benchmark can be run with make bench-three in the esbuild repo.

Bundler Time Relative slowdown Absolute speed Output size
esbuild 0.37s 1x 1479.6 kloc/s 5.80mb
esbuild (1 thread) 1.54s 4x 355.5 kloc/s 5.80mb
rollup + terser 36.00s 97x 15.2 kloc/s 5.81mb
webpack 4 41.91s 113x 13.1 kloc/s 5.97mb
webpack 5 54.50s 147x 10.0 kloc/s 5.84mb
parcel 2 56.71s 153x 9.7 kloc/s 5.92mb
parcel 1 118.51s 320x 4.6 kloc/s 5.89mb

Each time reported is the best of three runs. I'm running esbuild with --bundle --minify --sourcemap (the single-threaded version uses GOMAXPROCS=1). I used the rollup-plugin-terser plugin because Rollup itself doesn't support minification. Webpack uses --mode=production --devtool=sourcemap. Parcel uses the default options. Absolute speed is based on the total line count including comments and blank lines, which is currently 547,441. The tests were done on a 6-core 2019 MacBook Pro with 16gb of RAM.

Caveats:

TypeScript benchmark
esbuild
0.09s
esbuild (1 thread)
0.37s
webpack 4
18.38s
parcel 1
18.76s
webpack 5
25.12s
parcel 2
42.32s
0s
10s
20s
30s
40s

This benchmark uses the Rome build tool to approximate a large TypeScript codebase. All code must be combined into a single minified bundle with source maps and the resulting bundle must work correctly. The benchmark can be run with make bench-rome in the esbuild repo.

Bundler Time Relative slowdown Absolute speed Output size
esbuild 0.09s 1x 1464.8 kloc/s 0.97mb
esbuild (1 thread) 0.37s 4x 356.3 kloc/s 0.97mb
webpack 4 18.38s 204x 7.2 kloc/s 1.26mb
parcel 1 18.76s 208x 7.0 kloc/s 1.56mb
webpack 5 24.57s 273x 5.4 kloc/s 1.26mb
parcel 2 42.32s 470x 3.1 kloc/s 1.68mb

Each time reported is the best of three runs. I'm running esbuild with --bundle --minify --sourcemap --platform=node (the single-threaded version uses GOMAXPROCS=1). Webpack uses ts-loader with transpileOnly: true and --mode=production --devtool=sourcemap. Parcel 1 uses --target node --bundle-node-modules. Parcel 2 uses "engines": "node" in package.json and needs the @parcel/transformer-typescript-tsc transformer to be able to handle the TypeScript code used in the benchmark. Absolute speed is based on the total line count including comments and blank lines, which is currently 131,836. The tests were done on a 6-core 2019 MacBook Pro with 16gb of RAM.

The results don't include Rollup because I couldn't get it to work. I tried rollup-plugin-typescript, @rollup/plugin-typescript, and @rollup/plugin-sucrase and they all didn't work for different reasons relating to TypeScript compilation.

Upcoming roadmap

These features are already in progress and are first priority:

These are potential future features but may not happen or may happen to a more limited extent:

After that point, I will consider esbuild to be relatively complete. I'm planning for esbuild to reach a mostly stable state and then stop accumulating more features. This will involve saying "no" to requests for adding major features to esbuild itself. I don't think esbuild should become an all-in-one solution for all frontend needs. In particular, I want to avoid the pain and problems of the "webpack config" model where the underlying tool is too flexible and usability suffers.

For example, I am not planning to include these features in esbuild's core itself:

I hope that the extensibility points I'm adding to esbuild (plugins and the API) will make esbuild useful to include as part of more customized build workflows, but I'm not intending or expecting these extensibility points to cover all use cases. If you have very custom requirements then you should be using other tools. I also hope esbuild inspires other build tools to dramatically improve performance by overhauling their implementations so that everyone can benefit, not just those that use esbuild.

I am planning to continue to maintain everything in esbuild's existing scope even after esbuild reaches stability. This means implementing support for newly-released JavaScript and TypeScript syntax features, for example.

Production readiness

This project has not yet hit version 1.0.0 and is still in active development. That said, it is far beyond the alpha stage and is pretty stable. I think of it as a late-stage beta. For some early-adopters that means it's good enough to use for real things. Some other people think this means esbuild isn't ready yet. This section doesn't try to convince you either way. It just tries to give you enough information so you can decide for yourself whether you want to use esbuild as your bundler.

Some data points: