Anyone who has developed any project using Javascript knows how complicated and full of options the tooling can be. Javascript’s diverse platform support and varied use cases require specialized tools for different tasks: transpilers, bundlers, plugins, etc.
In spite of this, these tools share one constant thread; the tools themselves are mostly written in Javascript! It makes sense of course: if the application language and the tooling language are the same, then the entire community can contribute to both.
But there’s a disadvantage. Javascript itself wasn’t necessarily built as a build language in the same way that, say Make was. There are performance considerations that apply to large codebases and teams. Is it necessary to use Javascript for everything? Enter esbuild.
What is it?
esbuild is “An extremely fast JavaScript bundler”. It has all the features that you expect from a JS bundler.
- ES6 and CommonJS modules
- Tree shaking of ES6 modules
- TypeScript and JSX syntax
- Source maps
- Minification
- Plugins
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.
You may already know other JavaScript bundlers like webpack, rollup, or other ones that are used by the community. So how is this bundler different?
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
New tools that not only improve the developer experience but the whole ecosystem are always exciting. As the Javascript community gains experience with other languages like Golang and Rust, I’m expecting the right tools for the job to be more frequently applied in the coming years.
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.
Imagine the core of a web framework written in Rust or Golang but compiled to WebAssembly and leveraged from user-land Javascript! The possibilities and endless.
There’s a lot to learn, so if you are looking for more tools related to esbuild, be sure to check out:
