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.
Esbuild 0.9
21–30 of 123 posts
Re: Esbuild 0.9
#22esbuild 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.
Re: Esbuild 0.9
#23For those who are actively using esbuild with TypeScript, how do you check the types?
Re: Esbuild 0.9
#24As 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/
Re: Esbuild 0.9
#25As 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]
Re: Esbuild 0.9
#26Hell yes, esbuild is an amazing tool. I not only use it in most CRA projects (where it replaces webpack and builds everything at least two times faster), but it's also easy to use for plain HTML pages to add some interactivity without writing thousands of lines of webpack black magic: esbuild App.tsx --define:process.env.NODE_ENV=\\\"production\\\" --bundle --minify --target=es6 --outfile=out.js where App.tsx is your…
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.
Re: Esbuild 0.9
#27How does this compare to https://www.snowpack.dev/ ?
[deleted]
Re: Esbuild 0.9
#28For those who are actively using esbuild with TypeScript, how do you check the types?
I run tsc with noEmit passed as a flag. Esbuild is replaces my previous tsc, babel, uglify setup and is much faster.
Re: Esbuild 0.9
#29For those who are actively using esbuild with TypeScript, how do you check the types?
What some people do is use types purely for editor purposes, and let the build process just throw them away. We did this at my last company using Babel
Re: Esbuild 0.9
#30How does this compare to https://www.snowpack.dev/ ?
Snowpack uses esbuild internally now, there's a good rundown of it and other awesome snowpack features like streaming imports in their 3.0 release announcement: https://www.snowpack.dev/posts/2021-01-13-snowpack-3-0