Live data from Hacker News

Some notes on using esbuild

jvns.ca

31–40 of 205 posts

Re: Some notes on using esbuild

#31
post #20
post #16

If you're going to have a build step at all, instead of hand rolling your build commands and configs, just use Vite[1] already. It uses esbuild for development and rollup for production (since esbuild is not featureful enough for a lot of production use cases), you get instantaneous startup, hot module replacement, static asset imports, etc. for free. It's from Evan You, the creator of Vue, but it also supports React…

I don't understand the point of vite. I tried using it and the "build" took over 30 seconds. esbuilds takes less than 1 second for the same project. > esbuild is not featureful enough for a lot of production use cases What makes you say that? I keep hearing people say this, but I haven't run into any problem that make esbuild not ready for production.

The purpose of vite is not to be fast for build, but to be a live reload instant dev platform. So you almost never run build. You code with vite's server, and it let you see the result instantly in the browser. You can use modules, modern js, and transpiled languages transparently.

Then when you put in prod, you build once. 30s once a day doesn't matter.

Re: Some notes on using esbuild

#32
post #23
post #20

Earlier quoted context omitted.

I don't understand the point of vite. I tried using it and the "build" took over 30 seconds. esbuilds takes less than 1 second for the same project. > esbuild is not featureful enough for a lot of production use cases What makes you say that? I keep hearing people say this, but I haven't run into any problem that make esbuild not ready for production.

> I tried using it and the "build" took over 30 seconds. It hardly matters because it's very rare that you need to run build during development. Use dev. > I keep hearing people say this, but I haven't run into any problem that make esbuild not ready for production. https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...

I read that as yet another 30 seconds for a CI or production build, on top of every other inefficient tool shipping with an inflated sense of necessity and no feel for devops concerns. Accepting such into your toolset remains a primary source of creeping bloat.

The JS ecosystem is riddled with such pests, and (as with webpack) eradication from our workflows always proves by far the best policy.

Re: Some notes on using esbuild

#33
post #23

Earlier quoted context omitted.

> I tried using it and the "build" took over 30 seconds. It hardly matters because it's very rare that you need to run build during development. Use dev. > I keep hearing people say this, but I haven't run into any problem that make esbuild not ready for production. https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...

I read that as yet another 30 seconds for a CI or production build, on top of every other inefficient tool shipping with an inflated sense of necessity and no feel for devops concerns. Accepting such into your toolset remains a primary source of creeping bloat. The JS ecosystem is riddled with such pests, and (as with webpack) eradication from our workflows always proves by far the best policy.

Sure, please contribute to esbuild so that it solves more of people's actual needs. It's not like Evan doesn't want to switch to esbuild in Vite completely. My link to "Why Not Bundle with esbuild?" should be a good start for where you should look.

Re: Some notes on using esbuild

#34
post #7

Julia is one of my favorite examples of learning in public as a developer. Her technical chops are unquestioned so when she says things like "I have no idea what import does" it really drives home how much the JS community has to do to bring along the rest of the developer population who just wants to make web stuff occasionally without going to JS Build Tool University. I love this and maybe it would be great for so…

My thoughts exactly! I'm mostly a backend developer and also fine with doing occasional frontend stuff as long as the build system works, but when npm croaks with one of its cryptic error messages, I wouldn't know where to begin to fix it, and that's extremely frustrating...

Re: Some notes on using esbuild

#35
post #30

> problem 1: libraries that tell you to npm install them Agreed. I wish `npm install` was just some option for those who wanted it. But no! Somehow it became the defacto standard and everyone just expects everyone else to already be onboard. I got onboard reluctently because that's the only way to use the libraries I cared about. > problem 2: I don’t understand frontend build tools Absolute and total agreement. I can…

(Misunderstood comment)

Re: Some notes on using esbuild

#36
post #35
post #30

> problem 1: libraries that tell you to npm install them Agreed. I wish `npm install` was just some option for those who wanted it. But no! Somehow it became the defacto standard and everyone just expects everyone else to already be onboard. I got onboard reluctently because that's the only way to use the libraries I cared about. > problem 2: I don’t understand frontend build tools Absolute and total agreement. I can…

(Misunderstood comment)

> If you want a unix-style tool

I actually don't. esbuild not being unix-style is a good thing in my opinion.

Re: Some notes on using esbuild

#37
post #20

Earlier quoted context omitted.

I don't understand the point of vite. I tried using it and the "build" took over 30 seconds. esbuilds takes less than 1 second for the same project. > esbuild is not featureful enough for a lot of production use cases What makes you say that? I keep hearing people say this, but I haven't run into any problem that make esbuild not ready for production.

ESBuild doesn't transpile your code down to ES5. If you're using any ES6 features - default params, template literals, arrow functions, let/const, spread, etc, your cut-off for browser support will be ~2017 (= no support for IE 11). swc ( https://swc.rs ) does transpilation and it's as fast as esbuild. Setup is slightly more complex. I'm hoping esbuild will add ES5 transforms at some point, would much rather have a G…

IE (all versions) seems to have 1-2% market share, so I'm not sure it's worth jumping through hoops for.

Re: Some notes on using esbuild

#38
post #7

Julia is one of my favorite examples of learning in public as a developer. Her technical chops are unquestioned so when she says things like "I have no idea what import does" it really drives home how much the JS community has to do to bring along the rest of the developer population who just wants to make web stuff occasionally without going to JS Build Tool University. I love this and maybe it would be great for so…

Can you link which Julia you are speaking about?

Re: Some notes on using esbuild

#39
post #7

Julia is one of my favorite examples of learning in public as a developer. Her technical chops are unquestioned so when she says things like "I have no idea what import does" it really drives home how much the JS community has to do to bring along the rest of the developer population who just wants to make web stuff occasionally without going to JS Build Tool University. I love this and maybe it would be great for so…

Can you link which Julia you are speaking about?

The author of the article

Re: Some notes on using esbuild

#40
post #27

Earlier quoted context omitted.

> instead of hand rolling your build commands and configs, just use Vite[1] already. For greenfield projects? Certainly. For existing projects? Oh, you're in for a world of pain. I'm all for breaking with the old and ushering the new era in, but there should be an upgrade path for as many possible combinations of the old as possible . As luck would have it I decided to convert our project to vite to see if it's feasi…

The sane option would be to use a codemod to rewrite your code to not need bespoke tooling configurations. You are locking yourself into legacy tooling.

> The sane option would be to use a codemod to rewrite your code to not need bespoke tooling configurations.

1. Absolute paths are not "bespoke tooling config", it's a tsconfig setting

2. Requiring some code to be served from a specific url is not "bespoke tooling config", it's a requirement for quite a few projects

3. Forcing someone to mindlessly and absolutely needlessly re-write thousands of import statements isn't really a solution

4. This will still not fix "failed to resolve "extends":"../../tsconfig.json"" and who knows what other errors

Post reply on HN