Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Esbuild – An extremely fast JavaScript bundler

esbuild.github.io

Post reply on HN
Print view View original

71–80 of 288 posts

Re: Esbuild – An extremely fast JavaScript bundler

#71

Post by TekMol »

rudian wrote: post #48
TekMol wrote: post #31

Earlier quoted context omitted.

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.

Unless your site is made of 4 files/modules, you simply must bundle. ESM will download the files in series, as each dependency is discovered. Then compression doesn’t work as well as it will be per-file. Then of course you can’t tree-shake dependencies from npm, so good luck downloading the whole of lodash on your client. In short you lose the advantages of only download what you need pretty quickly.

> good luck downloading the whole of lodash on your client

I never felt the need to use loadash. But even if a site would do that, it does not seem like a big issue. It is 71k. A Twitter profile page is over 5MB. 70 times the size of that loadash library. An appartment page on AirBnB is over 9MB. An Instagram profile page is over 9MB too.

Re: Esbuild – An extremely fast JavaScript bundler

#72

Post by Intrepidd »

throw_m239339 wrote: post #61

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 recently switched to esbuild and I am delighed. My build time dropped from 30s to 2s and I was able to remove a lot of dependencies. So IMHO they need to continue producing these stuff to push the innovation forward.

Re: Esbuild – An extremely fast JavaScript bundler

#73

Post by innocenat »

throw_m239339 wrote: post #66
phinnaeus wrote: post #62

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

    dist.js: $(wildcard *.js)
        cat $? > dist.js
Like this?

Re: Esbuild – An extremely fast JavaScript bundler

#74

Post by throw_m239339 »

nsonha wrote: post #32
TekMol wrote: 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.

> When I visit websites that are rendered serverside, they usually feel instant to me. Even when they load a dozen scripts or so Then they'll be faster doing only one request, this is regardless of ssr or spa Bundling also gives you slatic analysis (typescript and linting), and frees developers from developing in the dark, like keeping track in their brain what component in what script exposes what global.

> Bundling also gives you slatic analysis (typescript and linting),

No it doesn't do that, typescript compiler does the static analysis and whatever linter does the linting, you don't need a bundler for that, a bundler just takes many source files and bundles them into one.

Re: Esbuild – An extremely fast JavaScript bundler

#75

Post by EugeneOZ »

kitd wrote: post #60
tiew9Vii wrote: post #45

Earlier quoted context omitted.

I looked at using ESbuild and I use Typescript. It was all looking good until reading the docs and it said ESbuild doesn't typecheck Typescript and to rely on your IDE to flag errors. Is that correct and how is that working for you practically if it is? The whole point for Typescript for me is to have a compiler typecheck my code and block errors at compile time. ESbuild not typechecking seemed like a major contradic…

Practically, it isn't an issue if you use VSCode which has the Typescript language server built in to catch type errors for you. If you want, your build script can include `tsc -noEmit` to type check before the build.

Only if a project is pretty small. Change in one place, especially if it's a reusable code, might ruin code in multiple different places and IDE will not recompile the whole project on every change, it will only watch your currently opened files and, maybe, some files in opened folders.

Re: Esbuild – An extremely fast JavaScript bundler

#76

Post by EugeneOZ »

Vinnl wrote: post #53
tiew9Vii wrote: post #45

Earlier quoted context omitted.

I looked at using ESbuild and I use Typescript. It was all looking good until reading the docs and it said ESbuild doesn't typecheck Typescript and to rely on your IDE to flag errors. Is that correct and how is that working for you practically if it is? The whole point for Typescript for me is to have a compiler typecheck my code and block errors at compile time. ESbuild not typechecking seemed like a major contradic…

Consider TypeScript like a linter. ESBuild doesn't run ESLint for you either - you can run it separately, or in parallel. This means that for example, during development, you can see your running code quickly, while your editor runs tsc to highlight type checking errors. And in your build system, you can produce a production bundle to test while in parallel checking for type errors.

It's not a linter, far from it.

Re: Esbuild – An extremely fast JavaScript bundler

#78

Post by baybal2 »

dom111 wrote: post #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 confus…

Webpack is a bane of webdev existence.

Having junior team encounter a webpack breakage === them spending as much time on tooling, as coding itself

Re: Esbuild – An extremely fast JavaScript bundler

#80

Post by rimliu »

throw_m239339 wrote: post #63
TekMol wrote: 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 cult…

I just saw an (internal) presentation where presenter predicted that in a few coming months we will see a lot more RxJS being used in ReactJS projects. Cannot wait to see it included on webpages which would be just fine with zero JS.
Post reply on HN