What is it?
- ES6 and CommonJS modules
- Tree shaking of ES6 modules
- TypeScript and JSX syntax
- Source maps
And no kidding, it’s fast:
The performance improvements are so drastic that they enable new workflows, especially on large projects and large teams where reducing build times has a multiplier effect.
The biggest and game-changing difference is that ESBuild is written in Golang. It’s a compiled c-like language with a static but lightweight type system, sophisticated concurrency, platform independence, and strong performance. These features directly benefit the performance of ESBuild.
Is it ready?
Whenever a new tool is considered for a project, the first question that arises is: Is it production ready? I’ve recently worked on a project using esbuild so I’m going to try and answer this.
For the most part, yes. My experience using it for a React project has been positive. Although it’s somewhat new, it’s been around enough that there’s ample plugins and flexible configuration for most use cases (with create-react-app for example). It’s even got support for esmodules and other features which we now expect to be standard.
On the other hand, there’s still some features missing that I believe to be important for a production project.
The biggest missing feature is code splitting. Although it’s supported, it is still a work in progress. This means that there’s still problems with creating the bundle, and unfortunately there isn’t support for code-split from other tools. I recently tried to code-split from a plugin that uses the Transform API, only to discover that it’s not possible. In big projects like the one I’m currently working on, code splitting is something that turns out to be almost necessary.
The second problem I found is plugins & maturity. During my investigation I found a lot of plugins/integrations with common platforms. esbuild supports create-react-app and other projects. However, it’s still not available with several important projects like Next.js, which is a huge drawback if your team relies on Next.js.
Also, when compared to other tools like webpack, it lacks community support, though this should improve with time. So many developers have been working with webpack that there’s a plethora of tools available, custom tailored for many use cases. I faced this when trying to import an SVG in a react project, a plugin exists but was not integrated to the config! I’m sure there are more corner cases like this, and these can be a pain on large teams.
One thing to notice is that esbuild’s page has a section explaining its current status and its “production readiness”, and it explains it far better than I can. If you want more details you should check it out because it’s excellent at explaining the design and development philosophy.
What it means for the future
But why stop in the build tooling? With the widening support of wasm (Web Assembly) as a compile target for different languages, I’m expecting to start seeing this trend up in the abstraction layers also.
There’s a lot to learn, so if you are looking for more tools related to esbuild, be sure to check out: