Hacker News Reader

Comment by qeternity | Hacker News Reader

What’s the catch? Do they really have a secret sauce or are there limitations in esbuild to achieve these speed ups?

Some section titles from the FAQ[1]:

> 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/

I saw that, but none of that adds up to a 100x speedup.

It does

Well not being written in JS does help -a lot-.

Esbuild is written in GO.

I'm sure it helps. It doesn't help 100x

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!

[0]: https://github.com/evanw/esbuild/issues/1619

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.

The catch is the person behind it cares about performance

Reply on news.ycombinator.com