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

141–150 of 243 posts

Re: Bun 0.6

#141

Post by ijustlovemath »

tracker1 wrote: post #107
10000truths wrote: post #80

Earlier quoted context omitted.

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.

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.

Re: Bun 0.6

#142

Post by june_twenty »

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

Was Google Maps the first JS-heavy app? That's a TIL for me..

Re: Bun 0.6

#143

Post by stephc_int13 »

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

The storage part is not a big deal, it does not look nice but this is simply a bit disgusting.

The worrying part is that this is mostly code, not dead junk simply occupying space, this is part of the code path, filling the caches, or should I say trashing the caches…

Re: Bun 0.6

#145

Post by gavmor »

`bun` is currently my favorite "just works out of the box" utility for running Typescript programs.

I've tried a couple and struggled with configuration and, on top of it all, bun is simply faster.

So, if you want to write a bunch of `.ts` files and point something at them, I really recommend `bun` (and, frankly, why would you write `.js` in 2023? Probably because you've not tried bun.

Edit: I don't care about bundle sizes, because I'm just using bun to run my @benchristel/taste sub-second test suite.

Re: Bun 0.6

#146

Post by Buttons840 »

ojosilva wrote: post #128
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?

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.

Re: Bun 0.6

#147

Post by postalrat »

Jarred wrote: post #137
postalrat wrote: post #136

Earlier quoted context omitted.

I deployed a small non critical service with bun. So far constant (but slow) memory leaks and an 80% chance of segfault when starting up. Will try a few more versions of bun then move it to node for a while until bun matures a bit.

wow thats rough i'm sorry can you file an issue with some code that reproduces it? will take a look

It's all easily reproducible. I'll double check my code but its not too complex.

The service subscribes to redis messages, accepts websocket connections, authenticates the connections, then broadcasts messages through the websockets. Maybe around 1200 or so websocket connections per server.

Re: Bun 0.6

#148

Post by georgyo »

metaltyphoon wrote: post #134
pier25 wrote: post #119

Earlier quoted context omitted.

Depends. Doesn't seem much for a server but if you want to distribute an executable to your users then 90MB seems huge. IIRC a hello world Go binary is like 2MB.

Yeah but no one distributes hello world.

If the base line is 90MB, then it only goes up from there.

Re: Bun 0.6

#149

Post by carbotaniuman »

Waterluvian wrote: post #140
microflash wrote: post #138

Earlier quoted context omitted.

A native Java "Hello World" can be around 8MB in size.[1] So, yes, 90MB is too much. 1. https://sergiomartinrubio.com/articles/getting-started-with-...

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

Re: Bun 0.6

#150

Post by paulddraper »

U1F984 wrote: post #121
paulddraper wrote: post #102

Earlier quoted context omitted.

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

A Java Runtime for Hello world is just 32 MB: https://adoptium.net/blog/2021/10/jlink-to-produce-own-runti...

A full Java runtime is 95MB. (Smaller than the JDK size of 312MB.)

> The jlinked runtime using the above command is about 95Mb.

Simple programs -- like Hello World -- can indeed exclude certain parts of the JRE using jdeps, for a smaller size.

Post reply on HN