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

Some notes on using esbuild

jvns.ca

Post reply on HN
Print view View original

41–50 of 205 posts

Re: Some notes on using esbuild

#41

Post by dmitriid »

oefrha wrote: post #25
dmitriid wrote: post #21

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…

Point taken, but it's not like switching the average existing webpack project (let alone a webpack 4 project) to esbuild is just a walk in the park. We're talking about whether you should roll your own esbuild commands here.

Yeah, it looks like rolling our own esbuild commands might be the way to go because "just switch to vite already" doesn't work, does it?

Re: Some notes on using esbuild

#42

Post by Griffinsauce »

dmitriid wrote: post #21
oefrha wrote: 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…

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

Your best bet is to try and remove as much config as possible first. Simplify and then migrate or upgrade.

Webpack allows you to paint yourself so far into a corner that it becomes impossible to move anywhere. We should see this for what it is: an existential threat for your app. It eventually grinds everything to a halt.

Re: Some notes on using esbuild

#43

Post by Zababa »

mkl wrote: post #37
ricardobeat wrote: post #24

Earlier quoted context omitted.

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.

IE usage could be 50% in your industry, or your company may guarantee IE support for one reason or another. Global stats aren't always representative of your business.

Re: Some notes on using esbuild

#44

Post by oefrha »

dmitriid wrote: post #41
oefrha wrote: post #25

Earlier quoted context omitted.

Point taken, but it's not like switching the average existing webpack project (let alone a webpack 4 project) to esbuild is just a walk in the park. We're talking about whether you should roll your own esbuild commands here.

Yeah, it looks like rolling our own esbuild commands might be the way to go because "just switch to vite already" doesn't work, does it?

If you can roll your own esbuild commands to build your codebase without change, good for you. Once you’ve done that, good luck figuring out a dev server with HMR, since esbuild certainly doesn’t offer that.

Re: Some notes on using esbuild

#45

Post by betageek »

swyx wrote: 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…

I don't understand why people are holding JS to a higher standard than other languages, is it just because it used to be easier?

Knowing nothing about Java, I wouldn't expect to open a Java file and know what every line means. There's a million reasons to find modern web dev complicated but not taking the time to google "js import" is not one of them. Also I wouldn't expect to "just know" how to take a Java program and build it in a way that I could host it somewhere, I'd expect to have to work at it.

Re: Some notes on using esbuild

#46

Post by irishsultan »

phist_mcgee wrote: post #38
swyx wrote: 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?

If you click on the link and read the header (not the actual article or it's title) you will see that it's posted on Julia Evans blog. That should answer your question.

Re: Some notes on using esbuild

#47

Post by dmitriid »

Griffinsauce wrote: post #42
dmitriid wrote: post #21

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…

Your best bet is to try and remove as much config as possible first. Simplify and then migrate or upgrade. Webpack allows you to paint yourself so far into a corner that it becomes impossible to move anywhere. We should see this for what it is: an existential threat for your app. It eventually grinds everything to a halt.

> Your best bet is to try and remove as much config as possible first.

Which config?

> Webpack allows you to paint yourself so far into a corner

https://news.ycombinator.com/item?id=29239108

Re: Some notes on using esbuild

#48

Post by 3np »

BiteCode_dev wrote: post #31
hsn915 wrote: 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.

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.

It does matter in a CI environment. Using a different build procedure there is not optimal.

Re: Some notes on using esbuild

#49

Post by smt88 »

nicoburns wrote: post #26
ricardobeat wrote: post #24

Earlier quoted context omitted.

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…

Plain esbuild is perfect for adding typescript support to node.js projects. We literally just run ’esbuild && node dist/run.js’

How is this different from `tsc && node dist/run.js`?

Re: Some notes on using esbuild

#50

Post by 3np »

betageek wrote: post #45
swyx wrote: 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…

I don't understand why people are holding JS to a higher standard than other languages, is it just because it used to be easier? Knowing nothing about Java, I wouldn't expect to open a Java file and know what every line means. There's a million reasons to find modern web dev complicated but not taking the time to google "js import" is not one of them. Also I wouldn't expect to "just know" how to take a Java program a…

I think it's more that depending on your point in time, build process and environment, `import` has changed meaning every couple of years.

I consider myself having deeper knowledge about JS and node than any other language, having spent more total time in it than anything else (except maybe bash).

I have a clearer understanding of what import/require really does in most other languages.

The flow-chart complexity and possible outcomes of what `import` really does in JS/TS are certainly greater than anything else I've encountered.

(I do find go's repository-based approach quite frustrating to work with when forking dependencies but at least it's straight-forward)

Post reply on HN