Hacker News Reader

Comment by segphault | Hacker News Reader

I have been really impressed with esbuild. It is lightning fast and trivially easy to configure. Instead of using a crappy React boilerplate that stitches together a thousand fragile, poorly-maintained npm packages, you just install one tiny binary implemented in performant, reliable Go.

View on HN

I previously dismissed esbuild thinking it was too limited, until realizing the extreme performance difference allows for far far more simplification than I had initially appreciated... I'm not just talking about the lack of 10k npm dependencies.

When a build process is slow, if we are unable to make it fundamentally faster we start to do loads of crazy workarounds that keep growing tentacles with increasing complexity and optimisation challenges: Incremental builds, caching, different pipelines for development vs production. We've been living with this stuff for so long it's easy to forget that when a full build is humanly instantaneous you can just throw all of this complexity away, you don't need it... that's when I realized I could use esbuild, I don't need those "features".

esbuild changes the game. Before we have a dynamic language with a compile step that compiles slow like a C++ project. All the disadvantages of a dynamic language combined with the disadvantages of a compiled language. In the browser you have no choice, but to use that setup on the server with node or on mobile with react native was questionable. Now with instant builds, you've got a dynamic language back - and one that mops the floor with Ruby and Python in terms of performance. You now have just one language to hire for, all your developers can work on our understand any part of the code, and you can share code between server and client. The time for universal JavaScript is here.

Agreed, I added it to a large project for a client for development builds that were crawling and it is far and away both easy to use and blows all other build tools out of the water when it comes to speed. We still use webpack for prod builds since we need to support legacy browsers (I know... But corporate) but it's blazingly fast for development.

I started extracting code from my project into a shared npm library. esbuild takes 70ms to bundle all files into a single index.js, then I also need to run tsc (TypeScript) to emit the declaration files and that takes ~10 seconds. esbuild is 3 orders of magnitude faster than tsc! Granted, they are not doing the same type of work, but still…

"I have 10k followers on FaceTwitterStagram but my family is only 4 members. Yes, people love me more on social networks than in my own family."

In other words: apples and oranges. :)

What is the point of that comparison?

I really love esbuild. Its speed is amazingly fast, and my node_modules folder is so clean.

But not being able to transpile to ES5 makes it a hard choice to use in client-facing projects, where IE11 is not totally dead (yet).

Its doable to integrate with swc (another great tool on the list), but now the build chain is longer, and more things to take care (such as sourcemaps).

Even if I guess IE11 is technically not EOL'd by Microsoft, they will stop supporting it for 365 services on Aug 17 this year, so I'm curious what kind of businesses are still using it.

I'm simply using Webpack for my production builds.

I've been meaning to check out esbuild. Question to those who have used it: what's the catch, other than flexibility? If you've got a standard TypeScript/JSX/bundling setup, is there any disadvantage at all to switching to esbuild?

Code splitting doesn't work (yet) if that's a feature you need.

Reply on news.ycombinator.com