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?
Esbuild – An extremely fast JavaScript bundler
61–70 of 288 posts
Re: Esbuild – An extremely fast JavaScript bundler
#62Yet 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?
Re: Esbuild – An extremely fast JavaScript bundler
#63Isn'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.
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
#64Re: Esbuild – An extremely fast JavaScript bundler
#65The 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
#66Yet 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.
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
#67The 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
#68Earlier 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...
- 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
#69Earlier 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...
> If you're going to use a JS bundler written in Go, just stick to MAKEFILE...
What?