3 ms·
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
by WorldMaker 2y ago
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.
- dartos 2y ago> 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