🔥 Battle for the Bundling time: esbuild — a JavaScript bundler and minifier written on Golang

Introduction

In this crazy world, it has become so difficult to secure leadership in at least one discipline. And now, a new battle has already begun: the speed of assembly of bundle — a measure to determine the best JavaScript bundler...

Hello, friend! And let the battle begins! ✊

📝 Table of contents

• Bundlers versions
• Official benchmark results
• My own benchmark results
  • Rollup.js
  • Parcel
  • Webpack
  • esbuild

Bundlers versions

Unfortunately, esbuild has no versions in repository, so I can't refer to a specific build of it. But, I'll use info from package.json file (17 Feb 2020):

{
  "private": true,
  "devDependencies": {
    "js-yaml": "3.13.1",
    "parcel": "1.12.4",              // -> latest 1.x version
    "rollup": "1.20.3",              // -> not latest version
    "rollup-plugin-terser": "5.1.3", // -> not latest version
    "webpack": "4.39.3",             // -> not latest version
    "webpack-cli": "3.3.7"
  }
}

Official benchmark results

[...] benchmark approximates a large codebase by duplicating the three.js library 10 times and building a single bundle from scratch, without any caches. [...] esbuild is 10-100x faster than the other JavaScript bundlers I tested (webpack, rollup, and parcel) [...]

Authors run benchmark on 6-core 2019 MacBook Pro with 16gb of RAM. This table show official results from README:

Impressive, isn't it? Yeah, me too. But I was taught not to believe the word numbers on the Internet (especially when it comes about JavaScript).

My own benchmark results

So, I decided to double-check everything on my work computer: 4-core 2015 MacBook Pro with 8gb of RAM.

OK! Let's git clone and run make bench-three from root folder:

$ git clone https://github.com/evanw/esbuild.git
$ cd esbuild
$ make bench-three

Rollup.js

[...] used the rollup-plugin-terser plugin because rollup itself doesn't support minification.

Done in 1m 15.2s

real 77.02
user 87.98
sys 6.04

5.8M    bench/three/rollup/entry.rollup.js
 19M    bench/three/rollup/entry.rollup.js.map

Hmm... 🤔 it was a strange result! IDK what's wrong, because I saw this result (±10s) each time on my MacBook Pro. But, okay. Let's see next bundler.

Parcel

[...] Parcel uses the default options.

Done in 322.5s

real 323.92
user 387.59
sys 33.24

6.8M    bench/three/parcel/entry.parcel.js
 20M    bench/three/parcel/entry.parcel.js.map

I often use Parcel on small projects without React.js or other frameworks. I know that it's not fastest, so this result didn't surprise me much.

Webpack

[...] Webpack uses --mode=production --devtool=sourcemap.

Done in 81.3s

real 82.81
user 100.26
sys 5.69

6.0M    bench/three/webpack/entry.webpack.js
 19M    bench/three/webpack/entry.webpack.js.map

Perhaps this is the most interesting result (for me) of the Big three bundlers! I'd never have thought, that Webpack could do this job better than Rollup... 🤯

esbuild

[...] running esbuild with --bundle --minify --sourcemap.

Done in 1.4s

real 1.47
user 3.14
sys 0.61

5.8M    bench/three/esbuild/entry.esbuild.js
 17M    bench/three/esbuild/entry.esbuild.js.map

Yeah, I'm shocked, too. How can that be? Actually, it's simple Go magic! ✨

• It's written in Go, a language that compiles to native code
• Parsing, printing, and source map generation are all fully parallelized
• Everything is done in very few passes without expensive data transformations
• Code is written with speed in mind, and tries to avoid unnecessary allocations

Photo by

[Title] esbuild authors https://github.com/evanw/esbuild
[1] Vic Shóstak (article author)

P.S.

If you want more — write a comment below & follow me. Thx! 😘