18 ms·

Bun 0.6

421 points by tommasoamici 3y ago

Jarred 3y ago
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
- samwillis 3y ago
  > I work on Bun Understatement.
  - intelVISA 3y ago
    Local hacker seasons v8 Bun with io_urings; woulda been a cool proj if the Js runtime was organic like Bellard's qjs Still, in the native-starved web space this sorta meal will be considered haute cuisine.
- Signez 3y ago
  Really impressed to see that bun is now faster than esbuild, that was in my mind one of the fastest bundler/minifier in town. How did you achieve that? Are there some shortcuts you took, or some feature you deemed not in scope (yet)?
  - eatonphil 3y ago
    I really hate to talk about software based on the language they're written in and I don't mean to imply one language is better or worse but the upper bound of performance on Zig is likely easier to reach and likely higher than the upper bound of performance in Go. Though it may depend on the workload. (esbuild being written in Go.)
  - conradev 3y ago
    This is a fantastic talk on some of the optimizations that Zig makes easy to implement: https://vimeo.com/649009599 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 great job of offloading work to the kernel when possible, too (i.e. the large file I/O improvement with the Linux kernel)
    - f311a 3y ago
      Zig is cool, but Bun heavily relies on JSC which is written in C++
      - brundolf 3y ago
        But bundling doesn't
      - conradev 3y ago
        JSC is a multi-tier JIT with the last stage ultimately being LLVM, so if you want to be pedantic, Bun relies on LLVM’s optimizer which is written in C++. The transpiling itself is written in Zig, which is the part that has the performance improvement. If Bun relied on JavaScript and JSC for the heavy lifting, it would be no faster than the other JS bundlers. edit: no longer LLVM: https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ https://webkit.org/blog/5852/introducing-the-b3-jit-compiler...
- kitd 3y ago
  Congrats on the release! How standalone are the standalone executables produced by `bun build`? Is a libc or equivalent expected to be present?
  - Jarred 3y ago
    Bun does need glibc, but older glibc versions should work okay because of this: https://github.com/oven-sh/bun/blob/78229da76048e72aa4d92516e296a57484450a30/src/bun.js/bindings/workaround-missing-symbols.cpp#L27 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
    - codethief 3y ago
      > 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?
      - hiccuphippo 3y ago
        Both, the executables produced by bun are the bun binary concatenated to your script at the end. Try building a hello world and run `tail -c200 hello | xxd` to see your script at the end of the file.
        codethief 3y ago
        Thanks!
    - 10000truths 3y ago
      Is there any plan to allow for statically linking with musl to get completely shared-lib-dependency-free executables?
- tazeg95 3y ago
  Hello, it seems very interesting. I am using esbuild to build my apps and it has a developper live server. How would you compare bun to esbuild ? what can one do that the other can't ? do you have a compare page ?
- meekaaku 3y ago
  Just wanted to say thank you for starting and leading the one of the most exciting projects in js landscape.
- drschwabe 3y ago
  Not a question, cause you already mention this here, but just wanted to give you extra props for supporting CommonJS out of the box; keep up the great work. https://twitter.com/jarredsumner/status/1475238259127058433?lang=en https://twitter.com/jarredsumner/status/1475238259127058433?... have been doing this (using ES and CommonJS modules in the same file) in clientside code via Browserify or Rollup ever since ESM got popular but it's a bit more nuanced and annoying to do in NodeJS
