Never Worry About CORS Again

Thanks everyone. Yeah, so the rendering API is not ready yet. So I'm going to give a different talk about Bund. Kind of like... First I'm going to give a little overview of what is actually Bund, and kind of where we... Bund's past, present, and also the future. Where Bund kind of started was really frustrated with... For years I'd been really frustrated with how slow everything is in JavaScript tooling. Why does installing your packages take sometimes minutes if you're at a big company? Why does running the test take a long time? Why does every command feel pretty slow, like when you just run a command in your terminal?

And a lot of that is because the complexity of everything... There's a lot of layers in the stack, and so if you compress the layers then you get less stuff and performance improves. So Bund is an incredibly fast JavaScript runtime. It's really four things in one. It's a JavaScript runtime, it's a package manager, it's a test runner, and it's a bundler. And each of these pieces kind of uses the other piece.

So for example, the package manager uses the same JSON parser that the runtime uses, which is also used by the bundler. The bundler at runtime, we transpile every single file. And so that uses the same stuff from the bundler. And this transpiler in Bund was built for Bund specifically. It's not using any existing libraries. And the bundler also has support for things like React and CSS, as well as TypeScript and JSX. You can also compile single file executables. For example, Cloud Code, for example, uses that feature. We spend a lot of time on Node.js compatibility.

Originally, Bund was designed to be a drop-in replacement for Node.js. And what that means is pretty much everything needs to work. We consider it a bug in Bund if something works in Node and doesn't work in Bund. And so if you do run into an issue like that, please just file an issue in Bund's repo. We do have a lot of GitHub issues open, but we do actually read all of them. It just takes a lot of time. But it's important.

And we've spent a lot of time just working on getting Node's test suite to pass in Bund, and we're still working on that. These numbers are slightly out of date. There's a bit more passing now. So there's other parts of Bund, too. So we have an incredibly fast npm package manager. In the previous version of Bund, we made it faster because there are certain really common npm packages that don't need to run either post-install scripts or lifecycle scripts, but they're sort of... Or when they do need to run them, the situation where they need to run them is very limited. Like if you didn't use... Or if you skipped optional dependencies. So there's a lot of tricks that we can do and we continue to do to make Bund install really fast. We also recently added support for pnpm lockfile migration. We wrote a whole YAML parser just for that, pretty much. And because of going back to what I was saying earlier about the different pieces of Bund... Use the different pieces of Bund, that YAML parser that we wrote for pnpm lockfile migration is also used by the bundler, so you can import YAML files in JavaScript at the runtime or at the bundler. So if you're building for front end, you can import the YAML file in your front-end code, and then the bundler will bundle it into JavaScript.

And then if you're importing it in the runtime, then you can just run a file. And this is pretty good for config stuff where maybe you want to load some get of action configuration or something along those lines. Bund test is a Jest compatible test runner. Uses the same expect API. And we also implement parts of the VTest specific APIs, like the VI global is there. And we kind of add a lot of built-in APIs. This is something that I think has been missing for a long time in the JavaScript ecosystem, that there's too many small packages that do something. You just have to install so many dependencies to be productive. And it's not necessary. In fact, it's faster if you can do it in the runtime, because there's just a lot of optimizations that you can do in kind of philosophically, we try to make every single part of Bund really fast. And it takes a lot of work to do that. But it makes the product so much better. And it just makes it so much faster to build stuff, too. Because it's like you can use the standard library or the built-in library and expect it to be fast and work pretty well. So, for example, Bund password is like Argon2 or bcrypt.

You can choose which one, which are like the modern password hashing algorithms. We have a built-in WebSocket server with PubSub, which is pretty nice. Because it means you can send the same message to a group of connections at the same time. And that ends up being also a performance improvement, because you can batch up the overhead for the WebSocket protocol queuing.

We have a built-in file glob API, we have a built-in cross-platform shell. It's very batch-like, so generally, this was originally made. This is another case where we like reuse stuff across different parts of Bund. So, for the package manager on Windows, people frequently have to install rimref, which is like rm-rf, but as an npm package. And so, with Bund shell, you can just use rm-rf in your package JSON scripts, and it'll work on Windows, even though Windows doesn't support rm.

