Esbuild – An extremely fast JavaScript bundler

Post by h0h0h0h0111 » Thu, Oct 14, 2021, 3:13 PM UTC

btbuildem wrote: post #186

jacobsenscott wrote: post #166

Earlier quoted context omitted.

I remember when we just served the javascript we wrote. Of course we are back to that. You can just write es6 in as many files as you would like and serve it over http/2 without any webpack/esbuild/babble/etc. The fastest code is no code.

Indeed, the best build chain is no build chain at all. I've been ridiculed at work for not using node, npm, web pack etc -- but I'm not spending 20% of my time on tooling issues.

Post by magerleagues » Thu, Oct 14, 2021, 3:17 PM UTC

baxuz wrote: post #124

maga wrote: post #110

Often overlooked things when discussing esbuild here: 1. It's not just a faster replacement for a single %tool_name% in your build chain: for the vast majority of cases, it's the whole "chain" in a single cli command if you're doing it right. That is, you don't just stick it inside, say, webpack as a faster replacement for babel (although you can). No, you look carefully through your webpack configs and its myriad of…

How is the integration with things like a dev server and tools present in create-react-app like react-fast-refresh? Also, in case of working on an Electron project: How well does it handle main/render/preload compile targets and handling of native modules and linking? Electron-forge is, for instance, the recommended toolchain for building Electron apps and the Webpack stuff is a particular pain in the ass.

Post by capableweb » Thu, Oct 14, 2021, 3:18 PM UTC

mr_pinnen wrote: post #107

eloff wrote: post #91

Earlier quoted context omitted.

I came here too say this. The man authored in the neighborhood of 100k LOC in a year, just on this. There's a living 10x dev, it's not a myth. What is ridiculous is to think someone can 10x a normal developer, it's more like the difference between the top few percent and the bottom 10-20%. Evan Wallace is a beast, no doubt.

While he is certainly an excellent developer with great productivity to boot, LOC is an obtuse metric. For example there is a package-lock.json commit which is almost 20K lines. Otherwise I totally agree.

Post by eyelidlessness » Thu, Oct 14, 2021, 3:35 PM UTC

TekMol wrote: post #31

eyelidlessness wrote: post #28

Earlier quoted context omitted.

What ESBuild offers over plain ESM is: - fast TypeScript/JSX compile - bundling shared code to reduce request waterfall/splitting to reduce redundancy - bundle optimization (tree shaking/dead code elimination; minification is actually faster than not using it) - a simple plugin system for use cases like other compiled frameworks like Vue or Svelte, or whatever else you might want in a build pipeline

On the downside, it will put all the code into one giant script that has to be downloaded upfront. While a website that loads scripts per page will only load the scripts that are needed on the current page.

Post by eyelidlessness » Thu, Oct 14, 2021, 3:47 PM UTC

theptip wrote: post #216

maga wrote: post #110

Often overlooked things when discussing esbuild here: 1. It's not just a faster replacement for a single %tool_name% in your build chain: for the vast majority of cases, it's the whole "chain" in a single cli command if you're doing it right. That is, you don't just stick it inside, say, webpack as a faster replacement for babel (although you can). No, you look carefully through your webpack configs and its myriad of…

Remember when all of these points applied to webpack, when it was the “single simple fast tool” to replace everyone’s grunt scripts? It seems there’s a feature treadmill at work here where projects inexorably bloat as they get popular. But we tried “compose tools in the Unix way” with grunt too, and that led to spaghetti scripts, unique to each project, that were hard to reason about. I wonder if there is a middle wa…