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

141–150 of 288 posts

Re: Esbuild – An extremely fast JavaScript bundler

#141

Post by chrisjc »

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.

First, forgive my ignorance of the JS/TS and bundler ecosystems.

> while in parallel checking for type errors.

Why are you suggesting this not be done during development? Is it bc while ESBuild is fast and runs in parallel, it's still only as fast as the slowest parallelized task, and in this case the slowest task is checking for type errors? And I assume checking for type errors is the slowest because it has to invoke an external resource, tsc?

Would it not make sense to have two development bundlers then? One for getting your code up and running quickly, and a second that outputs a dummy build artifact, but allows a more thorough production-like build that includes type checking (or other long running activities)? That way you get all the verification you would like, but don't pay a price on waiting for your code to deploy?

Re: Esbuild – An extremely fast JavaScript bundler

#142

Post by deergomoo »

louissm_it wrote: post #2

ESbuild is getting fantastic traction. It’s the default in Phoenix from 1.6 and comes as a default option in the current alpha of Rails 7, which you can get with a simple rails new your_app -j esbuild The only sort of issue I’ve had with it so far is you can’t use it with Inertiajs[1] as it does not support dynamic imports out of the box. Although I’m hesitant to call it an issue if its not in the scope of the projec…

Does it not support dynamic imports at all, or does it just not support “dynamic dynamic imports” i.e. dynamic imports where the module path is not constant?

If it’s the latter, you could have your Inertia page resolver be a giant switch statement of every possible page, where each case is a dynamic import call with a constant module name.

Kind of a pain but I think I’d prefer that if it meant I never had to write a webpack config again.

Re: Esbuild – An extremely fast JavaScript bundler

#143

Post by dkdbejwi383 »

tiew9Vii wrote: post #45
phillu wrote: post #26

I'm using this to compile typescript lambda functions for AWS with great success. Combined with cdk and its NodeJsFunction you can even deploy/compile without local docker.

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…

`eslint && tsc --noEmit && esbuild` or something like that, just simple process chaining. Means you can build something you know is going to be illegal to the TypeScript compiler, but you want to very quickly test an assumption, for example.

Re: Esbuild – An extremely fast JavaScript bundler

#144

Post by betageek »

ZephyrBlu wrote: post #105
CodeIsTheEnd wrote: post #41

Work on esbuild started at the start of 2020. It is primarily authored and maintained by Evan Wallace, who, in addition to making this tremendous contribution to the JavaScript ecosystem, is the CTO and co-founder of Figma . Incredible output.

I don't understand this perspective. Everyone only has so many hours in a day, and there's only so fast you can work. If he's writing esbuild that is taking time away from being the CTO of Figma. Either he's working a shit ton, one of the things (Esbuild or Figma) is being somewhat neglected, or his output is actually not as high as it looks.

CTO and lead developer on a focused project are very different jobs - my guess would be he relaxes from the very strategy and soft-skill heavy day job by diving into a challenging problem that keeps his dev chops up and lets him focus on a finite problem.

Re: Esbuild – An extremely fast JavaScript bundler

#145

Post by intruder »

enjikaka wrote: post #100
baybal2 wrote: post #78

Earlier quoted context omitted.

Webpack is a bane of webdev existence. Having junior team encounter a webpack breakage === them spending as much time on tooling, as coding itself

I cannot count the days I've spend on webpack config breakage during the last years at work. It's never really been good at all either. The gulp setup we had before worked faster, better and didn't break once a month. Webpack really only is a pet project of the idiocratic React-community. Facebook not only screws your personal data over, also your dev workflow!

what are you talking about, webpack has nothing to do with Facebook or React.

Re: Esbuild – An extremely fast JavaScript bundler

#146

Post by ZephyrBlu »

betageek wrote: post #144
ZephyrBlu wrote: post #105

Earlier quoted context omitted.

I don't understand this perspective. Everyone only has so many hours in a day, and there's only so fast you can work. If he's writing esbuild that is taking time away from being the CTO of Figma. Either he's working a shit ton, one of the things (Esbuild or Figma) is being somewhat neglected, or his output is actually not as high as it looks.

CTO and lead developer on a focused project are very different jobs - my guess would be he relaxes from the very strategy and soft-skill heavy day job by diving into a challenging problem that keeps his dev chops up and lets him focus on a finite problem.

So working a shit ton then.

Re: Esbuild – An extremely fast JavaScript bundler

#147

Post by Vinnl »

chrisjc wrote: post #141
Vinnl wrote: post #53

Earlier quoted context omitted.

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.

First, forgive my ignorance of the JS/TS and bundler ecosystems. > while in parallel checking for type errors. Why are you suggesting this not be done during development? Is it bc while ESBuild is fast and runs in parallel, it's still only as fast as the slowest parallelized task, and in this case the slowest task is checking for type errors? And I assume checking for type errors is the slowest because it has to invo…

You can absolutely run it during development! In fact, many people will use an editor that automatically does this and highlights any potential errors - which means you don't need your compiler to display them (or even block compiling) as well.

And yes, type checking is relatively slow, and also strictly extra work, since it's not required to make your code runnable.

You'll often see that people do still do a more thorough production build in their CI systems, but not necessarily by using a bundler that includes type checking; rather, they just run type checking and bundling as separate tasks. That way, you do indeed get all the verification you would like without having to delay deployment.

(To make it somewhat more confusing, a project like Vite does use a fast bundler (ESBuild) during development and a more thorough one for production (Rollup), but that's independent of type checking. It's more about the latter doing more optimisations, and the former merely making the code runnable by the browser.)

Re: Esbuild – An extremely fast JavaScript bundler

#148

Post by antihero »

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…

We're using Vite and enjoying it, would you say much of Vite could be replaced with pure esbuild?

I guess Vite provides a nice development experience but is built on esbuild.

Re: Esbuild – An extremely fast JavaScript bundler

#149

Post by iruoy »

gyosko wrote: post #99
petethepig wrote: post #47

Great job on the landing page — that simple animation tells an incredibly simple and compelling story all in 800x200 pixels. I wish more products had landing pages that looked like that.

It is very easy to be misleading though: https://github.com/evanw/esbuild/issues/669

I don't think rejecting a comparison with an uncomplete nightly build is unfair. It looks like it was added a little after this issue was closed because the blocker was fixed.

Parcel 2 was released as stable yesterday though and Evan has already updated comparison.

https://github.com/evanw/esbuild/commit/186446eae8cc8c7439eb...

Re: Esbuild – An extremely fast JavaScript bundler

#150

Post by [deleted] »

swhitf wrote: post #113

You know you are getting old when you watch the arrival of the fourth JavaScript build tool of your career. I still remember when everyone was waving goodbye to Gulp in favour of Webpack. Webpack was going to save us all from the hell of massive convoluted gulp.js files. Fast forward five years and it's the same mess it was supposed to avoid. Slow, bloated and confusing. I just switched to esbuild on our main project…

[deleted]
Post reply on HN