We also have a built-in Postgres client using the SQL tag template literal syntax. We also have a built-in MySQL client, and it has basically the same syntax as the Postgres client. You can see that there at the bottom. You just change out the protocol, and we're like, oh, this is MySQL. Let's connect with MySQL instead. And this is a really good way to, like, it makes it just really easy to switch database providers, or use whatever database adopter you want. We also have a built-in Redis client, and Redis is like a popular key-value store. Generally, the philosophy here is, like, these are all, like, Redis, MySQL, Postgres, S3, and the others. These are all, like, very old, not old, but like mature standards that, like, there's existing software that, like, we try to not use any bespoke internal stuff that's, like, BUN-specific.

Like, and also all of the APIs are, like, based on an existing thing. So, like, the actual API interface here is pretty much the same as Postgres.js. This Redis client is mostly similar to Ioredis. It's not 100% mapping, but pretty close. And that also de-risks some of this, because it's like, okay, part of the challenge, there's, like, what APIs should BUN have, and then also which of those APIs look like. And generally, the thing about a runtime is that you basically can't have breaking changes ever, because it's also just not really worth the time to deal with breaking changes from, like, the user's perspective.

So it's much less risky for us if we base whatever API we add on some existing common pattern in the ecosystem, and we try hard to, like, not invent new things. And then we optimize a lot of it. Like, for example, the Redis client, every time you do any network activity on it, any of the commands, it doesn't send them immediately. It uses what we call a deferred task queue. Basically, it batches all of the network calls to be after all the microtasks are drained, but before the next tick of the event loop. And that means that we can then combine all the network calls to send to, which is the system call it uses, automatically without the user having to do anything themselves. And that makes it a lot faster.

We also have a built-in file API, button.file. We do not yet have a directory API, which is kind of silly. We also have a built-in S3 API, and the S3 API and the file API are basically the same thing. And that's because, like, S3 is generally what servers use for production, like, file systems. So ideally, the remote file system API is pretty much the same as your local. So that way it's easy to test between the two. It also just makes it really easy to, like, read a file as JSON. This is such a common thing. It should be really easy. We also have a bunch of random, kind of, like, they're not random, but like, basically, when there's a package that has tens of millions or more of weekly downloads at npm, and they're, like, really small, with, like, a very clear use case that's probably never going to go away.

Like, for example, stripping the colors for NC's terminal, for writing to the terminal. So this is the kind of thing where we can make it a lot faster, mostly by using SIMD, but also by implementing it in native code. SIMD stands for single instruction, multiple data. Basically it's a set of CPU instructions that lets the CPU operate on more than one character byte at a time. So in this case, we get a 10X performance improvement, and it has the same, implements the same interface as the strip-nc package.

Similar to that, we have the button.stringwidth function, which is a 6,000 times faster string-width replacement. This one doesn't allocate any memory, which is why we can make it 6,000 times faster instead of only 10 times faster. And for this, this is using some code from the Ghost-TTY terminal. And this just calculates what is the width of the string as the user sees it in their terminal. So that accounts for graphemes, which are potentially multi-byte non-ASCII characters, or Unicode characters that can be sometimes combined together.

If you were to just look at this, you'd be like, okay, why did you add all this stuff? Because these are all seemingly random. Strip-nc, string-width, and file, and S3, and Redis, and MySQL, and password, and the WebSockets server. These are all just different things entirely. I think overall, JavaScript just isn't productive enough today. Other language ecosystems are often more productive. Ruby on Rails has built-in database, has validations, it has all this stuff where a lot of the time and programming is spent. What tools do I use, and what boxes do I put them in?

Other language ecosystems are often more productive. Ruby on Rails has built-in database, has validations, it has all this stuff where a lot of the time and programming is spent. What tools do I use, and what boxes do I put them in? With React, it's usually everything is a React component. With Rails, it's everything is a controller, or either somewhere in the controller, or somewhere in the model. A big part of the reason why JavaScript isn't productive enough is because there's too many different npm packages, you have to spend too much time shopping for libraries. If you put a lot of stuff built in, everything gets simpler.

Another thing, too, is that hardware, over the years, gets faster, but our computers don't really feel that much faster, generally. The piece at which hardware gets faster doesn't really catch up with software. Part of that is because a lot of the hardware improvements are most visible with things like Sim, where the computer is able to operate on more than one item or byte or whatever at a time. In JavaScript, it's difficult to express that. That's how we're able to get for string width, jumping back, because this is using Sims, so it can do 64 characters at a time or 32 characters at a time, instead of operating over one at a time. All that's great.

