Hacker News new | ask | show | jobs
by afavour 1128 days ago
> The binaries are pretty huge, hoping they can bring that down in time.

I'm surprised the numbers are as high as they are and hope they can reduce them... but they'll never get down to the kind of numbers Go and Rust get to because Bun depends on JavaScriptCore, which isn't small, and unless they're doing some truly insane optimizations they're not going to be able to reduce its size.

FWIW QuickJS is a tiny JS runtime by Fabrice Ballard... that also supports creation of standalone executables: https://bellard.org/quickjs/quickjs.html#Executable-generati... though its runtime speed is considerably worse than JSC or V8.

4 comments

For 90% of things this will be used for, it's more than enough so it might be a good default unless you enable a `-Ojit` flag when building more complex applications where the JIT will be a benefit. In fact, startup times might even be faster.

The challenge of course is supporting two JS runtimes within the same codebase.

Yeah I suspect the weird little differences between runtimes (e.g. what language features they do and do not support) would lead you down a path of a thousand cuts.

It still feels like a graceful idea, though.

> but they'll never get down to the kind of numbers Go and Rust

Can we please not put the two next to each other? There is absolutely nothing similar between the two.. why don’t mention go and haskell, or go and D instead?

JSC is ridiculously fast, this is what makes bun great
It really depends on what you're doing. If 95% of your code is file or network I/O then it's really not going to make the slightest difference whether you're running JSC, V8 or QuickJS. If your code is enormously complex and benefits from JIT then yes, you're going to really feel that downgrade.
The difference in real world performance between web servers written in things like Python or Ruby to those written in Go, C# or even lower-level languages like Rust would indicate that's an over-estimation of how much IO dominates total runtime, even if it is by far the slowest part.
Why is JavascriptCore so big? What's going on internally to end up with binaries that big?