Hacker News new | ask | show | jobs
by brrrrrm 1398 days ago
Congrats to Jarred! Bun has blown me away in terms of performance. Often (in other projects) performance claims out of nowhere are simply cherry-picked but I’ve found bun repeatedly impressing me with both speed and elegance.

What doesn’t get mentioned enough is just how friggin ergonomic bun is. Install it and you’ll see what I mean immediately. Play with any API in the “bun:” namespace and it’s just a breath of fresh air.

3 comments

I'm curious about where all that performance comes from

I know it uses the WebKit JS runtime instead of V8, which is super interesting. Does that cause a performance lift? Or is there some other secret sauce that pervades throughout Bun? Or is it just a matter of Jarred giving lots of attention to spot-optimizing the most important bottlenecks outside of the core runtime?

There's no secret sauce

Just lots of time spent profiling and trying things

On the runtime side, JavaScriptCore/WebKit's team are extremely receptive to feedback, especially performance-related. Today, @Constellation made `Promise.all` about 30% faster https://github.com/WebKit/WebKit/pull/3569

Have you done any comparisons with Graal’s NodeJS runtime?
It's worth noting that most of Node's API are written in JavaScript, and often not particularly optimised JavaScript (sometimes constrained by API compatibility). I think bun is taking the approach of implementing a lot of core APIs in zig.
That's surprising, I didn't know that about Node
I suspect it’s the latter. I would guess V8 with a thin wrapper and a ton of effort from someone who cares about perf to port all the native goodies of node would get similar wins.
Absolutely. And it has been done already, JustJS[1] has made it to the top 10 fastest in the TechEmpower benchmarks. It’s Linux only though, and not nearly as complete or easy to use, which makes it unappealing for real world projects.

[1] https://github.com/just-js/just

Good thing Cloudflare is open-sourcing their V8-based Workers runtime soon.
I'm curious if it will be as fast after implementing some must have features like sourcemaps, minification, and tree shaking? Bun is definitely not production ready yet, but I'm keeping my eye on it for sure

https://github.com/oven-sh/bun#not-implemented-yet

Sourcemaps are technically already implemented, but not for bundled dependencies. Initially, it was a 30% drop, but I made it use lots of SIMD and that compensated a lot. When you use Bun's runtime, it transpiles every file (including non-TypeScript files) and generates an in-memory sourcemap so that error messages have useful line/column numbers. Bun's fast startup time is very much in spite of things like this.

Minification will likely make it faster because there will be less code to print (see https://twitter.com/evanwallace/status/1396304029840396290). Many of the syntax compression and small optimizations like ("foo" + " " + "bar") becoming "foo bar" are implemented already, but not the whitespace removal

It might have an impact on bundling performance overall because that will involve an extra pass to more correctly handle `export * as from`, which isn't as important when used with the runtime (since that can happen at runtime)

I'm not looking to use Bun as a JS runner because all of my JS runs in the browser. The time and complexity of implementing these processes will increase build time. We will have to wait to see how it compares to existing tools for bundling and creating production code.
> I'm curious if it will be as fast after implementing some must have features like sourcemaps, minification, and tree shaking?

Can you explain why you think a transpilation step will prove to be a technical challenge here? The "bundler" part of Bun seems like a very small piece, and not something that would impact its performance as a runtime too greatly.

A lot of the conversation around Bun's performance has included the performance of non-runtime things like how fast it can install packages, perform builds, cold-start, etc
I only use JS/TS on the client side, which will end up running in the browser, thus being able to use Bun to create production code will require these features. I didn't say they were technical challenges, but these processes require more complex analysis and algos.
I’m not familiar with deployment in the modern web world, but I’m curious how fast those specific features need to be in a production setting? Are they done dynamically for every request?
> Often (in other projects) performance claims out of nowhere are simply cherry-picked

I’ve had it proven true only two times so far. First time was with esbuild.