Earlier quoted context omitted.
As if bun isn't experimental
Node moves pretty slow these days, I wouldn't be surprised if Bun's version gets stabilized before Node's
Has it ever moved fast? It's been at a steady pace for a long time.
Bun 0.6
151–160 of 243 posts
Re: Bun 0.6
#152Earlier quoted context omitted.
Nope. I wouldn't. Not for production. • Bun is not stable yet (0.6.0) • Zig, the language Bun is built upon is not stable either (0.11.0) Nothing against these awesome projects, I'm all in for a streamlined toolchain (TypeScript, bundling, binary generation...) and other excellent goals driving the Deno and Bun teams. But... • Node.js is a powerful piece of software, it's stable and full of battle-tested buttons and…
Bun might be a cool project, but them building on an immature language like Zig makes me wonder where their priorities are.
It wouldn't exist any other way, the story is that it was built with speed as a priority, and Zig was chosen for the performance optimizations it enables.
Re: Bun 0.6
#153Earlier quoted context omitted.
It's why I dove into Go. This definitely took me from the 'eh, kinda cool project' to 'I cant wait to try this out immediately' camp. The binaries are pretty huge, hoping they can bring that down in time.
> 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 runti…
Why is JavascriptCore so big? What's going on internally to end up with binaries that big?
Re: Bun 0.6
#154I work on Bun. Happy to answer any questions also: there is a bug in `bun build --compile` I am currently working on fixing. Expect a v0.6.1 in a bit
1. It seems the Bun.file API ( https://bun.sh/docs/api/file-io ) doesn't provide a way to distinguish between a zero-size file and a file that doesn't exist. Is this right? If it is, it would be nice to have one. It doesn't have to interfere with the lazy loading. 2. Do you cross-compile Bun? If you do, how has your experience been cross-compiling with Zig when you have a C++ dependency?
> 1. It seems the Bun.file API (https://bun.sh/docs/api/file-io) doesn't provide a way to distinguish between a zero-size file and a file that doesn't exist. Is this right? If it is, it would be nice to have one. It doesn't have to interfere with the lazy loading.
Yes that is correct and not good. Pedantically, files which don't exist can be created between the call to check if it exists and after. In practice though, it is pretty annoying
> 2. Do you cross-compile Bun? If you do, how has your experience been cross-compiling with Zig when you have a C++ dependency?
We cross-compile the Zig part but not the C++ dependencies. zig c++ was too opinionated for us the last time we gave it a try. I'm optimistic this will improve in the future though.
Re: Bun 0.6
#155Earlier quoted context omitted.
Yeah but no one distributes hello world.
If the base line is 90MB, then it only goes up from there.
The question is "how fast". If bun executables are always 45x go's that's a problem. If they are always 98mb more than go's, then it's less of a problem as the size grows.
Re: Bun 0.6
#156Earlier quoted context omitted.
Not to mention, you can get better compression with some pre-compression levels that are hard to match with the best on the fly, often getting another 10% or more on size. It all adds up. There are some Steve Souders books on optimization that are pretty good and still pretty relevant.
If you minify, aren't you increasing the overall information entropy, and thereby decreasing the amount that can be gained from compression? I'm sure overall there's still a net gain but I wonder where the point of inflection is.
In my experience things kind of balance out, and you end up with negligible compression gains after compression. On the other hand, it also affects the time it takes for the browser / js engine to parse and execute the code, which can be significant in this world of massive bundles.
Re: Bun 0.6
#157Earlier quoted context omitted.
It bundles an entire JS engine with it. I think JSC in Bun's case. V8 for Deno and Node.
The engine is not the largest part of it. just-js, which is pretty close to barebones V8, sits at ~20MB. JSC is supposed to be about 4MB, Hermes is 2-3MB. The largest parts I think are ICU and the built-in libraries.
yes. author of just-js here. a minimal build of a v8 based runtime weighs in around 23-25 MB on modern linux using latest v8. this gets bigger all the time, due to new functionality being added to JS/V8 and no easy way to decide what parts of JS to include. when i started working on just-js ~3.5 years ago i'm pretty sure it was only 15MB or so - can verify when i have time.
Re: Bun 0.6
#158Earlier quoted context omitted.
“The generated file is 7.7MB, which is quite impressive for a Java application since this executable does need a JVM.” I assume this is a typo and they mean “does NOT”?
I think it isn't, and there saying it's impressive how small the JVM overhead is.
Is the JVM inside that 8MB then I guess? That is pretty great.
Originally I thought the alternative was “8MB but supply your own virtual machine.”
Re: Bun 0.6
#159Earlier quoted context omitted.
Bundling is totally different from linking and building for native platforms. Bundling is all about optimizing code to be sent over a small pipe--you're combining multiple compilation units into one file (so just one web request and lower latency) and doing optimizations like tree shaking to send only the code that's actually used. It's a pretty unique use-case that not many other programming languages deal with or c…
A native compiler also optimises the code. A native static linker also tries to omit unused library data and code. It's absolutely not the case that native devs don't care about code size (we do!) I guess Javascript uses a slightly unusual executable format, text instead of binary. Otherwise, it seems like very much the same thing?
I'd say that bundler design is less influenced by the format and more by the requirements of delivery over the web. Native code is not downloaded each time the user opens the application. Tons of web infrastructure and complexity is aimed at solving the problem of "user lands on page for the first time, it must be responsive as soon as possible."
Re: Bun 0.6
#160Earlier quoted context omitted.
You can statically link libc in Rust too; at least, if teh interwebz is correct (not a Rust expert); you just need some extra flags. This is actually not that different from Go in practice; many Go binaries are linked to libc: it happens as soon as you or a dependency imports the very commonly used "net" package unless you specifically set CGO_ENABLED=0, -tags=netgo, or use -extldflags=-static.
Statically linking libC is problematic in various ways. I really appreciate that Zig has its own runtime that is designed specifically for this use case.
> Statically linking libC is problematic in various ways.
Are we just talking about standard rop gadget vulnerabilities, or is there something else that's a problem with it?