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?
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.
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
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 great job of offloading work to the kernel when possible, too (i.e. the large file I/O improvement with the Linux kernel)
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.
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.)
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
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?
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.
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 ?
1. It seems the Bun.file API (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?
> 1. It seems the Bun.file API (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.
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.
Given that Oven has taken $7m in VC funding, how do you plan to monetize Bun, etc?