Much of esbuild's performance gains are in throwing out a lot of cruft. It definitely benefits from the "fresh rewrite can avoid the cruft of an organic project", including specifically benefiting a lot from ESM as the winning end goal format, and the hindsight of Webpack eventually a massive organic ecosystem of plugins towards a core set of "best practices" over a lot of versions and ecosystem churn.
esbuild versus webpack performance is never a fair fight. Most of the other behemoths are still "just" webpack configurations plus bundles of plugins. It will take a while for the build tools in that model to settle down/slim down.
(esbuild versus Typescript for "Typescript is the only build tool" workflows is a much more interesting fight. esbuild doesn't do type checking only type stripping so it is also not a fair fight, and you really most often want both, but "type strip-only" modes in Typescript are iterating to compete with esbuild in fun ways, so it is also good for the ecosystem to see the fight happening.)
I appreciate esbuild, but I also appreciate esbuild had so much of the benefit of a lot of hindsight and not developing in the open as an ecosystem of plugins like webpack did but rather baking in the known best practices as one core tool.
> Much of esbuild's performance gains are in throwing out a lot of cruft.
I don’t think there’s a great way to be sure of this.
Parcel 2 (my personal favorite), for example, doesn’t include, by default, much of the cruft from mid-2010s JavaScript, but esbuild is still faster.
Theoretically, being able to use multiple cores would bring speed improvements to a lot of the tree manipulation tasks involved in building js projects.
> esbuild versus webpack performance is never a fair fight.
Yeah webpack is just the worst. Bloated from day 1
The build on my last large project took about 12 seconds total. That included installing self-signed certificates into the OS trust store, installing certificates into the browsers in Linux, compiling from TypeScript, via SWC, creating a universal command available from the command path, consolidating JS and CSS assets into single files, and some other things. I bet it could be faster, but I was happy with 12 seconds considering the project was quite large.
More than 90% of performance in JavaScript comes down to:
* comfort with events and callbacks
* avoiding string parsing: queryStrings, innerHTML, and so on
* a solid understanding of transmission and messaging. I wrote my own WebSocket library
None of that, except figuring out your own home grown WebSocket engine, is complicated, but it takes some trial and effort to get it right universally
Look at the performance gains in build tool land (esbuild specifically) and you’ll see the performance gains with native languages.
For most webservers and UIs it’s plenty fast though.