Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bun 0.6

bun.sh

Post reply on HN
Print view View original

101–110 of 243 posts

Re: Bun 0.6

#101

Post by haberman »

qbasic_forever wrote: post #61
tankenmate wrote: post #37

I am truly perplexed as someone outside of the Javascript ecosystem; why are there so many incompatible bundlers? If you look at most compiled languages they have a set ABI / executable image format, and you just use a link editor (either compile time, run time, or both). Is it just because most Javascript developers have never learnt from any of the lessons that came from decades of compiled languages? (compilers, c…

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…

> Linking native code doesn't really care about optimizing the size of the output and is just just trying to make sure all code paths can be called with some kind of code.

That is not true at all. There are many use cases where native code size is very important. Native code toolchains often target platforms with extremely limited ROM/RAM. Even on big machines, RAM is not free and cache even less so.

Native code linkers will GC unused code sections (`-Wl,--gc-sections `), fold identical data to remove duplication (see COMDAT). Native code compilers have optimization modes that specifically optimize for small code size (`-Os` and the like).

Re: Bun 0.6

#102

Post by paulddraper »

pier25 wrote: post #81
hu3 wrote: 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…

Apparently a hello world is like 90MB. https://twitter.com/jarredsumner/status/1657765876085690368

IIRC the latest Linux Node.js binary is over 70MB.

Though Bun doesn't use Node.js I believe, there's a reference

(At least it's not JVM Hotspot...)

Re: Bun 0.6

#103

Post by [deleted] »

qbasic_forever wrote: post #61
tankenmate wrote: post #37

I am truly perplexed as someone outside of the Javascript ecosystem; why are there so many incompatible bundlers? If you look at most compiled languages they have a set ABI / executable image format, and you just use a link editor (either compile time, run time, or both). Is it just because most Javascript developers have never learnt from any of the lessons that came from decades of compiled languages? (compilers, c…

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…

[deleted]

Re: Bun 0.6

#104

Post by tracker1 »

moron4hire wrote: post #53
tankenmate wrote: post #45

Earlier quoted context omitted.

But surely the people writing the browser code thought about the ecosystem they were creating / trying to create?

Browsers weren't written in a day. Technically speaking, Mozilla Firefox is a ship of Theseus going back to the release of Netscape in 1994. Did browser and internet infrastructure developers in the early 90s understand that these things would become rich application platforms? Looking at the history of HTTP, it's clear that they expected some concept of "application" to be delivered through the browser. While there'…

There were a lot of JS heavy web applications prior to Google Maps. From around the release of IE5 at the end of 2000 in particular through the long tenure of IE6. Having worked on some JS heavy applications around that time. It was also much harder as you had a relatively wide variety of browsers and versions. Since people on dialup were far less likely to update their browsers regularly (or at all beyond what came on an ISP or AOL CD.

Of course, the efforts for larger dev teams, optimizations and bundling were far less popular before then. Can't tell you how many poorly written sites/apps carried who knows how many versions/copies of JQuery for example. It was really bad for a while.

Now, at least there are more paying some attention to it. There's still some relatively large bundles that are easy to get overloaded. I mean as soon as you load any charting or graphing library it blows out everything else. Of course this is offset between bandwidth and compute advancements as well.

There was a popular developer site around 1998-2000 or so called 15seconds.com as that was the average point at which users would start dropping off from a load. Now that's measured at around a second or two.

Re: Bun 0.6

#105

Post by tracker1 »

doodlesdev wrote: post #5

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,…

I've been playing with static content generation with Deno+Lume and deploying to Cloudflare pages... crazy good loads.

Re: Bun 0.6

#106

Post by tracker1 »

dimgl wrote: post #55

I've been pretty jaded by Node.js lately, especially with all of the ESM and TypeScript stuff. This led me to try using Deno but Deno was missing the mark in a lot of ways. Is Bun in a state where I can start thinking about replacing my Node.js production toolchains with it?

I've been pretty happy with Deno... mostly in personal use... still some rough bits in terms of Node compatibility but pretty good in general.

Re: Bun 0.6

#107

Post by tracker1 »

10000truths wrote: post #80
dheera wrote: post #60

Why are we still minifying JavaScript? Is it only for obfuscation? State-of-the-art HTTP servers already do a pretty damn good job gzipping stuff on the fly, do we need this garbage? If it is for obfuscation, fine, can we just call it that?

You can shrink transmitted sizes even further by using minification on top of transport compression. That nets me ~25% reduction in size compared to compression without minification, in practice, and those kinds of gains add up, especially at the tail end of page load times.

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.

Re: Bun 0.6

#108

Post by ricardobeat »

matlin wrote: post #86
VWWHFSfQ wrote: post #85

Earlier quoted context omitted.

I'm curious why that would be so big. Even my python3.10 binary + /usr/lib/python3.10 is only 30MB

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.

Re: Bun 0.6

#109

Post by datavirtue »

pier25 wrote: post #81
hu3 wrote: 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…

Apparently a hello world is like 90MB. https://twitter.com/jarredsumner/status/1657765876085690368

That small!?

Re: Bun 0.6

#110

Post by d0100 »

winrid wrote: post #48
MuffinFlavored wrote: post #11

Earlier quoted context omitted.

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

Nah, rust still depends on libc at runtime which is a pain. Go doesn't have this problem afaik as it has its own stdlib and runtime.

Indeed, I built Supabase's edge-runtime and sent the binary to another pc with a earlier Ubuntu version only to discover it wont work

I went on a wild goose chase to build static Rust but deno can't target musl yet and the issue is a few years old

Post reply on HN