Live data from Hacker News

Bun 0.6

bun.sh

11–20 of 243 posts

Re: Bun 0.6

#11
post #6

> Standalone executables. You can now create standalone executables with bun build. > bun build --compile ./foo.ts > This lets you distribute your app as a single executable file, without requiring users to install Bun. > ./foo This is big! Part of Go's popularity is due to how easy it is to produce self-contained executables. And it seems to support amd64 and arm according too: https://twitter.com/jarredsumner/statu…

> Part of Go's popularity is due to how easy it is to produce self-contained executables.

Rust too... :D

Re: Bun 0.6

#12
post #6

> Standalone executables. You can now create standalone executables with bun build. > bun build --compile ./foo.ts > This lets you distribute your app as a single executable file, without requiring users to install Bun. > ./foo This is big! Part of Go's popularity is due to how easy it is to produce self-contained executables. And it seems to support amd64 and arm according too: https://twitter.com/jarredsumner/statu…

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.

You've been able to do this with Deno for a long time (and Node too, as of recently). The downside is it bundles all of V8 so a "hello world" binary ends up being at least 70mb.

Re: Bun 0.6

#13
post #4
post #2

I 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

Really impressed to see that bun is now faster than esbuild, that was in my mind one of the fastest bundler/minifier in town. How did you achieve that? Are there some shortcuts you took, or some feature you deemed not in scope (yet)?

I really hate to talk about software based on the language they're written in and I don't mean to imply one language is better or worse but the upper bound of performance on Zig is likely easier to reach and likely higher than the upper bound of performance in Go. Though it may depend on the workload. (esbuild being written in Go.)

Re: Bun 0.6

#14
post #6

> Standalone executables. You can now create standalone executables with bun build. > bun build --compile ./foo.ts > This lets you distribute your app as a single executable file, without requiring users to install Bun. > ./foo This is big! Part of Go's popularity is due to how easy it is to produce self-contained executables. And it seems to support amd64 and arm according too: https://twitter.com/jarredsumner/statu…

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 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.

Re: Bun 0.6

#15
post #7
post #2

I 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

Congrats on the release! How standalone are the standalone executables produced by `bun build`? Is a libc or equivalent expected to be present?

Bun does need glibc, but older glibc versions should work okay because of this: https://github.com/oven-sh/bun/blob/78229da76048e72aa4d92516...

We haven't implemented polyfills for everything yet though, like Bun uses posix_spawn and doesn't have an exec + fork fallback

Bun's dependencies otherwise are statically linked

Re: Bun 0.6

#16
post #6

> Standalone executables. You can now create standalone executables with bun build. > bun build --compile ./foo.ts > This lets you distribute your app as a single executable file, without requiring users to install Bun. > ./foo This is big! Part of Go's popularity is due to how easy it is to produce self-contained executables. And it seems to support amd64 and arm according too: https://twitter.com/jarredsumner/statu…

Doesn't Deno already let us do this?

Re: Bun 0.6

#17
post #4
post #2

I 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

Really impressed to see that bun is now faster than esbuild, that was in my mind one of the fastest bundler/minifier in town. How did you achieve that? Are there some shortcuts you took, or some feature you deemed not in scope (yet)?

This is a fantastic talk on some of the optimizations that Zig makes easy to implement: https://vimeo.com/649009599

Bun is written in Zig, but it takes the same approach that esbuild took to make things fast: a linear, synchronous pipeline fitting as much as possible in the CPU cache with as little allocation and other overhead as possible. Zig has more knobs to turn than Go.

Bun goes one step further and does a great job of offloading work to the kernel when possible, too (i.e. the large file I/O improvement with the Linux kernel)

Re: Bun 0.6

#18
post #2

I 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

Hello, it seems very interesting. I am using esbuild to build my apps and it has a developper live server. How would you compare bun to esbuild ? what can one do that the other can't ? do you have a compare page ?

Re: Bun 0.6

#19
import.meta.main (whether the current file is the 'main' or just being required) looks interesting and like something I have wanted in the past, but not sure if it would actually be a good idea.

was it ever offered for standardisation?

Re: Bun 0.6

#20

Tangential, but, this has to be one of the fastest websites I've used recently. How is it possible they get such fast loading of static content? It's basically instantaneous, specially with JavaScript disabled. edit: Oh well, after navigating to some pages on the blog I see that everything was already on browser cache, so that's why it was so fast. Reminds me I need to overwrite Netlify's cache-control on my website,…

Its use of the Cloudflare cache seems to be a part of it

Indeed, http headers indicate that the asset policy for the HTML is:

   cache-control: public, max-age=0, must-revalidate
A few things I notice:

   - It uses Cloudflare cache (as you pointed out).
   - All CSS is in the HTML file, so only one request is needed to display the page.
   - The compressed webpage is reasonably lean considering it has all CSS in the same file and uses Tailwind.
Post reply on HN