Ben: Hello, and welcome to PodRocket. Today, I'm here with Jarred Sumner, who is the creator of Bun. Seeing a lot of talk of Bun in the Twitter sphere. It's a new JavaScript Runtime, similar or a new version of Node or Demo. So really excited to learn about it. How are you doing today otherwise, Jarred? Jarred Sumner: Pretty good. Ben: And so before we kind get into talking about Bun, curious to learn a bit about your background and your journey and what led you to go out there and create a new JavaScript Runtime. Jarred Sumner: Yeah. Before Bun, I was building a game and it was a really big multiplayer voxel game in the browser. And I just kept running into... The game got to be pretty large as a code base and it just got really slow to build. It was a front end, it was written in JavaScript. And so I started to work a lot on the build tools for the game to try to make it build faster and try to improve the iteration cycle time. But eventually I found myself just spending more time on the iteration cycle time in the build tools than the actual game. So then I was like, "Well, okay, what if I just do that instead?" Ben: Got it. And so I guess Bun was born. Yeah, what is Bun? How is it different than Node, which most people are familiar with? Jarred Sumner: So Bun is an all in one JavaScript Runtime. It combines a Bundler, a transpiler, a package manager, a script runner, all in one in addition to being a Runtime. And so it comes with a TypeScript transpiler, JSX transpiler. And all of this is quite a bit faster than anything that exists today. Ben: Got it. And just for folks who maybe aren't as familiar with the intimate details of the modern JavaScript stack, each of those pieces, Bundler, transpiler, package manager, script runner, if you're working with Node, those are each a separate tool. So Bundler people would use web pack or one of those. Is Dabble the most popular one or what? Jarred Sumner: Yeah, probably. Ben: Yeah, probably Dabble package manager, like Yarn or NPM. So have you rebuilt each of those pieces of infrastructure all in one platform or do you- Jarred Sumner: Exactly. Ben: Wow. So you really- Jarred Sumner: It's rebuilt. Ben: And is everything built from scratch? Jarred Sumner: Pretty much. Ben: Wow. So a lot of infrastructure to build there, I guess maybe take me through each part of that stack and talk about some of the ways where Bun is different or improves upon the standard tools everyone uses with Node. Jarred Sumner: Yeah. So Bun install, which is the NPM package manager, on Linux it installs about 20 times to a hundred times faster than NPM. Specifically when you're dealing with cache installs, which is the common case where you've already installed most of the packages once and you're installing it again because you cleaned out your node modules folder or maybe there was some updates since the last time you did git pull. And so that's faster because mostly due to system call overhead is really, really low. With Bun, just a lot of work went into making that really fast. And also because Bun is written in Zig mostly, and Zig is really good for this type of systems programming to do it as quickly as possible while also not going crazy because it's a low level systems' language with manual memory management. By its nature, without garbage collection, things are a little bit harder, but Zig does a really good job of making it easier than it would be otherwise in C. Ben: Got it. So Zig, I'm actually not super familiar with that language. Is it relatively new or it's been around, just not as popular or? Jarred Sumner: Yeah. So Zig is a pretty new programming language. The easiest one to compare to is public Rust. They're both systems languages. Zig is really focused on C compatibility and being really fast and giving you really tight control over everything that's going on. It's really easy, in other probing languages, for there to be like lots of hidden behavior. When you call a function, it might call another function at the end of the scope. Zig doesn't have any of that. Zig has a philosophy of no hidden control flow, which means you pretty much know everything that's going on, which is really good for performance because it's very easy to... that's a lot of what makes software slow is that you're doing a bunch of work, you don't even realize you're doing that work and it's unnecessary. Ben: Got it. So you chose Zig. Is that the primary innovation that lets Bun be so much faster, or what else goes into the fact that Bun is so much faster than the existing tools? Jarred Sumner: Honestly, Zig is a big part of it, but I would say the biggest thing is just a lot of time spent profiling. Just looking at what is... all of these things started slow. Especially the transpiler. So the very first versions of the transpiler were slower than esbuild. And then I did a lot of profiling, I did a lot of looking at exactly what it was doing to make it faster and messing around mostly with the memory allocation stuff. After that it was three times faster than esbuild. So I think the answer to why is Bun fast is, it's mostly just a lot of time spent trying to make it fast. Ben: Enjoying the podcast? Consider hitting that follow button for more great episodes. I guess a question about transpilation. Does transpilation speed have any impact or does the work you did around any impact on production run speed or more just build speed, which is obviously an important part of the development cycle? Jarred Sumner: Well, the way I'm thinking about this longterm is that I want people to be doing... Bun will eventually have a production transpiler API/Bundling API. And I think what people will do with that is they will actually bundle and transpile in network requests. And so for that, you need it to be really fast. But the reason why I think people will do that is because it's going to enable a lot of new kinds of plugin systems where you have this dynamic code generation and you do server side JavaScript rendering. Similarly you do server side HTML rendering. But if you can embed the data it makes a lot of... It'll let people delete a bunch of code. Ben: Got it. Help me understand that a bit more. What's an example of what being able to do that real time JavaScript code generation will let you do? Jarred Sumner: One example would be like, say you have like a page that renders a bunch of sub client side, a really long list of content. And you know that the page is like relatively static, but there might be some amount of interactivity to it. So you're writing in React or you have like some code that fetches from an API end point. Instead, you can just embed you using the same function call that you might with React. You could just embed the data into the Bundle, and then there's no extra network request. It's just you fetch the code and it's in the code. And normally that skips a... You can do that if you do statically rendered HTML. But then you have this hydration problem where you potentially have to load the data again anyway, or you load it twice, once for the DOM version, and then once for the JavaScript version. It's much easier if the data's just in the code. And then it also enables dead code elimination that's really precise. Because it knows everything that's being used and it knows that there's no side effects from the data being injected into the build, you can remove all the parts of the data that you're not using. That part was actually implemented today through the macro API in Bun. Ben: Got it. And so let's talk a bit more about this script runner. So as of today, is Bun truly a drop in replacement for Node in terms of actually executing JavaScript or are there any gaps in terms of APIs that it doesn't yet support? Jarred Sumner: There's a lot of stuff that still needs to be implemented for Node APIs. Today, the APIs that are furthest along are FS, Buffer, Path, and then also nappy the Node API native modules, and then as well as just like Node module support, which are independent of Node APIs. You can use require and import in the same file in Bun. But there still is a lot of work to do on the Node API compatibility stuff and it is a priority. But the easiest way to use Bun right now is Bun-run, because you can just use that instead of NPM-run and it's faster. It's something like 30 times faster to start a script. And the reason why is because Bun takes somewhere between five, six milliseconds to start, sometimes less depending on the platform, and NPM takes something like 160 milliseconds to 200 something milliseconds to start. So when you do a NPM-run, you're paying that cost every single time you start a script. And so at Bun, because that just literally saves you time. Ben: And is part of that because Bun doesn't yet support a lot of the features that MPM does, or do you think even once you reach feature parity in terms of API supported, it will still be that much faster? Jarred Sumner: It's still going to be that much faster. In Bun-run, it does essentially the same thing. It reads the package.json scripts, it reads the bins from Node modules/.bin. Bun-run is actually really simple. Most of that was written in about a day, because it was most of the other infrastructure for reading package.json and JSON pars and all that stuff was already written for the transpiler. Ben: And help me understand, why is Node and NPM so much slower? Is it just they've been around for a really long time and have a lot of like historical craft that kind of just slows things down? Or is it just they were architected in a way that's just less efficient? Why have you been able to achieve such more significant performance gains by rewriting from the ground up? Jarred Sumner: In the Bun-run case, a lot of that is their startup time. JavaScript takes a long time to start up, native code doesn't. But the other parts of it is just like... with this, kind of going back to Zig, because you have really like low level control over everything and Bun basically built almost everything from scratch, excluding some standard library stuff in Zig like arrays, it means that it's much more straightforward to optimize all of it when you basically own the whole stack. Whereas in Node/JavaScript/NPM, you have the JavaScript built-ins and then you have some APIs that are written in C++ and then you have a bunch of JavaScript on top of it. So it's very hard to actually figure out everything that's going on and make it faster in a lot of cases. But also part of it is just that, well, there's a lot of code in Node and it's easier to make stuff faster when there's less code. Ben: What does all that extra code do though? Is it just legacy stuff that's not necessary for certain things? Jarred Sumner: In the Node case- Ben: Yeah. Jarred Sumner: I think they're fixing some of this with heap snapshots. But it basically loads a lot of code at startup that is just unrelated to the code you're actually trying to run. It Bun also has a lot of code now, but because it's almost all... there's very, very little JavaScript in Bun actually. It loads pretty quickly. Like in Bun-run, there actually is no JavaScript right now. Ben: And as of today is it exclusively you, or is it an open-source project other folks are working on? Yeah, what is the development? Jarred Sumner: Bun has a number of contributors. I'm still definitely the most by commit/code volume. But I think it's starting to change. If you go on the contributors list, you'll see there's a bunch of PRS. And it's been really awesome seeing the reception. Honestly, I did not expect nearly this much. Bun is at, I think, 29,000 stars on GitHub hook now, which was like a lot more than I anticipated. Ben: Yeah, no congrats. Have you done anything to market Bun or people have just found it organically? Jarred Sumner: The only thing I really did was I posted on Hacker News on the day of the launch and I tweeted about it. Well, I think really the answer here is I've been tweeting about Bun for about a year, the entire time I've worked on it. But it was in private beta for most of that time. The private beta was like, you had to go to Bun's Discord and type, "I want Bun," and then a bot would send you an invite link. And I think about 4,000 people did that. And then after I went public with it, then it's just mostly been people seemed really excited. Ben: And in terms of use cases, obviously you can run scripts faster. Bun can be a drop in replacement once more of APIs are built out. It will be just a true drop in replacement for Node in many back ends. I imagine that because of the fast startup time, there's a good application for serverless here where you're running functions at the Edge. Is that a use case you're thinking about? Jarred Sumner: I've been thinking about that a lot. I have a lot of ideas there and I think it's something that will be a focus for Bun, but probably a little bit after it's stable. We want to have stability within six months, a stable release within six months. And I think after that point, one of the things we'll focus on is specifically like a version of Bun for the Edge. It will have single file deploys. And it'll do this really efficiently because it'll use a binary Bundling format to turn it all into one compact file that loads... There's some issues with existing Bundlers, how they Bundle for server side JavaScript. A lot of the time you have to embed assets as Base64, which is much less efficient than just as binary data and with bite offsets. So Bun will have a Bundling format that works, specifically for Bun, that will solve some of these problems. And this will also improve startup time that use case. Ben: I remember when CloudFlare first launched their CloudFlare functions, whatever, they did a whole write up and one of the reasons they chose the V8 Runtime is just because the sandboxing is known to be really good. It's been hardened for years and years because obviously you have to have really good sandboxing if you're running a web browser. Is that- Jarred Sumner: This is not really true. The V8 team publicly will say that. Obviously, I don't speak for them at all, but they'll they don't say that the V8 isolates are security boundary. This is just not true. Ben: Okay. No, I stand corrected. But I'm curious if- Jarred Sumner: But it's a common thing that people think. Ben: Yeah, I'll have to dig up that blog post again, because yeah, maybe there was something else they were using for the sandboxing. With Bun, would work need to be done around sandboxing in order for it to be a drop in replacement for a public provider of Edge hosting? Jarred Sumner: Honestly, being a drop in replacement for a public provider isn't actually a priority. It's more being a drop in replacement for people instead of the hosting companies. I think longer term, Bun is going to have a solution for this, but it's just a little too early right now. I definitely think a lot about how it'll actually run on the Edge, and I'm still not really sure yet is the answer. It's still a little too early to figure out. The first thing is for Bun to be stable, that's the main priority, because it needs to run stably in production before actually deploying it makes sense. The broader question here is, how will it run? Will it be multiple instances per process? Will you need a separate firecracker, like VM? That's sort of your question. I think the answer will be that it can run multiple per process, but I think it'll be a little bit longer. Maybe it's a year out before that happens, because I think there's a lot of... It just needs really, really, really good test coverage for that scenario, and the test coverage just isn't there yet. The reason why it needs really good test coverage for that is because since Bun is written mostly in native code with manual memory made instrument, it's much easier for situations that could happen with memory leaks and things like that. Particularly if you're loading and unloading dynamically, because that would be necessary for a multiple isolate scenario. And JavaScript probably doesn't call them isolates, it just call them VMs. So for that scenario. And right now, because Bun typically runs one per process, most of the tests are once per process. But this is going to also need to be fixed regardless, because one is going to need to have worker support like the browser worker global as well as Nodes' trial workers, trial threads, worker threads. That's what it's called, worker threads. And so Bun is going to support both of these. And so it'll have a similar problem then. So I imagine it will be dealt with in the next six months, but it still is going to need a lot of test coverage before I would say that it works for a Runtime. Ben: So help me understand roadmap a bit more. You mentioned that feature parity with Node is important. Beyond that, what does the roadmap look like for the next year or so? Jarred Sumner: Yeah, so the roadmap is a few different things. One is the Bundler itself and transpiler needs to be production ready. That means that it needs to have a built-in minifier. It needs to have really good tree shaking. It needs to support code splitting. It needs to have some link time optimizations like support constant enums. It needs to have some cross module inlining. It needs to support multiple output formats. It also needs a CSS parser. This will most likely be a port of esbuild CSS parser to Bun. That's actually how the transpiler started, was I imported esbuild's transpiler to Zig, and then made it faster. That was the very first start of Bun. Then all of this needs to be exposed as Runtime APIs. Then after that, it also needs to have support for server side renting for basically every popular framework. The first one that Bun will focus on his V. That's going to need to happen before October because I'm presenting a demo of a V comp and it doesn't work yet. Another one that's on the roadmap is a loader API. This will let you import, view and spell in SESS and pretty much any other file format that you want. It'll work very similar to esbuild's API. Ideally it will even be compatible with esbuild's plugin API. So that way you can just use existing esbuild plugins with Bun and they'll work for both on the server and on the client, which I think will be pretty cool. I also want Bun to have a built-in Postgres client and my SQL client. It already has a built-in SQL client and it's on every benchmark I've seen, the fastest one in JavaScript right now. Another thing on the benchmark is this TCP sockets API. And I think there's going to need to be two of those. One for net, for Node's net module, but also for Bun itself. And I think the Bun version will be... It's going to have a different API than Nodes because there's a way to make it a lot faster, I think. Basically moving the event handling to like context objects that are reused for... Because right now with Nodes API, you have event handlers per socket. So that gets really expensive if you have lots of sockets, which servers very well might. Then after that, the next step is Edge Runtime. And there's sort of what I was talking about earlier. And then Bun also needs a repo, there's no repo right now. It needs public docs, it needs good examples, it needs a Bunch of GitHub actions. Another one on the roadmap is an NPX, but for Bun. That doesn't exist yet. It'll be really fast. I think it'll be really good. There's some web APIs that Bun is missing right now. Some of them are also implemented, but a few of those need to be done. Then there's going to be some stuff with Bun install that's missing. And I think the Bun install stuff will happen a little sooner. The Bun install stuff that's missing is GitHub support for GitHub packages, like GitHub Colon and then Git, and then workspaces and link. Those all need to be implanted. Really the basic case right now is implemented of just NPM packages. And then there's a lot of reliability work that Bun will be doing in the next six months. Like it needs to run web platform tests, it needs to run test 262, it needs to run a bunch of web kits tests. Right now it mostly just relies on Bun's tests, but I think it would be good to start running web browser tests in addition to web platform tests. Yeah, that's mostly the road wrap right now. Ben: Yeah. Very ambitious. Definitely sounds like you have your hands full there. I'm curious, some of the things you mentioned like building a new TCP/IP stack or a new SQL client or a Postgres client or what not, how are you thinking about what to build from scratch versus what to just leverage existing off the shelf software? Because it sounds like you're rebuilding so many core pieces of software. How do you think about those trade offs around building from scratch versus just adopting already built and tested parts of the stack? Jarred Sumner: I think like philosophically Bun kind of embraces not-invented-here syndrome. I think that when everything is in one package, you can really make it a lot faster and you can really make it a better developer experience. It's just a question of how do you make sure it works well, and how do you actually ship it. The shipping part is the harder part at first, and then the, how do you make it work well becomes the harder part. And I think the answer to those questions are mostly writing a lot of tests. But I think the main thing here is that for these really common use cases of running database queries, Bun just needs to be really fast. And the best way to do that is through having those APIs be part of Bun where it can be relatively easily optimized for Bun. I think if it was a general purpose library, it would... And there will be general purpose libraries, because it's important that the APIs that Bun exposes supports that. But I think that it just needs to be really fast. Ben: Yeah. So Jarred, it's been great having you on and learning about Bun. For folks out there who want to learn more, the website is bun.sh If anyone's interested in like learning more or potentially contributing, what do you recommend as the best way to get up to speed? Jarred Sumner: Yeah. The best way to get started with contributing is probably to look at Buns ReadMe. There's a contributing section towards the bottom. And the easiest way is probably to use the dev container. And that will get you set up with web kit, prebuilt and Zig and a few other things that are Buns' dependencies. And probably the thing that would be really helpful if you want to contribute to Bun right now is to write tests. Just add more tests. They can be either tests in JavaScript, which would be in the test/bun.js folder in Bun's repo, or they could just be shell scripts that run something end-to-end. And if you file an issue with like a failing test that you add, I will prioritize that first. Ben: Well, thanks again, Jarred. Jarred Sumner: Thanks a lot.