Work on esbuild started at the start of 2020. It is primarily authored and maintained by Evan Wallace, who, in addition to making this tremendous contribution to the JavaScript ecosystem, is the CTO and co-founder of Figma. Incredible output.
Bun [1] is a JS bundler based on esbuild’s source, but written in Zig. And it is about 3x faster than esbuild. I think its author Jarred is on HN as well.
Probably worth a submission on its own but I am just waiting till it is fully open source.
Edit: ( Deleted those Stats, since it may not be a fair comparison and it was probably not meant to be a fair benchmark in the first place. The details are still in the linked tweets. I do not know the author or am I in anyway affiliate with Bun. )
I am also wondering how much of those optimisation could be used on ESbuild. Since Rails 7 and Phoenix 1.6 will be using esbuild and not Webpack.
[1] https://twitter.com/jarredsumner/status/1390084458724741121
I've been trying to figure out how to build JS projects with the evolving tools (grunt => gulp => webpack => parcel => back to webpack) for years. I stumbled on esbuild and thought why not. Within about 15 minutes, I had solved pretty much all our build issues. Admittedly, our use case was simple-- we needed to transpile React-flavored TS to a npm package. In about 6 lines of code, I had a working bundle. There were no .esbuildrc or esbuild.config.js files, no babel dependencies, and no order of build operations to consider. The tool just worked and it was screaming fast. My first impression was that it _didn't_ work because the process closed in my terminal so quickly.
After my first experiment with it, I rewrote our hundreds of lines Cloud Functions deploy script in about 15 lines (most of which is configuration options on the `build()` method).
I'm curious to explore the tool more. Kudos and thanks to the author for an unbelievably useful contribution.
ESbuild is getting fantastic traction. It’s the default in Phoenix from 1.6 and comes as a default option in the current alpha of Rails 7, which you can get with a simple
rails new your_app -j esbuild
The only sort of issue I’ve had with it so far is you can’t use it with Inertiajs[1] as it does not support dynamic imports out of the box. Although I’m hesitant to call it an issue if its not in the scope of the project. Perhaps there are plugins I can use.
[1] - https://inertiajs.com
Why is it so fast? Mainly because:
- It's written in Go and compiles to native code. [...] While esbuild is busy parsing your JavaScript, node is busy parsing your bundler's JavaScript. By the time node has finished parsing your bundler's code, esbuild might have already exited and your bundler hasn't even started bundling yet. [...] Go is designed from the core for parallelism while JavaScript is not.
- Parallelism is used heavily.
We recently switched on a few of our project from Webpack and the difference is incredible. Running a watch using this is practically instantaneous compared to our previous setup. I've been recommending it to all my colleagues and we're replacing Webpack slowly but surely.
The main draw for me is the simplicity of the config too. Webpack config (even using things like Symfony's Encore) is pretty convoluted and confusing to track. This, at least in my experience, has greater readability and is simpler to understand.
esbuild is fast but it has a lot of place you have to figure out yourself and get into your way of doing thing.
1. dev server: you have to write a bit of code for this server to act as webpack dev server 2. scss: need to install plugin, and plugin cannot use from command line then you need to write a bit of JavaScript 3. global function: if you do `process.env` now you need to inject into build script 4. node package: if the package use node stuff you have to define thing like `fs/stream` into package.json
very quickly it get into your way of doing thing.
However, once you get past that base line, the cost is constant, the complexity just stop right there and not adding up.
Plus, the speed is amazing.
See also SWC, something similar to esbuild but written in Rust. NextJS uses SWC as well as Deno.
Rome is also being rewritten in Rust, it's more of a complete set of packages that subsume Webpack, Babel and all the other parts of the JS / TS development experience.
I'm using this to compile typescript lambda functions for AWS with great success. Combined with cdk and its NodeJsFunction you can even deploy/compile without local docker.
Great job on the landing page — that simple animation tells an incredibly simple and compelling story all in 800x200 pixels.
I wish more products had landing pages that looked like that.
You know you are getting old when you watch the arrival of the fourth JavaScript build tool of your career. I still remember when everyone was waving goodbye to Gulp in favour of Webpack. Webpack was going to save us all from the hell of massive convoluted gulp.js files. Fast forward five years and it's the same mess it was supposed to avoid. Slow, bloated and confusing.
I just switched to esbuild on our main project and the build time went from 7 minutes on CI to 1 second. Kinda stupid really. Anyway, here's to the future, let's hope it works out this time!
What I need is a similar speedup for my Typescript and eslint checks. Bundling isn’t my main issue.
For our quite big JS codebase on React + typescript, we switched from Webpack to esbuild earlier this year. It actually changed our daily lives !
The watch rebuild time went from 3-5s (actually a lot when you save your code very often) to something like .5-1 s
The full build time went from 120s to less than 5s
Full build with Rollup on all of my bundles for my project took around 10 minutes. IDK what my KLoC count is, but it's probably in the 25 to 50K range, with very few dependencies. I had a lot of complexity in my build scripts to try to subdivide related bundles into individual build commands to get the day-to-day rebuilds down to the 1 to 2 minute range. I had to run TypeScript in watch mode separately to emit individual JS files from my TS code for each module, and then only let Rollup bundle the JS code (the available TS plugins were just too slow), so I had tons of garbage files all over everywhere and occasionally they would get out of synch. It was a mess and it was extremely difficult to explain everything to newcomers.
With ESBuild, everything, all the things, build in 0.25 seconds. Build script has massively reduced complexity, as there's no point in running any command other than "build all". There's just the TS code and the output. I'm still running TypeScript in watch mode separately to get compilation errors on the fly (ESBuild doesn't run the TS compiler itself, it has a custom-built translator that optimistically throws away type information), but I no longer configure it to emit translated code. And did I mention the build script is massively simpler?
Esbuild actually made writing frontend bearable for the first time in years. It alone reduced our iterative build times from 45 seconds to something like .5 seconds.
Are there any tools that transform HTML and other files? For example, lets say I have an <img> tag with a src attribute that points to a local image. Can I automatically replace that with a <picture> tag with various formats (jpg, webp, avif) and sizes?
Such a shame that Angular doesn't benefit from using such tools:
https://github.com/evanw/esbuild/issues/42#issuecomment-9339...
So I'm currently stuck with a build that takes minutes, even though in principle it should require only seconds.
I switched to it on all of my personal (TypeScript) projects after upgrading to Phoenix 1.6 (where it is required). I normally have a separate lint step during production builds so its lack of type checking isn't an issue during development as VSCode catches and highlights type errors anyway.
It is crazy fast. It feels like the Turbo Pascal 3 of web development.
I had ignored this space for a while as I didn't see any need to fiddle with it. But there does seem to be quite a lot of movement now on Webpack alternatives. The speed improvements do look very interesting, though I'm not so sure how much of the delays I'm seeing with Webpack/Create React App are from the Typescript checking. I mean Typescript is awesome, but it's also not all that fast in building and type checking.
Vite seems to be one of the more interesting CRA alternatives. Though it uses esbuild only for development, and Rollup for production builds. It'll be interesting to see how this develops, and if the fast bundlers keep catching up in terms of features without getting slower.
Esbuild is amazing, but it’s worth mentioning SWC, which is written in Rust, even faster than Esbuild, and integrated within Deno, NextJS and other leading tools. Overall I am pretty bullish on the Rust/Js/Wasm/Typescript ecosystem.
Does esbuild support scss directly yet? I see on the site it mentions css. This is an important limitation for me.
That's old news or? For complex projects moving to esbuild from say Webpack is not necessarily easy.
see comparison with swc: https://swc.rs/docs/benchmark-transform
I started with webpack using create react app, I tried parcel, I tried esbuild. I tried parcel 2. I use esbuild. As a sole developer it takes no thought, and it still lets me do odd things pretty easily - like I have a particular process for dealing with odd cases in mdx files. Not a ringing endorsement or an exhaustive analysis. I'm just happy I don't have to spend time thinking about it. :-)
I've been actively moving all my projects from rollup to esbuild where possible. You have to do a bit more plumbing to get a lot of the niceties provided by the rollup/webpack ecosystem, but the resulting simplicity, speed, and size of esbuild make it worth it.
Isn't the browser also an extremely fast Javscript bundler?
How many scripts does a site need to make it feel faster when bundled?
When I visit websites that are rendered serverside, they usually feel instant to me. Even when they load a dozen scripts or so.
Although esbuild has been out for a while now, I think it's relevant today because the benchmarks have been updated to include Parcel 2, which was just released earlier today.
Both Rails 7 and Phoenix 1.6 is going off Webpack by default and I am so looking into the esbuild future. I never really liked Webpack to be honest.
I already replaced Webpack in my Phoenix project (you can compare default steps for building a release here https://nts.strzibny.name/12factor-elixir-phoenix-releases/) and cannot wait to do the same in Rails.
Deno is using this: https://github.com/swc-project/swc
How does esbuild compare to Bun, snowpack, Vite, and any other JS bundles? In performance, reliability, and extra features?
What’s the catch? Do they really have a secret sauce or are there limitations in esbuild to achieve these speed ups?
esbuild is a pleasure to use. Because of its speed you no longer need to separate test/release build for simple libraries. I am using esbuild for transpiling my new TypeScript projects.
However, I am still have to use TSC to generate declaration files(dts). Are anyone aware of esbuold-like tool to do that job?
I am using ParcelJS v2 (nightly), and my builds are really fast for a medium-sized project. It takes about 5s from scratch (no-cache) and <500ms to update after a change.
Do I recommend Parcel? Not sure, it feels like every time I update the package something breaks (in their defense, it is still in Beta).
Well, I spent few days to move large vue.js codebase from webpack 4 to Vite (esbuild). You know what? It isn’t as fast as that benchmarks shows us, even buggy and laggy. So upgraded to webpack 5 with caching to filesystem (I bet no one know) and it became even faster than Vite! I’m happy.
> Both Go and JavaScript have parallel garbage collectors, but Go's heap is shared between all threads while JavaScript has a separate heap per JavaScript thread.
It actually implies that JS GC can be faster because it doesn’t require global locks and can collect garbage in parallel.
Personally I've never found bundling speed to be a major bottleneck.
I do have some complicated Webpack setups that I don't think can be solved with any other bundler.
It stings being in webpack and there isn't much I can do about it in my current situation
How is it possible to be so fast?
esbuild is awesome! The level of detail in the release notes [1] always impresses me.
Is this the only popular JS build tool written in something other than JavaScript
So is esbuild vs parcel a bit of an accidental proxy battle between go and rust?
I've used it for a TypeScript project and it just worked.
A bit like Parcel, but faster.
also kudos to the esbuild team to have an official mention of deno usage and support. it works great and turned out to be much simpler, flexible and reliable than the current Deno.emit .
Yep, moved from webpack to esbuild + postcss. Great results.
has anyone used this in react-native ?
Looks awesome! I'm gonna use it!
Anyone able to compare this to Vite?
from my PoV Vite.js is much more mature project than esbuild
What do you think of the importmap approach propagated by dhh on rails 7?
salu2
I must say that this got to be a new standard. Es build is what we need. Great thing. Huge thanks to creators!
I would rather use Parcel.
On another thread were I said I don't like build tools/compilers in the same language as they work on, when the language is slow, I got voted down.
Here everyone: JS build tool in Go? Great!
+1 for parallelism of esbuild. I have a12 core machine and many tools either use one core or when forced to not benefit from more cores.
I also wish they would waste more memory, I have 32gb which re mostly unused even by large projects.
I stand by my opinion: dev tools should make it pleasant for developers not the tool writers.
Yet another one of these...
I'm sorry, but the node.js community needs to stop producing these stuff... it doesn't do anything better than all the webpack vs gulp vs parcel vs snowpack vs rollup vs how many bundlers again?
Often overlooked things when discussing esbuild here:
1. It's not just a faster replacement for a single %tool_name% in your build chain: for the vast majority of cases, it's the whole "chain" in a single cli command if you're doing it right.
That is, you don't just stick it inside, say, webpack as a faster replacement for babel (although you can). No, you look carefully through your webpack configs and its myriad of plugins, ask yourself whether you really need to inline css in jsx in png while simultaneously optimizing it for IE 4.0, realize you don't, through out the whole thing, and use esbuild instead.
I have two 50K+ LOC projects using esbuild, and I would use it even if it was slower than webpack/babel/tsc simply not to worry about the build chain breaking due to an update to some obscure dependency or plugin.
2. It is fast because it's written from scratch to do a set of particular things and do it fast, not just because it's Go and parallelized.
If you look at the commit log you will notice a lot of performance tweaks. If you look into the issues, you will find a lot of requests for additional features rejected, often due to possible negative performance impact.
3. The most impressive part about esbuild development is not just that it's one guy writing it: it is the level of support and documentation he manages to provide alongside.
The release notes alone are a good course into nitty-gritty details of the web ecosystem: all the addressed edge cases are explained in detail. To top it all off--all opened issues, no matter how uninformed they seem, find a courteous response.