esbuild, a JavaScript bundler and minifier, seeks to bring order-of-magnitude speed improvements in the JavaScript bundling and minification process. esbuild achieves its speed by being written in Go compiled to native code, parallelizing tasks to leverage multi-core processors, and minimizing data transformations.
Evan Wallace, CTO and co-founder of @figmadesign and esbuild’s creator, explained that he aims to reset the performance expectations of the JavaScript community:
[…] The current build tools for the web are at least an order of magnitude slower than they should be. I’m hoping that this project serves as an “existence proof” that our JavaScript tooling can be much, much faster.
[…] I’m not trying to compete with the entire JavaScript ecosystem and create an extremely flexible build system that can build anything.
I’m trying to create a build tool that a) works well for a given sweet spot of use cases (bundling JavaScript, TypeScript, and maybe CSS) and b) resets the expectations of the community for what it means for a JavaScript build tool to be fast.
Wallace mentioned that a key use case for esbuild was the packaging of a large codebase for production. This includes minifying the code, which reduces network transfer time, and producing source maps, which are important for debugging.
Wallace provided a custom-made JavaScript benchmark that shows esbuild achieving build times under one second, while other tools’ build time varies between 30s and over a minute. Similar results are observed in the provided TypeScript benchmark:
A developer has run the benchmark on a different machine and reproduced results confirming the speed improvements. Devon Govett, creator of the parcel bundler, hinted at one reason behind the performance gap between esbuild and parcel:
[…] For those looking at this and wondering why Parcel appears much slower, it’s because it runs Babel by default whereas webpack and others do not. If those tools were configured similarly, or Parcel was configured to skip this, I imagine the results would be closer.
While the benchmark methodology needs to be refined to reflect realistic scenarios, the build times achieved by esbuild remain impressive and are unheard of among the alternative bundlers that are written in JavaScript or TypeScript. esbuild is written in Go, and compiles to native code. esbuild additionally relies on an architecture that maximizes parallelism (e.g. when parsing, printing, and generating source maps), tries to do as few full-abstract syntax tree (AST) passes as possible for better cache locality, and supports incremental builds.
esbuild supports constant folding and is able to handle libraries such as React that may contain code as follows:
if (process.env.NODE_ENV === 'production') {
module.exports = require('./cjs/react.production.min.js');
} else {
module.exports = require('./cjs/react.development.js');
}
According to the value of process.env.NODE_ENV passed in the command line, one of the previous code branches will be eliminated from the bundle.
Developers have been welcoming the speed improvements. In a recent panel at QCon London, Eoin Shanaghy, CTO and co-founder of fourTheorem, said:
I tried a recent development called ES Build, which is a native transpiler written in Golang, which is significantly faster than any of the alternatives. I think that’s ultimately what’s going to happen because the benefits are there. You need it. […] You don’t have to build every JavaScript tool in JavaScript.
esbuild is still being actively worked on and may not be ready to be used in production. esbuild is an open-source, MIT-licensed project. The latest release at the time of publication is 0.5.0 and includes both a Go and JavaScript (browser) API, together with TypeScript decorator support.