> Why is esbuild fast?
> - It's written in Go and compiles to native code.
> - Parallelism is used heavily.
> - Everything in esbuild is written from scratch.
> - Memory is used efficiently.
> Production readiness
> - Used by other projects
> - API stability
> - Only one main developer
> - Not always open to scope expansion
It helps to get 80% of the way there, on a logarithmic scale. The remaining 20% is evanw saying no to adding any kind of option, feature and the kitchen sink to this project, which is one of the reason Webpack/Babel & co. are some of the heaviest objects in the universe.
It doesn't always work in situations where 'require' can't be statically evaluated at run-time (webpack would work in this situation) - for example I filed a bug recently[0]
Even though the bug was closed I was impressed with the thorough and timely response from the esbuild developers which explained the reasoning behind it. For me it was worth changing my project just so I could continue using esbuild, it really is that good!
The catch is that they focus on modern builds (I.e. not IE) it also doesn’t do type definitions, so if you want type defs you’ll need to compile with typescript anyway.
> Why is esbuild fast? > - It's written in Go and compiles to native code. > - Parallelism is used heavily. > - Everything in esbuild is written from scratch. > - Memory is used efficiently.
> Production readiness > - Used by other projects > - API stability > - Only one main developer > - Not always open to scope expansion
1: https://esbuild.github.io/faq/