Esbuild 0.9 • Hacker News Board

Re: Esbuild 0.9

#31

Post by earthboundkid » Tue, Mar 09, 2021, 6:24 PM UTC

afavour wrote: post #22

AbuAssar wrote: post #6

esbuild makes it pretty clear that writing the JS ecosystem in JS is a bad choice*. now we need to rewrite tsc/babel/npm/eslint/etc... in a language that compile down to native binary that is also cross platform (like go or rust), to gain the same performance improvements across the entire JS tool-chain. * based on the benchmark on their landing page.

I don’t know about that. Just look at the performance difference between NPM and Yarn: both built with JS, but for me at least Yarn is way, way faster. I’m sure it would make sense to rewrite certain things in Rust or Go (then possibly pull them into Node as native modules) but they’re not magic. Good engineering will win out no matter what.

Good engineering is definitely key, but I think interpreted languages are a bad fit for developer tools (though they are extremely popular for writing developer tools). On the surface, writing JS tools in JS is good because hey, you definitely know JS, right? But in practice it is bad because I don't want the JS I am writing in any way constrained by the JS you wrote.

The problem with any interpreted language is that to run the tool you need all the source and all the dependencies plus the interpreter in something like their intended versions to be present in the right locations on disk. This is a huge PITA, and if you're say writing JavaScript targeting ES5 but your tools are targeting ES2020 or vice versa, there can be painful yak shaving sessions getting everything on the same page.

Essentially all developer tools should be static binaries.

Re: Esbuild 0.9

#32

Post by jakelazaroff » Tue, Mar 09, 2021, 6:24 PM UTC

deanclatworthy wrote: post #13

AbuAssar wrote: post #6

esbuild makes it pretty clear that writing the JS ecosystem in JS is a bad choice*. now we need to rewrite tsc/babel/npm/eslint/etc... in a language that compile down to native binary that is also cross platform (like go or rust), to gain the same performance improvements across the entire JS tool-chain. * based on the benchmark on their landing page.

I think this comment undervalues the quality of engineering that Evan has put into esbuild. It’s not only quick because it’s written in golang, but also due to the decisions taken in architecture and an opinionated tool that does mainly one thing well.

I don’t read OP as devaluing Evan’s work. Presumably the TypeScript/Webpack/etc teams are also doing great engineering work — but because they’re writing in JS, the performance ceiling is significantly lower.

Re: Esbuild 0.9

#33

Post by brundolf » Tue, Mar 09, 2021, 6:24 PM UTC

AbuAssar wrote: post #6

esbuild makes it pretty clear that writing the JS ecosystem in JS is a bad choice*. now we need to rewrite tsc/babel/npm/eslint/etc... in a language that compile down to native binary that is also cross platform (like go or rust), to gain the same performance improvements across the entire JS tool-chain. * based on the benchmark on their landing page.

One of the main benefits of Esbuild (if I recall correctly) is that all passes share a single AST. Whereas in a traditional setup your linter, transpiler, formatter, and sometimes even bundler and minifier all do their own totally independent passes on the source which means parsing it from scratch each time. So this would be a classic case of integrating everything into a monolith for a boost in efficiency.

Re: Esbuild 0.9

#34

Post by parhamn » Tue, Mar 09, 2021, 6:25 PM UTC

lhorie wrote: post #25

parhamn wrote: post #21

As soon as esbuild gets react hot reloading capabilities I’m jumping ship. Although that might be out of scope and there is Vite. I’m hoping to avoid vite and go pure esbuild. Fantastic tool. It will make JavaScript distribution a much more pleasant experience across the board when it gets wider adoption.

He said in the past that he's not interested in implementing HMR[0] [0] https://github.com/evanw/esbuild/issues/97

Makes logical sense from a library/unixy perspective. They offered similar reasoning for not including a file watcher at first but they eventually added that.

HMR is pretty much the last missing piece to make this the only JS bundling and dev tool you need. It would be a bad decision to omit it.

Re: Esbuild 0.9

#35

Post by earthboundkid » Tue, Mar 09, 2021, 6:25 PM UTC

encryptluks2 wrote: post #2

Love how this is used with Hugo: https://gohugo.io/hugo-pipes/js/

Yes. When ESBuild came out, I made a feature request to get it added to Hugo, and I was surprised at how well it has worked out. Goes to show you should always open an issue!

Re: Esbuild 0.9

#36

Post by arcatek » Tue, Mar 09, 2021, 6:27 PM UTC

afavour wrote: post #22

AbuAssar wrote: post #6

esbuild makes it pretty clear that writing the JS ecosystem in JS is a bad choice*. now we need to rewrite tsc/babel/npm/eslint/etc... in a language that compile down to native binary that is also cross platform (like go or rust), to gain the same performance improvements across the entire JS tool-chain. * based on the benchmark on their landing page.