It does a lot of stuff, but I think it's also useful to talk about who actually uses BUN, because we're not yet the number one JavaScript runtime. Honestly, it's really exciting. We're getting so much more production usage this year than in any previous year. We're still relatively new. Midjourney's whole backend runs on BUN. Cloud Code uses BUN. The Portland Trailblazers use BUN for data science stuff, which I learned the other day. As of pretty recently, you can deploy to production BUN's runtime on Vercel. Datadog uses BUN on some of their open source repos. CodeRabbit's DLI uses BUN. As of pretty recently, there's two easy ways to deploy BUN. You can either use Vercel functions or you can use Railway functions.

You can either use Vercel functions or you can use Railway functions. This is the full runtime, so you can use all the frameworks that are specific to BUN, as well as all the BUN APIs. But it's still kind of difficult to deploy BUN. If you're building a full-stack app with BUN, then it's very difficult to feel like here's all the parts that care about the frontend, here's all the parts that care about the backend. Here's what should go on a CDN, here's what should be in my server. And this is something we're going to be working on more pretty soon. We're going to have a BUN deploy subcommand that will kind of generate this manifest and make it really easy to deploy BUN to other hosting providers, a variety of different hosting providers.

We're also going to make a lot more progress on Node.js compatibility. It's going to be a big focus. We've already made a lot of progress on this, but we're not there yet. And there still are things that come up, like there's a playwright. There's some issues with that that we need to fix on our end. There's some issues with worker threads. And there's a lot of stuff like that. But it's so much better than it used to be. This is also a thing that I've been thinking about a lot, that AI stuff has gotten really good. It was kind of terrible two years ago. It was okay six months ago, a year ago. But now it can write a lot of code, so that probably means it's going to be writing a lot of code in the future. So I don't really know what's going to happen there, but this is something that's on my mind.

And because we have all this stuff built in, what we see is a lot of our users just delete a bunch of dependencies when they switch to BUN. So there's all that stuff, but then it's like, how do I actually use BUN? Well, the easiest way to use BUN is to just switch out setup node in your GitHub action to be setup BUN. And then where it says NPM or node, just switch it to BUN. That's also why we have BUN run, and then also you can run a file just by calling BUN. It kind of is like, should it be like Node.js? Should it be like NPM? You can also install BUN this way. The curl script is generally what I recommend, or the PowerShell script, because we automatically detect whether your CPU is recent or not, and then choose the faster version of BUN if your CPU is relatively recent. Yeah.

Any questions? The question is, does BUN have client support for NoSQL out of the box? No. Is it possible to do that? I think MongoDB probably is the most popular NoSQL thing and it's kind of difficult to ... I think MongoDB tends to be a bit faster of a moving target, so there doesn't tend to be quite as many third-party clients there. I'm also pretty hesitant to add a random, less popular NoSQL thing, because generally we have to support ... everything has to be supported basically forever, so it has to stay in the test of time. Makes sense, right? Because SQL's been around forever, right? A lot of the SQL engines have pretty similar syntax with a few things different, right? But with NoSQL, there's so much, right? Cool.

The next question is, what's your intended versioning strategy for BUN versus Nodes versions, or do you intend to keep BUNs versioning more evergreen? I think there's kind of two questions in there. One is sort of BUN, SEMVIR, or LTS, and then the separate question is how do we treat BUNs version, or what version of Node does BUN target? I would say generally our plan here is we aren't really going to do SEMVIR, but what we are going to do is config versions, where when we have breaking changes, then you say I want the version of BUN as it seems at this version. That way people can upgrade without worrying about breaking changes. Sure, right? They can download the latest BUN, but then they can target an older API if they need to. Yeah. Cool.

The next question in there, which is what version of BUN does it target for Node compatibility, if you do process.versions.node in BUN, it will lie and say the version of Node that we pretend to be. This actually has to be very consistent because a lot of V8 C++ API and like NAPI both expect very specific versions of Node, and like V8 and other things. So it's actually a bunch of work to upgrade our fake version of Node, because we also have to upgrade our fake V8 C++ API bindings and a bunch of other things. Gotcha. Interesting. So, how easy is it to implement BUN in a project that already has NPM dependencies? Yeah, we really want to be a drop-in replacement for Node and also in many cases for NPM. So if you run the file and it doesn't work, please file an issue in BUN's repo. Basically, you shouldn't have to do anything. Just run the file.

