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

121–130 of 288 posts

Re: Esbuild – An extremely fast JavaScript bundler

#121

Post by ZephyrBlu »

zerocount wrote: post #117
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.

Maybe there's not much to do as the CTO of Figma. Throwing time into Esbuild doesn't mean he's neglecting his CTO duties.

In which case my last option would be relevant:

> or his output is actually not as high as it looks

Re: Esbuild – An extremely fast JavaScript bundler

#122

Post by strzibny »

Both Rails 7 and Phoenix 1.6 is going off Webpack by default and I am so looking into the esbuild future. I never really liked Webpack to be honest.

I already replaced Webpack in my Phoenix project (you can compare default steps for building a release here https://nts.strzibny.name/12factor-elixir-phoenix-releases/) and cannot wait to do the same in Rails.

Re: Esbuild – An extremely fast JavaScript bundler

#123

Post by RobertKerans »

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…

You're likely literally doing the same thing with Webpack. There is only one complete implementation of the TS compiler in existence, so you have to use that to typecheck, it doesn't matter what bundler tool is used. If you need the type definitions as part of the output (eg you are distributing a library), then you have to involve the compiler to construct the output definition files, but for the code itself, it doesn't really matter because you're just generating JS. The TS compiler is very slow (and in any case is not designed to produce code bundles - it just dumbly translates all the TS to JS), so the standard way to speed this up is to use a module bundling tool that ignores the types and compiles the code as JS, and have the TS compiler set to not emit any files itself.

Nothing in the above precludes using the compiler to typecheck the code, that's the primary usecase & what sibling is saying about thinking of it as a linter: if typechecking fails, don't build

Re: Esbuild – An extremely fast JavaScript bundler

#124

Post by baxuz »

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…

How is the integration with things like a dev server and tools present in create-react-app like react-fast-refresh?

Also, in case of working on an Electron project: How well does it handle main/render/preload compile targets and handling of native modules and linking?

Electron-forge is, for instance, the recommended toolchain for building Electron apps and the Webpack stuff is a particular pain in the ass.

Re: Esbuild – An extremely fast JavaScript bundler

#125

Post by pedrow »

qeternity wrote: post #79

What’s the catch? Do they really have a secret sauce or are there limitations in esbuild to achieve these speed ups?

It doesn't always work in situations where 'require' can't be statically evaluated at run-time (webpack would work in this situation) - for example I filed a bug recently[0] Even though the bug was closed I was impressed with the thorough and timely response from the esbuild developers which explained the reasoning behind it. For me it was worth changing my project just so I could continue using esbuild, it really is that good!

[0]: https://github.com/evanw/esbuild/issues/1619

Re: Esbuild – An extremely fast JavaScript bundler

#126

Post by koolba »

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…

> I just switched to esbuild on our main project and the build time went from 7 minutes on CI to 1 second.

Is that an exaggeration or did it really get 420x faster?

Re: Esbuild – An extremely fast JavaScript bundler

#127

Post by Aeolun »

baxuz wrote: post #124
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…

How is the integration with things like a dev server and tools present in create-react-app like react-fast-refresh? Also, in case of working on an Electron project: How well does it handle main/render/preload compile targets and handling of native modules and linking? Electron-forge is, for instance, the recommended toolchain for building Electron apps and the Webpack stuff is a particular pain in the ass.

> How is the integration with things like a dev server and tools present in create-react-app like react-fast-refresh?

It’s not. It doesn’t do hot reloading, and it’s one of the features the author rejected I think.

Re: Esbuild – An extremely fast JavaScript bundler

#128

Post by KingOfCoders »

On another thread were I said I don't like build tools/compilers in the same language as they work on, when the language is slow, I got voted down.

Here everyone: JS build tool in Go? Great!

+1 for parallelism of esbuild. I have a12 core machine and many tools either use one core or when forced to not benefit from more cores.

I also wish they would waste more memory, I have 32gb which re mostly unused even by large projects.

I stand by my opinion: dev tools should make it pleasant for developers not the tool writers.

Re: Esbuild – An extremely fast JavaScript bundler

#129

Post by have_faith »

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…

I always found it amusing going from Grunt (unwieldly huge object based config) to Gulp (config is code, pipe transformations together in a simple unix'y way) to being told webpack is the future (huge unwieldly config objects again). Definitely felt like a step backwards although I appreciate the power webpacks gives to people building boilerplates like Create-react-app. I rarely use Gulp anymore but I still appreciate it's UX/DX.
Post reply on HN