I don’t know about that. Just look at the performance difference between NPM and Yarn: both built with JS, but for me at least Yarn is way, way faster. I’m sure it would make sense to rewrite certain things in Rust or Go (then possibly pull them into Node as native modules) but they’re not magic. Good engineering will win out no matter what.

Speaking of Yarn in particular since I maintain it, I strongly believe that more than speed we (package managers) need a good polish. And to do that, we need a community that feels empowered to make changes when they feel frustrated about something - which makes using JS / TS critical. By contrast, the UX of a bundler / linter is fairly straightforward (compared to Yarn's 46 builtin commands), so making external contributions easier isn't really necessary.

Re: Esbuild 0.9

#37

Post by qbasic_forever » Tue, Mar 09, 2021, 6:29 PM UTC

The JS & frontend world is _seriously fun_ right now. If you blew it all off as a quagmire of complexity, sketchy engineering, treadmill of tools, etc... it's time to re-evaluate everything. I have more fun and feel more productive working on modern frontend stuff with tools like esbuild than any other GUI programming I've done in 30 years.

Re: Esbuild 0.9

#38

Post by qbasic_forever » Tue, Mar 09, 2021, 6:30 PM UTC

parhamn wrote: post #34

lhorie wrote: post #25

Earlier quoted context omitted.

He said in the past that he's not interested in implementing HMR[0] [0] https://github.com/evanw/esbuild/issues/97

Makes logical sense from a library/unixy perspective. They offered similar reasoning for not including a file watcher at first but they eventually added that. HMR is pretty much the last missing piece to make this the only JS bundling and dev tool you need. It would be a bad decision to omit it.

Check out tools like vite or snowpack, which use esbuild internally. They're the HMR developer experience you're looking for.

Re: Esbuild 0.9

#39

Post by izelnakri » Tue, Mar 09, 2021, 6:32 PM UTC

lhorie wrote: post #25

parhamn wrote: post #21

As soon as esbuild gets react hot reloading capabilities I’m jumping ship. Although that might be out of scope and there is Vite. I’m hoping to avoid vite and go pure esbuild. Fantastic tool. It will make JavaScript distribution a much more pleasant experience across the board when it gets wider adoption.

He said in the past that he's not interested in implementing HMR[0] [0] https://github.com/evanw/esbuild/issues/97

I'm actually very happy that esbuild doesnt have HMR by default. Despite the fact that most frontend devs loving/hyping HMR, I prefer live-reloads more because it refetches data/makes network calls and run my route hooks without any additional step. This is particularly important when you run your application tests in the browser(thats better than running app tests in CI btw) and change these test files constantly. The fact that most frontend devs favor HMR over live-reload signals something that I really dislike.

Re: Esbuild 0.9

#40

Post by brundolf » Tue, Mar 09, 2021, 6:33 PM UTC

earthboundkid wrote: post #31

afavour wrote: post #22

Earlier quoted context omitted.

I don’t know about that. Just look at the performance difference between NPM and Yarn: both built with JS, but for me at least Yarn is way, way faster. I’m sure it would make sense to rewrite certain things in Rust or Go (then possibly pull them into Node as native modules) but they’re not magic. Good engineering will win out no matter what.

Good engineering is definitely key, but I think interpreted languages are a bad fit for developer tools (though they are extremely popular for writing developer tools). On the surface, writing JS tools in JS is good because hey, you definitely know JS, right? But in practice it is bad because I don't want the JS I am writing in any way constrained by the JS you wrote. The problem with any interpreted language is that…

Would I be right in guessing that most of your experience with dynamic languages comes from Python?

1) Modern JITed JS is fast. It's closer to Java than it is to what we typically think of as "interpreted languages".

2) "something like their intended versions to be present in the right locations on disk"; Node packages really just depend on the user having a new-enough install of Node and NPM, somewhere in the path. Any dependencies that live on npm will install to the local directory to ensure against conflicts or permissions issues. The only exception I can think of is that occasionally (looking at you, node-sass) npm dependencies will have to do a native build of something and require a local C/++ compiler somewhere in the path. This is pretty rare in my experience, and isn't a super brittle dependency anyway.

3) "if you're say writing JavaScript targeting ES5 but your tools are targeting ES2020 or vice versa, there can be painful yak shaving sessions getting everything on the same page"; this really doesn't happen in any distributed NPM dependencies I've worked with. The great majority are written for the least-common-denominator of environments; if they use ES2020 internally, they'll do their own transpilation step to make sure you can use them in older environments. Also, "or vice versa" really doesn't apply because all ES versions are 100% backwards-compatible. You just need a Node version new enough to cover the newest features that any of your code or dependencies is using. Dependencies will be as compatible as they can be; your own code is under your control. Virtually never an issue.