Ok. You mentioned BUN has support for React. What support is that? And is that the only front-end framework supported? Yeah, so we have built-in support for JSX, and then it just defaults to React like the other JSX transpilers. So kind of what that means is if you're using React and you have React installed and you want to use React server-side rendering, you can use the React APIs for that. We kind of...there isn't as much of a strong standard...JSX is somewhat standardized within...there's a JSX spec and everything. And you can use JSX with non-React, and so you can also use Preact the same way you can use React in BUN. We're probably not going to add more front-end frameworks as built-in in the transpiler, unless they're going to be a little bit...what's interesting about React and JSX is the transpiler API for it is really stable. Generally, there's been one change in the last...I want to say 10 years, and that's when they switched to the newer JSX function thing. That's not what it's called, but that's basically what it is. So whereas the other front-end frameworks are a much faster-moving target, which makes it difficult for BUN to support. Right, but you can still use them. Yeah, we have a BUN plugin spelt and there's probably a Vue one as well. We have a transpiler API that looks a lot like ESBuild's API, so that means that pretty much anything that uses the ESBuild plugin API just works with the BUN plugin API, and our API actually works at both runtime and in the bundler. So that makes it a lot simpler to use it in either server or client cases. Very cool.

How do you decide which packages make it into BUN? It's kind of arbitrary, to be honest. Is this popular enough, and do we see a way to make it significantly faster or something along those lines by making it built-in? And usually, how complex is it? For example, the string-width one, I think it was a day and a half of work, and then it's like, sure, we have to maintain it going forward, but those sorts of things are actually very low maintenance because the code doesn't really change once in a while. Maybe every five years we have to update the grapheme, the specific Unicode code point ranges it uses, but that's pretty unusual. Yeah, makes sense. You mentioned that you took that from Ghosty, which is cool because yours is written in ZIG and so is theirs, so there's a lot of portability there, right? Yeah, yeah. Very cool.

Are there edge cases where you wouldn't recommend BUN for production? Generally, right now, worker threads is pretty unstable. Using workers is stable, but terminating workers is not stable. So that's one reason. There's a handful of native add-ons, which we don't support yet, that depend on the V8 C++ API. Most packages nowadays depend on the Na'vi API, which we have very good support for. We've run Node's test suite for that on every single commit. But yeah, so I guess if you're using worker threads and you need to close those workers or terminate those workers, then probably don't use BUN yet. Maybe wait a little while.

Maybe wait a little while. Okay, makes sense. Is BUN's future community extensible, or will all features be provided through internal developments? We get a number of PRs from the community. You can see our pull requests. And generally I would say that we try to be as much part of the existing JavaScript ecosystem. We're not trying to be separate. That's why we try to have drop-in Node.js compatibility. That's why you can just run stuff that you could run in Node. You can often just run it in BUN without any changes. We try really hard to make that the case, because it's just not worth time rewriting our code. That just collectively wastes a lot of time, and that's just not necessary. Right.

What's the next one here? So with BUN having such a focus on speed and performance, do you have any advice on benchmarking that you'd like to share? Generally, you want to benchmark as close to your production usage as possible. One thing that can be pretty tricky is the JIT. Because there's a trap that many people fall into with micro-benchmarking small functions, where the JIT sees that some data is static and then does something that it wouldn't normally do in production. Because it's really smart, and it's like a run-time profiler, basically. So you want to profile as much as you can as close to production. Yeah, that's one thing I've seen happen a lot. Okay, and just for everyone out there, the JIT is the just-in-time compiler in the run-times. So how does BUN handle security vulnerabilities? Yeah, so our process there is somebody emails us, or they disclose a vulnerability through GitHub, and then the first thing we do is try to reproduce it. And then we try to fix it quickly. Okay. So even zero days, just make an issue for it or something? No, there's a thing in GitHub. Oh, there's a process? I didn't know that. Yeah, and it's private until it's published. Oh, very cool. Oh, yeah. It's great. We just try to fix stuff really quickly as soon as we can reproduce it. Awesome.

And can I use BUN with things like Next.js? Yeah. In fact, in our BUN 1.3 video, we got Lee Robb in the video to say that you could use BUN with Next.js. Lee Robb is the former devrel at Purcell. So yeah, it works really well. And we run tests from that test Next.js on every committed BUN to ensure it works well. So let us know if you run into any issues and we'll fix it. Awesome.

And that looks like the last of our questions. And we are right at time. So perfect. Thank you for those questions. And feel free. We are going to be getting into our next speaker in just a moment.