- alberth 3y ago
  Revenue/monetization model? Given that Oven has taken $7m in VC funding, how do you plan to monetize Bun, etc?
  - whimsicalism 3y ago
    my understanding was an edge environment similar to CF workers
  - Jarred 3y ago
    The plan is JavaScript edge hosting focused on fast cold starts and being extremely inexpensive, using lots of custom infrastructure
    - internetter 3y ago
      Hi Jarred. Super excited to see bun coming along. I've been loving it ever since the invitation release. As I watch from the sidelines, I've been mesmerized by your productivity. I have a couple questions, if you don't mind. The first – I'm curious about Vite in bun. You have a bundler, you have a typescript transpiler, and you have a HTTP server. Does this mean eventually Vite (or at least some of it's functionality) will be "native" inside of bun, or will Vite continue to be it's own thing? (eg. Vite plugins for <framework>) The second is more related to Oven. I'm curious what the value proposition of Oven's edge is, compared to other serverless providers? It's hard to imagine the runtime being the main selling point, with it's node compatibility and packages like hono being able to run everywhere. What will set Oven's edge hosting apart from the pack?
    - icemelt8 3y ago
      This reply is news itself. Nice!
- pastacacioepepe 3y ago
  Is Windows support planned?
- yobuko 3y ago
  First, thank you for all of your hard efforts. I have seen some desire and works expressed towards using Bun with Electron or Electron alternatives; this interests me greatly. Do you have any plans or aspirations to make any strong push in this direction?
  - sroussey 3y ago
    This would be awesome. Use bun as the main process (replacing node) and have the front end use the system webview. The system webviews are good these days.
- HorizonXP 3y ago
  California Ave Lockitron crew represent!! Glad to see you leading this, incredible work and nice to see the positive reception.
  - zamnos 3y ago
    In Palo Alto by the Nuthouse? small Internet
    - HorizonXP 3y ago
      That’s the one
- raphaelrk 3y ago
  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 https://github.com/jhmaster2000/bun-repl and https://www.val.town/ 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
- sroussey 3y ago
  Bun is awesome! Need debug support and console fixes. Please!!!
- networked 3y ago
  1. It seems the Bun.file API (https://bun.sh/docs/api/file-io https://bun.sh/docs/api/file-io) doesn't provide a way to distinguish between a zero-size file and a file that doesn't exist. Is this right? If it is, it would be nice to have one. It doesn't have to interfere with the lazy loading. 2. Do you cross-compile Bun? If you do, how has your experience been cross-compiling with Zig when you have a C++ dependency?
  - Jarred 3y ago
    > 1. It seems the Bun.file API (https://bun.sh/docs/api/file-io https://bun.sh/docs/api/file-io) doesn't provide a way to distinguish between a zero-size file and a file that doesn't exist. Is this right? If it is, it would be nice to have one. It doesn't have to interfere with the lazy loading. Yes that is correct and not good. Pedantically, files which don't exist can be created between the call to check if it exists and after. In practice though, it is pretty annoying > 2. Do you cross-compile Bun? If you do, how has your experience been cross-compiling with Zig when you have a C++ dependency? We cross-compile the Zig part but not the C++ dependencies. zig c++ was too opinionated for us the last time we gave it a try. I'm optimistic this will improve in the future though.
- toastal 3y ago
  When will Bun open up communications to something open source/decentralized instead of relying on users to give up their online security to Discord?
doodlesdev 3y ago
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, even though it's already very fast to load (Netlify sets max-age=0, must-revalidate by default).
- Minor49er 3y ago
  Its use of the Cloudflare cache seems to be a part of it
  - doodlesdev 3y ago
    Indeed, http headers indicate that the asset policy for the HTML is: cache-control: public, max-age=0, must-revalidate A few things I notice: - It uses Cloudflare cache (as you pointed out). - All CSS is in the HTML file, so only one request is needed to display the page. - The compressed webpage is reasonably lean considering it has all CSS in the same file and uses Tailwind.
- ignoramous 3y ago
  From experience, static websites on https://pages.dev https://pages.dev are blazing fast (and free); ex: pagespeed result for a static webpage I host: https://archive.is/PkZbO https://archive.is/PkZbO Netifly was equally fast (not free).
  - doodlesdev 3y ago
    Cloudflare is indeed absurdly fast. I haven't been impressed with Netlify's speed, although I am using the free plan (don't think it makes sense to upgrade if I'm already not super happy with performance). When you say paid Netlify is as fast as Cloudflare do you mean the Pro plan or the Enterprise plan? AFAIK the enterprise plans run on a different network, with more distributed servers, although I could be wrong. It seems at least part of the noticed difference in speed has to do with my region, as pagespeed insights gives me sub-second FCP and LCP on my Netlify website [0], which feels a bit better than what I get at home (with 500mbps fiber). It's possible my ISP is at fault, but I'm not sure how I could diagnose this much better. [0]: https://archive.ph/IF0t5 https://archive.ph/IF0t5
hu3 3y ago
> 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/status/1657964313888575489 https://twitter.com/jarredsumner/status/1657964313888575489
- silisili 3y ago
  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.
  - TechBro8615 3y ago
    You've been able to do this with Deno for a long time (and Node too, as of recently). The downside is it bundles all of V8 so a "hello world" binary ends up being at least 70mb.
    - winrid 3y ago
      I've been desensitized by my world of 500mb docker containers.
      - nine_k 3y ago
        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.
        tracker1 3y ago
        Yeah, I notice many/most images are based on a recent Debian base if they aren't on Alpine or closer to bare images. I don't consider even Alpine as a base too bad for a lot of apps.
timetraveller26 3y ago
How does this compare to bite?
unilynx 3y ago
import.meta.main (whether the current file is the 'main' or just being required) looks interesting and like something I have wanted in the past, but not sure if it would actually be a good idea. was it ever offered for standardisation?
- Jarred 3y ago
  There is no standard, import.meta is host-defined: 13.3.12.1.1 HostGetImportMetaProperties ( moduleRecord ) The host-defined abstract operation HostGetImportMetaProperties takes argument moduleRecord (a Module Record) and returns a List of Records with fields [[Key]] (a property key) and [[Value]] (an ECMAScript language value). It allows hosts to provide property keys and values for the object returned from import.meta. https://tc39.es/ecma262/#sec-hostgetimportmetaproperties https://tc39.es/ecma262/#sec-hostgetimportmetaproperties
brundolf 3y ago
Anybody using Bun in production yet? What's your experience been like?
- postalrat 3y ago
  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.
  - Jarred 3y ago
    wow thats rough i'm sorry can you file an issue with some code that reproduces it? will take a look
    - postalrat 3y ago
      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.
    - postalrat 3y ago
      I did upgrade to bun 0.6.1. Haven't seen the segvault on startup yet but still seeing the memory leak. Maybe even slightly faster than before. Will check my code to see if it could be causing the issue.
      - opengears 3y ago
        Can you point us to the code so we can figure out where the memory leak originates from?
schemescape 3y ago
How big are the bundles (edit: I meant self-contained executables) and do they depend on glibc? Edit: just saw a comment from the author indicating glibc is required.
- lionkor 3y ago
  Doing it without glibc is not practical
  - AndyKelley 3y ago
    why?
    - lionkor 3y ago
      Because otherwise you need to implement almost everything yourself - memory allocation, input, output, etc. and anything more complex (like asking for the width of the terminal) requires you to get into Kernel structs, copy them out, translate, and basically copy paste glibc code anyways. And thats just linux.
      - bruce_one 3y ago
        There are alternative C libraries that are worth considering, e.g. Zig (which is what Bun itself is written in, afaiu) supports using [musl](https://musl.libc.org https://musl.libc.org) as an alternative to glibc, and musl can be statically linked as well (by contrast to the glibc quasi-static-linking).
  - silverwind 3y ago
    It's just DNS isn't it? Many apps don't even need DNS, so there should at least be an option to build fully static binaries.
tankenmate 3y ago
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, compiler tools, operating system and kernel development, etc). Is there some benefit that Javascript bundlers have that I'm unaware of? Truly curious.
- ponyous 3y ago
  Because there were browsers and no standards. How can you expect someone that starts coding on the web to know what pains kernel went through decades prior?
  - tankenmate 3y ago
    But surely the people writing the browser code thought about the ecosystem they were creating / trying to create?
    - moron4hire 3y ago
      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's certainly a chance at least a few of them foresaw the full scope of what that would mean (it's not like X11 remoting wasn't a thing), I don't think most of the people involved were thinking much past 10 years (The Distant Future, the Year 2000). JavaScript was apocryphally "invented in 10 days", it came as an attempt to create competitive advantage, not to create a global standard. The first JavaScript came a year (1995) after the first Netscape, but the first major JS-heavy application didn't come for another 13 years (Google Maps, 2008).
deleted 3y ago
[deleted]
dimgl 3y ago
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?
- tracker1 3y ago
  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.
- ojosilva 3y ago
  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 knobs • NPM and Bun/Deno are not real friends at the moment, just acquaintances • Take benchmarks with a pinch of salt. Real-world app performance depends on a well-greased system, not a particular 60,000 req/s react render benchmark. Remember the adage: your app will as fast as your slowest component. On a side note, lately I've been extending Node.js with Rust + N-API (ie. napi-rs or neon) and it opens up excellent possibilities. https://napi.rs/ https://napi.rs/ https://neon-bindings.com/ https://neon-bindings.com/
  - Buttons840 3y ago
    Bun might be a cool project, but them building on an immature language like Zig makes me wonder where their priorities are.
    - ricardobeat 3y ago
      It wouldn't exist any other way, the story is that it was built with speed as a priority, and Zig was chosen for the performance optimizations it enables.
dheera 3y ago
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?
- djbusby 3y ago
  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
  - dheera 3y ago
    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.
  - LispSporks22 3y ago
    I thought I read in the Rails docs somewhere that HTTP2 and import maps rescued us from bundling JS
- 10000truths 3y ago
  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.
  - tracker1 3y ago
    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.
freddex 3y ago
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 https://github.com/oven-sh/bun/issues/43
fluente 3y ago
It would be helpful to see how Bun's minifier compares to the others with popular libraries: https://github.com/privatenumber/minification-benchmarks https://github.com/privatenumber/minification-benchmarks
ShadowBanThis01 3y ago
Is WHAT? The title should tell us what the post is about. Why do we have to keep bringing this up? A title like this is a great way to miss out on a lot of views and reduce the usefulness of your post. Let the downvoting of this simple observation begin.
- deleted 3y ago
  [deleted]
captainmarble 3y ago
Any plan on adding something likr Deno KV in Bun?
deleted 3y ago
[deleted]
0x445442 3y ago
> Lots of bug fixes to Node.js Does Node.js have lots of bugs still?
- hiccuphippo 3y ago
  > lots of bug fixes to Node.js compatibility
- willmorrison 3y ago
  They prpbably mean their node.js compatibility.
gavmor 3y ago
`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.
- Kamq 3y ago
  > 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.
  - gavmor 3y ago
    JSON is great, for sure, and "calling random APIs" gets even better with type definition autocompletion!
    - Kamq 3y ago
      If you make me start statically typing the random scripts I write to munge data round to answer business questions, I quit.
      - gavmor 3y ago
        Fair enough.
- mark_and_sweep 3y ago
  Have you tried Deno yet? I've been using it for years now, without any config. It's fast, too.
  - gavmor 3y ago
Aeolun 3y ago
Does it work with Prisma yet? I’m kinda waitjng for that to switch everything over.
vaughan 3y ago
We need an equivalent Python Mojo for TypeScript. This seems like the most obvious thing yet to be built. I wonder how hard it would be to take an existing systems language and add TS syntax to it. Seeing as they are all built on LLVM. Or maybe you could transpile TS to Zig.
19h 3y ago
Funny to see improvements in crypto.createHash… I was totally caught off guard yesterday noticing most of crypto has been removed in Node 20 and replaced with the exclusively-async „subtle“ WebCrypto. Quite a pain to work with when you need synchronous code.

421 points by tommasoamici 3y ago

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

samwillis 3y ago
> I work on Bun Understatement.
- intelVISA 3y ago
  Local hacker seasons v8 Bun with io_urings; woulda been a cool proj if the Js runtime was organic like Bellard's qjs Still, in the native-starved web space this sorta meal will be considered haute cuisine.
Signez 3y ago
Really impressed to see that bun is now faster than esbuild, that was in my mind one of the fastest bundler/minifier in town. How did you achieve that? Are there some shortcuts you took, or some feature you deemed not in scope (yet)?
- eatonphil 3y ago
  I really hate to talk about software based on the language they're written in and I don't mean to imply one language is better or worse but the upper bound of performance on Zig is likely easier to reach and likely higher than the upper bound of performance in Go. Though it may depend on the workload. (esbuild being written in Go.)
- conradev 3y ago
  This is a fantastic talk on some of the optimizations that Zig makes easy to implement: https://vimeo.com/649009599 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 great job of offloading work to the kernel when possible, too (i.e. the large file I/O improvement with the Linux kernel)
  - f311a 3y ago
    Zig is cool, but Bun heavily relies on JSC which is written in C++
    - brundolf 3y ago
      But bundling doesn't
    - conradev 3y ago
      JSC is a multi-tier JIT with the last stage ultimately being LLVM, so if you want to be pedantic, Bun relies on LLVM’s optimizer which is written in C++. The transpiling itself is written in Zig, which is the part that has the performance improvement. If Bun relied on JavaScript and JSC for the heavy lifting, it would be no faster than the other JS bundlers. edit: no longer LLVM: https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ https://webkit.org/blog/5852/introducing-the-b3-jit-compiler...
kitd 3y ago
Congrats on the release! How standalone are the standalone executables produced by `bun build`? Is a libc or equivalent expected to be present?
- Jarred 3y ago
  Bun does need glibc, but older glibc versions should work okay because of this: https://github.com/oven-sh/bun/blob/78229da76048e72aa4d92516e296a57484450a30/src/bun.js/bindings/workaround-missing-symbols.cpp#L27 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
  - codethief 3y ago
    > 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?
    - hiccuphippo 3y ago
      Both, the executables produced by bun are the bun binary concatenated to your script at the end. Try building a hello world and run `tail -c200 hello | xxd` to see your script at the end of the file.
      - codethief 3y ago
        Thanks!
  - 10000truths 3y ago
    Is there any plan to allow for statically linking with musl to get completely shared-lib-dependency-free executables?
tazeg95 3y ago
Hello, it seems very interesting. I am using esbuild to build my apps and it has a developper live server. How would you compare bun to esbuild ? what can one do that the other can't ? do you have a compare page ?
meekaaku 3y ago
Just wanted to say thank you for starting and leading the one of the most exciting projects in js landscape.
drschwabe 3y ago
Not a question, cause you already mention this here, but just wanted to give you extra props for supporting CommonJS out of the box; keep up the great work. https://twitter.com/jarredsumner/status/1475238259127058433?lang=en https://twitter.com/jarredsumner/status/1475238259127058433?... have been doing this (using ES and CommonJS modules in the same file) in clientside code via Browserify or Rollup ever since ESM got popular but it's a bit more nuanced and annoying to do in NodeJS
alberth 3y ago
Revenue/monetization model? Given that Oven has taken $7m in VC funding, how do you plan to monetize Bun, etc?
- whimsicalism 3y ago
  my understanding was an edge environment similar to CF workers
- Jarred 3y ago
  The plan is JavaScript edge hosting focused on fast cold starts and being extremely inexpensive, using lots of custom infrastructure
  - internetter 3y ago
    Hi Jarred. Super excited to see bun coming along. I've been loving it ever since the invitation release. As I watch from the sidelines, I've been mesmerized by your productivity. I have a couple questions, if you don't mind. The first – I'm curious about Vite in bun. You have a bundler, you have a typescript transpiler, and you have a HTTP server. Does this mean eventually Vite (or at least some of it's functionality) will be "native" inside of bun, or will Vite continue to be it's own thing? (eg. Vite plugins for <framework>) The second is more related to Oven. I'm curious what the value proposition of Oven's edge is, compared to other serverless providers? It's hard to imagine the runtime being the main selling point, with it's node compatibility and packages like hono being able to run everywhere. What will set Oven's edge hosting apart from the pack?
  - icemelt8 3y ago
    This reply is news itself. Nice!
pastacacioepepe 3y ago
Is Windows support planned?
yobuko 3y ago
First, thank you for all of your hard efforts. I have seen some desire and works expressed towards using Bun with Electron or Electron alternatives; this interests me greatly. Do you have any plans or aspirations to make any strong push in this direction?
- sroussey 3y ago
  This would be awesome. Use bun as the main process (replacing node) and have the front end use the system webview. The system webviews are good these days.
HorizonXP 3y ago
California Ave Lockitron crew represent!! Glad to see you leading this, incredible work and nice to see the positive reception.
- zamnos 3y ago
  In Palo Alto by the Nuthouse? small Internet
  - HorizonXP 3y ago
    That’s the one
raphaelrk 3y ago
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 https://github.com/jhmaster2000/bun-repl and https://www.val.town/ 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
sroussey 3y ago
Bun is awesome! Need debug support and console fixes. Please!!!
networked 3y ago
1. It seems the Bun.file API (https://bun.sh/docs/api/file-io https://bun.sh/docs/api/file-io) doesn't provide a way to distinguish between a zero-size file and a file that doesn't exist. Is this right? If it is, it would be nice to have one. It doesn't have to interfere with the lazy loading. 2. Do you cross-compile Bun? If you do, how has your experience been cross-compiling with Zig when you have a C++ dependency?
- Jarred 3y ago
  > 1. It seems the Bun.file API (https://bun.sh/docs/api/file-io https://bun.sh/docs/api/file-io) doesn't provide a way to distinguish between a zero-size file and a file that doesn't exist. Is this right? If it is, it would be nice to have one. It doesn't have to interfere with the lazy loading. Yes that is correct and not good. Pedantically, files which don't exist can be created between the call to check if it exists and after. In practice though, it is pretty annoying > 2. Do you cross-compile Bun? If you do, how has your experience been cross-compiling with Zig when you have a C++ dependency? We cross-compile the Zig part but not the C++ dependencies. zig c++ was too opinionated for us the last time we gave it a try. I'm optimistic this will improve in the future though.
toastal 3y ago
When will Bun open up communications to something open source/decentralized instead of relying on users to give up their online security to Discord?

doodlesdev 3y ago

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, even though it's already very fast to load (Netlify sets max-age=0, must-revalidate by default).

Minor49er 3y ago
Its use of the Cloudflare cache seems to be a part of it
- doodlesdev 3y ago
  Indeed, http headers indicate that the asset policy for the HTML is: cache-control: public, max-age=0, must-revalidate A few things I notice: - It uses Cloudflare cache (as you pointed out). - All CSS is in the HTML file, so only one request is needed to display the page. - The compressed webpage is reasonably lean considering it has all CSS in the same file and uses Tailwind.
ignoramous 3y ago
From experience, static websites on https://pages.dev https://pages.dev are blazing fast (and free); ex: pagespeed result for a static webpage I host: https://archive.is/PkZbO https://archive.is/PkZbO Netifly was equally fast (not free).
- doodlesdev 3y ago
  Cloudflare is indeed absurdly fast. I haven't been impressed with Netlify's speed, although I am using the free plan (don't think it makes sense to upgrade if I'm already not super happy with performance). When you say paid Netlify is as fast as Cloudflare do you mean the Pro plan or the Enterprise plan? AFAIK the enterprise plans run on a different network, with more distributed servers, although I could be wrong. It seems at least part of the noticed difference in speed has to do with my region, as pagespeed insights gives me sub-second FCP and LCP on my Netlify website [0], which feels a bit better than what I get at home (with 500mbps fiber). It's possible my ISP is at fault, but I'm not sure how I could diagnose this much better. [0]: https://archive.ph/IF0t5 https://archive.ph/IF0t5

hu3 3y ago

> 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/status/1657964313888575489 https://twitter.com/jarredsumner/status/1657964313888575489

silisili 3y ago
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.
- TechBro8615 3y ago
  You've been able to do this with Deno for a long time (and Node too, as of recently). The downside is it bundles all of V8 so a "hello world" binary ends up being at least 70mb.
  - winrid 3y ago
    I've been desensitized by my world of 500mb docker containers.
    - nine_k 3y ago
      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.
      - tracker1 3y ago
        Yeah, I notice many/most images are based on a recent Debian base if they aren't on Alpine or closer to bare images. I don't consider even Alpine as a base too bad for a lot of apps.

timetraveller26 3y ago

How does this compare to bite?

unilynx 3y ago

import.meta.main (whether the current file is the 'main' or just being required) looks interesting and like something I have wanted in the past, but not sure if it would actually be a good idea. was it ever offered for standardisation?

Jarred 3y ago
There is no standard, import.meta is host-defined: 13.3.12.1.1 HostGetImportMetaProperties ( moduleRecord ) The host-defined abstract operation HostGetImportMetaProperties takes argument moduleRecord (a Module Record) and returns a List of Records with fields [[Key]] (a property key) and [[Value]] (an ECMAScript language value). It allows hosts to provide property keys and values for the object returned from import.meta. https://tc39.es/ecma262/#sec-hostgetimportmetaproperties https://tc39.es/ecma262/#sec-hostgetimportmetaproperties

brundolf 3y ago

Anybody using Bun in production yet? What's your experience been like?

postalrat 3y ago
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.
- Jarred 3y ago
  wow thats rough i'm sorry can you file an issue with some code that reproduces it? will take a look
  - postalrat 3y ago
    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.
  - postalrat 3y ago
    I did upgrade to bun 0.6.1. Haven't seen the segvault on startup yet but still seeing the memory leak. Maybe even slightly faster than before. Will check my code to see if it could be causing the issue.
    - opengears 3y ago
      Can you point us to the code so we can figure out where the memory leak originates from?

schemescape 3y ago

How big are the bundles (edit: I meant self-contained executables) and do they depend on glibc? Edit: just saw a comment from the author indicating glibc is required.

lionkor 3y ago
Doing it without glibc is not practical
- AndyKelley 3y ago
  why?
  - lionkor 3y ago
    Because otherwise you need to implement almost everything yourself - memory allocation, input, output, etc. and anything more complex (like asking for the width of the terminal) requires you to get into Kernel structs, copy them out, translate, and basically copy paste glibc code anyways. And thats just linux.
    - bruce_one 3y ago
      There are alternative C libraries that are worth considering, e.g. Zig (which is what Bun itself is written in, afaiu) supports using [musl](https://musl.libc.org https://musl.libc.org) as an alternative to glibc, and musl can be statically linked as well (by contrast to the glibc quasi-static-linking).
- silverwind 3y ago
  It's just DNS isn't it? Many apps don't even need DNS, so there should at least be an option to build fully static binaries.

tankenmate 3y ago

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, compiler tools, operating system and kernel development, etc). Is there some benefit that Javascript bundlers have that I'm unaware of? Truly curious.

ponyous 3y ago
Because there were browsers and no standards. How can you expect someone that starts coding on the web to know what pains kernel went through decades prior?
- tankenmate 3y ago
  But surely the people writing the browser code thought about the ecosystem they were creating / trying to create?
  - moron4hire 3y ago
    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's certainly a chance at least a few of them foresaw the full scope of what that would mean (it's not like X11 remoting wasn't a thing), I don't think most of the people involved were thinking much past 10 years (The Distant Future, the Year 2000). JavaScript was apocryphally "invented in 10 days", it came as an attempt to create competitive advantage, not to create a global standard. The first JavaScript came a year (1995) after the first Netscape, but the first major JS-heavy application didn't come for another 13 years (Google Maps, 2008).

deleted 3y ago

[deleted]

dimgl 3y ago

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?

tracker1 3y ago
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.
ojosilva 3y ago
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 knobs • NPM and Bun/Deno are not real friends at the moment, just acquaintances • Take benchmarks with a pinch of salt. Real-world app performance depends on a well-greased system, not a particular 60,000 req/s react render benchmark. Remember the adage: your app will as fast as your slowest component. On a side note, lately I've been extending Node.js with Rust + N-API (ie. napi-rs or neon) and it opens up excellent possibilities. https://napi.rs/ https://napi.rs/ https://neon-bindings.com/ https://neon-bindings.com/
- Buttons840 3y ago
  Bun might be a cool project, but them building on an immature language like Zig makes me wonder where their priorities are.
  - ricardobeat 3y ago
    It wouldn't exist any other way, the story is that it was built with speed as a priority, and Zig was chosen for the performance optimizations it enables.

dheera 3y ago

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?

djbusby 3y ago
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
- dheera 3y ago
  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.
- LispSporks22 3y ago
  I thought I read in the Rails docs somewhere that HTTP2 and import maps rescued us from bundling JS
10000truths 3y ago
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.
- tracker1 3y ago
  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.

freddex 3y ago

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 https://github.com/oven-sh/bun/issues/43

fluente 3y ago

It would be helpful to see how Bun's minifier compares to the others with popular libraries: https://github.com/privatenumber/minification-benchmarks https://github.com/privatenumber/minification-benchmarks

ShadowBanThis01 3y ago

Is WHAT? The title should tell us what the post is about. Why do we have to keep bringing this up? A title like this is a great way to miss out on a lot of views and reduce the usefulness of your post. Let the downvoting of this simple observation begin.

deleted 3y ago
[deleted]

captainmarble 3y ago

Any plan on adding something likr Deno KV in Bun?

deleted 3y ago

[deleted]

0x445442 3y ago

> Lots of bug fixes to Node.js Does Node.js have lots of bugs still?

hiccuphippo 3y ago
> lots of bug fixes to Node.js compatibility
willmorrison 3y ago
They prpbably mean their node.js compatibility.

gavmor 3y ago

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

Kamq 3y ago
> 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.
- gavmor 3y ago
  JSON is great, for sure, and "calling random APIs" gets even better with type definition autocompletion!
  - Kamq 3y ago
    If you make me start statically typing the random scripts I write to munge data round to answer business questions, I quit.
    - gavmor 3y ago
      Fair enough.
mark_and_sweep 3y ago
Have you tried Deno yet? I've been using it for years now, without any config. It's fast, too.
- gavmor 3y ago

Aeolun 3y ago

Does it work with Prisma yet? I’m kinda waitjng for that to switch everything over.

vaughan 3y ago

We need an equivalent Python Mojo for TypeScript. This seems like the most obvious thing yet to be built. I wonder how hard it would be to take an existing systems language and add TS syntax to it. Seeing as they are all built on LLVM. Or maybe you could transpile TS to Zig.

19h 3y ago

Funny to see improvements in crypto.createHash… I was totally caught off guard yesterday noticing most of crypto has been removed in Node 20 and replaced with the exclusively-async „subtle“ WebCrypto. Quite a pain to work with when you need synchronous code.