4 ms·
It’ll take a lot to replace esbuild for me -- it’s fast enough that it’s never the bottleneck and more importantly has always been absolutely rock-solid and rel
by iainmerrick 3y ago
It’ll take a lot to replace esbuild for me -- it’s fast enough that it’s never the bottleneck and more importantly has always been absolutely rock-solid and reliable. So a tool that’s 2x faster but less reliable isn’t appealing.
- throwme_123 3y agobun seems great and promising but I'm in the same boat. vite/esbuild with vitest is running perfectly, and already fast enough (and at last not struggling with webpack or rollup overall poor quality anymore...).
- silverwind 3y agobun can run vite prod build at least and seems about 10% faster at it than node according to my testing.
- iainmerrick 3y agoYep, vite is really nice too.
- eyelidlessness 3y agoMy problem with “Vite is good enough” and “Vitest is good enough” as a paired hypothesis is they are literally opposite in their target environments. It’s explicitly unsupported to use Vite to build projects specifically for Node as a target, and it’s explicitly unsupported to test in Vitest in browser environments (though I think that’s being actively addressed, but it’s still going to be a second class solution).
- throwme_123 3y agoIt depends of what you mean by browser environments (integration tests?), but vitest with happy-dom is working great for testing libraries and components.
- 8n4vidtmkvmk 3y agoI've had bad experiences with esbuild. Don't remember what specifically but didn't work for my use cases. Roll-up for libs and webpack for apps. Only thing that works for me and all the wonky edge cases involved in building for web and node and npm and old browsers and various file types and loaders and whatnot.
- reilly3000 3y agoIt isn’t clear to me that bun is less reliable. A day old bundling tool is not a fair yardstick for what I’m referring to. In general I haven’t heard about any reliability issues and see glowing reviews about its cold start time and thorough-put. If there are any I should be aware of please do share.
- iainmerrick 3y agoI was just thinking about the sort of issues described in this post, like having to use specific flags to prevent the minifier breaking code, or write an extra pass to tweak the output. I’d worry about what other problems there might be that I hadn’t noticed yet. Presumably those will get fixed over time, and at some point bun will just work if you want to replace your existing bundler. But even then, I personally would lean to sticking with esbuild as it’s more than fast enough for my purposes -- extra speed isn’t a compelling selling point (for me).
- shaneos 3y agoYes, Bun is very much in beta, but it's already really, really good. I'm fine using it with my hobby projects right now, but once it gets to 1.0 I'll give serious consideration to using it in production code too. The API is really simple, and I love how it just understands Typescript, so you can throw any code in your repo at it and it chugs away happily.
- iainmerrick 3y agoYes, being able to just run TS directly is very appealing. When I last tried, neither bun nor deno nor ts-node worked out of the box for me. The other two seem to be a bit stuck in the weeds (deno aggressively trying to do its own thing, then backtracking and adding node compatibility back in; ts-node hampered by having to work around weird design decisions in both node and TS) so I wouldn’t be surprised if bun ends up as the winning TS engine.
- intelVISA 3y agoINCREDIBLY less reliable! Even the sole dev would admit as much if you could distract them from their VC handlers. Gotta go with libre tools for these cases unfortunately. Nothing against Bun specifically of course, just the concept of capital + dev tools is something that must be re-learned as evil time and time again.