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

Esbuild 0.9

github.com

Post reply on HN
Print view View original

41–50 of 123 posts

Re: Esbuild 0.9

#41

Post by keraf »

ccmcarey wrote: post #24
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.

Think that's out of scope - doesn't snowpack (which uses esbuild) cover this though? https://www.snowpack.dev/

Snowpack uses ESM for development which allows really fast HMR. And ESBuild is used for production builds. Best of both worlds.

Re: Esbuild 0.9

#42

Post by madjam002 »

nicoburns wrote: post #19

ESbuild is excellent for using with TypeScript and Node.js. We were previously using Nodemon to restart the server on changes. ESbuild is fast enough that rather than having to change our workflow and run a tsc --watch process in addition to Nodemon (which would be rather a pain given that we have 5-6 microservices), we simply use ESbuild to recompile the entire service before restarting the code (it takes about 0.1…

Amazing stuff, I was thinking of doing pretty much exactly this this morning.

Out of interest, if you’re bundling with Esbuild before running, how do you cope with native dependencies?

Re: Esbuild 0.9

#43

Post by nicoburns »

madjam002 wrote: post #42
nicoburns wrote: post #19

ESbuild is excellent for using with TypeScript and Node.js. We were previously using Nodemon to restart the server on changes. ESbuild is fast enough that rather than having to change our workflow and run a tsc --watch process in addition to Nodemon (which would be rather a pain given that we have 5-6 microservices), we simply use ESbuild to recompile the entire service before restarting the code (it takes about 0.1…

Amazing stuff, I was thinking of doing pretty much exactly this this morning. Out of interest, if you’re bundling with Esbuild before running, how do you cope with native dependencies?

We don't use esbuild's "bundle" (--bundle) option, which means that our files get processed one-by-one and end up as separate files in the `dist` directory that we output to and that dependencies aren't processed at all and are just `required` like normal by our transpiled code.

Our build command (in a bash script file to avoid string escaping issues) is:

    find src -type f \( -name '*.js' -o -name '*.ts' -o -name '*.sql' \) -print0 \
      | xargs -0 ./node_modules/.bin/esbuild --platform=node --format=cjs --outdir=dist --loader:.sql=text

Re: Esbuild 0.9

#44

Post by Scramblejams »

qbasic_forever wrote: post #37

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.

Yep, I tried front-end way back and hated it. Can you mention some other tech that should be covered in my re-evaluation?

Re: Esbuild 0.9

#45

Post by connor4312 »

earthboundkid wrote: post #26
picardo wrote: post #16

Earlier quoted context omitted.

esbuild can be a good alternative to Webpack in some cases, but Webpack solves a lot of edge cases well. For example, just today I debugged an issue where a library had used `require` in an ES module instead of `import`, and that broke the build with esbuild. So I had to fork the library to fix that issue. Webpack handles that case without problems. I can think of at least a few cases like that where Webpack works be…

> Webpack solves a lot of edge cases well I would quibble with the word "solves". Webpack is a tool building tool. With Webpack, you can build a tool to solve your edge case problem, as long as you're willing to spend a lot of time and dig through random Github issues for your dependencies. Webpack itself however does basically nothing.

> Webpack itself however does basically nothing

This is not the case. I love esbuild and hope to see it go far, but Webpack does out of the box most of what esbuild (today) does as well, with the notable exception of TypeScript /jsx transpilation. For more advanced scenarios, like dealing with css modules, you do need plugins -- but esbuild doesn't support most of these scenarios today at all.

It's like saying VS Code does nothing: you probably want extensions to help you out and let you do more complex things more easily, but it doesn't "do nothing" out of the box.

Re: Esbuild 0.9

#46

Post by nicoburns »

snemvalts wrote: post #23

For those who are actively using esbuild with TypeScript, how do you check the types?

In 3 ways:

- Using the Language Server Plugin in editors

- `npx tsc --noEmit` in a pre-commit hook

- `npx tsc --noEmit` in CI

Re: Esbuild 0.9

#47

Post by uses »

I tried this a week or so ago, and it was indeed 100x or 1000x as fast as my webpack setup. Shocking, really. I couldn't get dynamic imports / code splitting working, which seemed to not be fully implemented yet. I also wasn't sure how to make polyfills happen.

Re: Esbuild 0.9

#49

Post by earthboundkid »

brundolf wrote: post #40
earthboundkid wrote: post #31

Earlier quoted context omitted.

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

1. My complaint is not about speed.

2. Node is much better than Python because the correct location on disk is pretty much project/node_modules. However, it is still that case that e.g. Babel was broken by Node 12.17.0 [1] last year, which necessitates something like NVM. I don't want to deal with that for my build tools. I just want a binary that is known to work to continue to work until it is replaced.

3. Yes, conventionally everything in Nodeland was written out to dist as ES5. This also sucks ass because now you end up shipping a bunch of ES5 crap to your end users even though you aren't targeting ES5. It is very hard to build an actual ES2020 module unless you're willing to not use external dependencies at all. Snowpack et al are shifting this slowly, but it has barely even begun as a trend.

[0] https://nodejs.org/en/blog/release/v12.17.0/ https://www.google.com/search?q=babel+compat+data+corejs3+sh...

Re: Esbuild 0.9

#50

Post by EMM_386 »

qbasic_forever wrote: post #37

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.

I agree. I was a web developer in the 90s when stuff was primitive, ugly and difficult.

I switched to desktop .Net development in 2001 did that for almost 15 years.

Since then I have been back on the web. I am full-stack so I find myself switching between front-end and back-end frequently.

I am enjoying my time more in the world of TypeScript, VS Code, and Angular than I am writing the back-end REST APIs in .Net Core and Visual Studio.

I was dreading going back to web development when I switched back again but recently it has turned out to be nicely structured, performant, logical and enjoyable.

Post reply on HN