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

61–70 of 243 posts

Re: Bun 0.6

#61

Post by qbasic_forever »

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 care about. It's almost as if you are a demo scene coder trying to optimize for the absolute smallest code possible.

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.

Re: Bun 0.6

#62

Post by thewataccount »

winrid wrote: post #49
thewataccount wrote: post #36

Earlier quoted context omitted.

Have you tried using alpine based images instead of debian/ubuntu/others? I know it's not always possible especially because of musl but for most things it works fine and is tiny.

It becomes a political issue at this point w/ battling the ops team. I have more important battles.

Yeah that's fair, if it works it works.

Depending on your setup it doesn't really matter anyway.

Re: Bun 0.6

#63

Post by djbusby »

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?

And pack a bunch of assets into one larger asset, reduce the HTTP request count and maybe pre-gzip to save a few clock cycles

Re: Bun 0.6

#64

Post by dheera »

djbusby wrote: post #63
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?

And pack a bunch of assets into one larger asset, reduce the HTTP request count and maybe pre-gzip to save a few clock cycles

Maybe all of this should be an optional feature of HTTP servers and browsers with graceful fallback? NGINX could have a module that understands JavaScript and CSS and bundles and caches things on the fly, enabled optionally.

It would greatly simplify deployment to have the source and deployed code be identical. Obfuscation aside, given JS is an interpreted language, there is no reason to not use it for what it is. We've turned deploying JS into the same level of complexity as deploying C++ by adding building and packaging steps. Interpreted languages should never need build steps, and deployment should be no more than a simple rsync.

Re: Bun 0.6

#65

Post by HorizonXP »

Jarred wrote: 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

California Ave Lockitron crew represent!!

Glad to see you leading this, incredible work and nice to see the positive reception.

Re: Bun 0.6

#66

Post by latchkey »

silisili wrote: post #10
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…

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.

`-trimpath -s -w` makes binary size smaller.

`xz -z -9e` is good to compress it for distribution.

Re: Bun 0.6

#67

Post by hiccuphippo »

chrisco255 wrote: post #21
henry_viii wrote: post #16

Earlier quoted context omitted.

Doesn't Deno already let us do this?

Bun is intended to be a drop in replacement for Node.js, with Node.js compatible APIs. Deno chose to go a different route with the design of the runtime, encouraging more modern web-native paradigms.

Deno changed their opinion recently and will offer Node.js compatibility. Apparently it wasn't such a good idea to not be compatible on purpose.

Re: Bun 0.6

#68

Post by bdg »

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…

Is this like a phar file?

Re: Bun 0.6

#69

Post by raphaelrk »

Jarred wrote: 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 launch!!

Any plans on adding "in-memory" / "virtual" file support to Bun.build? I'd be interested in using it for notebook-style use cases

--

Also, ways to do "on-the-fly" "mixed client/server" components (ala hyperfiddle/electric) + sandboxing (ala Deno) would be extremely exciting

Some projects in this vein - https://github.com/jhmaster2000/bun-repl and https://www.val.town/

Also, bun macros are very cool -- they let you write code that writes over itself with GPT-4. Just mentioning as a thing to keep on your radar as you keep pushing the boundaries of what's possible in javascript :) making it more lispy and preserving eval-ability is great

Re: Bun 0.6

#70

Post by freddex »

Looks great! Still eagerly waiting for Windows support: I have a specific use case where I need both a bundler and a package manager to run on the user's desktop cross-platform, and right now that's yarn + esbuild. I'd love to roll this into a single, performant solution. It's already being worked on as far as I know [1], excited to upgrade to Bun when that's available.

[1] https://github.com/oven-sh/bun/issues/43

Post reply on HN