Live data from Hacker News

Esbuild – An extremely fast JavaScript bundler

esbuild.github.io

61–70 of 288 posts

Re: Esbuild – An extremely fast JavaScript bundler

#62

Yet another one of these... I'm sorry, but the node.js community needs to stop producing these stuff... it doesn't do anything better than all the webpack vs gulp vs parcel vs snowpack vs rollup vs how many bundlers again?

I agree with you in principle, but your comment makes it clear that you didn't actually look into this one at all. This one is actually good.

Re: Esbuild – An extremely fast JavaScript bundler

#63
post #4

Isn't the browser also an extremely fast Javscript bundler? How many scripts does a site need to make it feel faster when bundled? When I visit websites that are rendered serverside, they usually feel instant to me. Even when they load a dozen scripts or so.

> How many scripts does a site need to make it feel faster when bundled?

It's because people are using these huge frameworks with a lot of bloated code, it's too big, now devs are forced to do tree shaking and what not to trim the fat... front end JS development has become a madhouse of unnecessary complexity, because of node.js as well...

I hope that with the help of DENO that doesn't suffer from all that cargo culting, front-end development can become a healthier ecosystem...

Yes, some apps are complex, but 99% of front-end UI aren't.

Re: Esbuild – An extremely fast JavaScript bundler

#65
We recently switched on a few of our project from Webpack and the difference is incredible. Running a watch using this is practically instantaneous compared to our previous setup. I've been recommending it to all my colleagues and we're replacing Webpack slowly but surely.

The main draw for me is the simplicity of the config too. Webpack config (even using things like Symfony's Encore) is pretty convoluted and confusing to track. This, at least in my experience, has greater readability and is simpler to understand.

Re: Esbuild – An extremely fast JavaScript bundler

#66

Yet another one of these... I'm sorry, but the node.js community needs to stop producing these stuff... it doesn't do anything better than all the webpack vs gulp vs parcel vs snowpack vs rollup vs how many bundlers again?

I agree with you in principle, but your comment makes it clear that you didn't actually look into this one at all. This one is actually good.

> I agree with you in principle, but your comment makes it clear that you didn't actually look into this one at all. This one is actually good.

People have said say that same thing each time a new one pops up since Grunt 10 years+ ago.

If you're going to use a JS bundler written in Go, just stick to MAKEFILE...

Re: Esbuild – An extremely fast JavaScript bundler

#67
For our quite big JS codebase on React + typescript, we switched from Webpack to esbuild earlier this year. It actually changed our daily lives !

The watch rebuild time went from 3-5s (actually a lot when you save your code very often) to something like .5-1 s

The full build time went from 120s to less than 5s

Re: Esbuild – An extremely fast JavaScript bundler

#68
post #5

Earlier quoted context omitted.

> How many scripts does a site need to make it feel faster when bundled? Depends on what you're building. If you have many nested dependencies, you need to bundle them, and not rely on the browser to resolve them at runtime and do dozens of roundtrips to the server to fetch them.

I thought HTTP 2 fixed the problem of multiple downloads of small files/dependencies? The creator of Rails talks about it here: https://world.hey.com/dhh/modern-web-apps-without-javascript...

Khan Academy did a great writeup on their experience (including thoughts about HTTP/2) with various strategies for serving JS, such as:

- Single bundle

- No bundles (all separate files)

- Hybrid

https://blog.khanacademy.org/forgo-js-packaging-not-so-fast/

Re: Esbuild – An extremely fast JavaScript bundler

#69

Earlier quoted context omitted.

I agree with you in principle, but your comment makes it clear that you didn't actually look into this one at all. This one is actually good.

> I agree with you in principle, but your comment makes it clear that you didn't actually look into this one at all. This one is actually good. People have said say that same thing each time a new one pops up since Grunt 10 years+ ago. If you're going to use a JS bundler written in Go, just stick to MAKEFILE...

I certainly didn't.

> If you're going to use a JS bundler written in Go, just stick to MAKEFILE...

What?

Post reply on HN