Live data from Hacker News

Bun 0.6

bun.sh

221–230 of 243 posts

Re: Bun 0.6

#221
post #14

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

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

Re: Bun 0.6

#222
post #180

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

I feel like using Graal for the comparison is cheating a bit because it's so fundamentally different from what bun is doing. You need to compare it to tools that ship class files and a JVM, or something like PyInstaller which will have much much more overhead.

PyInstaller actually seems to have less overhead, in terms of space, not "much much more". Building a hello world script with "pyinstaller --onefile" gives me a 5.6 MB executable on Linux or 4.9 MB on Windows.

Re: Bun 0.6

#224
post #168
post #145

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

> and, frankly, why would you write `.js` in 2023? It's surprisingly convenient for munging around random json files or calling random apis that return json (or for dealing with an interaction between the two), especially now that fetch ships with node.

JSON is great, for sure, and "calling random APIs" gets even better with type definition autocompletion!

Re: Bun 0.6

#225
post #145

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

Have you tried Deno yet? I've been using it for years now, without any config. It's fast, too.

No, but I should. It looks solid:

https://medium.com/deno-the-complete-reference/deno-vs-bun-p...

Re: Bun 0.6

#226
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?

Bundling and minimizing can very significantly reduce code size, by eliminating unused code.

This is beyond the stripping comments, whitespace, renaming all symbols to short identifiers, replacing idiomatic constructs with shorter equivalents, etc. that people expect minifiers to be doing.

Bundling with tree shaking can get rid of a lot of code that would otherwise need to be downloaded. This is especially the case when using only a subset of functionality from a larger library.

Otherwise, for most libraries, if you pull in a single function, every single module from that library will also get loaded. This applies both the pre-bundled libraries (i.e. where there is only one large module, so obviously everything gets downloaded), and non-bundled libraries, because most libraries have you import from an "index.(m)js" module, that exports all the various public API of the library. Which means a browser with import maps will need to download all those files, and all files they import, which will be basically every module in the library.

Minimizers themselves often also have some sophisticated dead code elimination. Indeed, one potential (but inefficient) way to implement tree shaking is simply to bundler without shaking, while using module concatenation, and then simply passing it to a minifier with good dead code elimination capabilities. This would be able to eliminate basically anything tree shaking could, and more. The more comes from both from any eliminable code the bundler would not know how to eliminate, but also being able to eliminate anything that was only imported by said dead code.

This is one of reasons why uncompressed minified code can sometimes beat out the compressed original code, and is still at least somewhat compressible itself. Of course I have not even touched on having fewer files to download (which still has meaningful overhead), nor the smaller resulting codebase being faster to parse than the.

Lastly, but not least, many people want to use typescript or jsx when writing their code, which means the code needs to be pre-processed before a JavaScript engine will read it. If you already have a compile step, then adding bundling and minimizing on top of that can be relatively simple and make good sense for the above reasons. (Note can be simple. It depends a lot on what tools you use. Webpack for example can get really complicated, but it also offers some really powerful features.)

Re: Bun 0.6

#227
post #217

Earlier quoted context omitted.

What's even "lighter" is a single binary sitting in /home/app running under "app" user and launched by systemd unit file with auto restart. Look, I totally get the unholy hell that's (for example) python dependency management, and containers are a great solve for that. Sometimes you don't have a choice of technology, so I get it. What I don't understand is folks that use containers for stuff like go binaries. Or node…

> I totally get the unholy hell that's (for example) python dependency management, and containers are a great solve for that. [...] What I don't understand is folks that use containers for stuff like [...] nodejs. I mean, it's just an "npm install". With Python it's just "venv/bin/pip install -r requirements.txt". All the tools needed to create an isolated environment (venv) and install packages (pip) come with the s…

Now wait two years, run the same command, and see what happens.

Re: Bun 0.6

#228
post #214
post #198

Earlier quoted context omitted.

It also misleading to think C doesn't have a runtime. https://learn.microsoft.com/en-us/cpp/c-runtime-library/c-ru... https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html https://software-dl.ti.com/codegen/docs/tiarmclang/compiler_... And many more, not feeling like linking documentation from all C compilers. In fact this is so relevant even for C, that ISO C has a special section for deployments without runtime support…

That's not at all comparable. From your link: "Most of the routines in libgcc handle arithmetic operations that the target processor cannot perform directly." You're trying to imply the Java native runtime is comparable to liggcc?? That's silly.

A runtime is a runtime, regardless of the size and features checkbook.

Re: Bun 0.6

#230
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?

Bundling and minimizing can very significantly reduce code size, by eliminating unused code. This is beyond the stripping comments, whitespace, renaming all symbols to short identifiers, replacing idiomatic constructs with shorter equivalents, etc. that people expect minifiers to be doing. Bundling with tree shaking can get rid of a lot of code that would otherwise need to be downloaded. This is especially the case w…

All your points are good, thanks, especially about the unused functions.

> many people want to use typescript or jsx when writing their code

However, if this is true, why don't we just add these languages to browsers (, ) with some kind of client-side processor for old browsers that turns them into "text/javascript" in-line in the DOM if the browser doesn't support it?

It's kind of weird that JavaScript is becoming a common "bytecode" among other better-structured languages, one would think the bytecode language that becomes the compilation target should be one that is better designed of its own.

If we're compiling JS, JSX, and TS all to some sort of assembly, or even a statically and strongly typed language like C++, I would feel a bit better.

Post reply on HN