81–90 of 243 posts
> 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…
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
Earlier quoted context omitted.
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 grea…
Zig is cool, but Bun heavily relies on JSC which is written in C++
> 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
> 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
Earlier quoted context omitted.
Apparently a hello world is like 90MB. https://twitter.com/jarredsumner/status/1657765876085690368
I'm curious why that would be so big. Even my python3.10 binary + /usr/lib/python3.10 is only 30MB
> 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…
Earlier quoted context omitted.
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
> Bun does need glibc Wait, are we talking about what Bun needs to run or what standalone executables produced by bun build need in order to run?
> 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?
Earlier quoted context omitted.
I've been desensitized by my world of 500mb docker containers.
Docker containers are actually smaller if they share layers with other containers in the system. A ton of containers based on the same image reaps many deduplication benefits.