Building Full Stack React Apps with Bun

Thanks, everyone. Over the years, JavaScript tooling got too slow and complicated. Our answer to that is Bun. Bun is an incredibly fast JavaScript runtime. On every commit, we run over 2,000 tests from the Node.js test suite. We designed Bun from the beginning to be a drop-in replacement for Node.js. We're still working on that. That's what most of the team spends most of their time on is Node.js compatibility.

But it's getting better basically every day. The total percentage is going up roughly 1 per cent every week or so of Node.js' test suite passing in Bun. Bun is also a package manager. It's really fast. A lot of people have said that if you can RM-RF Node modules, that is slower than installing packages with Bun install. To do that, we did a lot of work on what is the fastest way to copy files on every single platform target, and also, sometimes, like file system.

Bun test is a really fast jest-compatible test runner. You can use it with JSX, TSX, all that stuff is built in. You can import and require in the same file. This is the comparison. It's 20 times faster than jest to SSR, 1,000 React components, but then just to print the help menu, it's three or four times faster. This is kind of like, Bun is four different things in one. It's a package manager, it's a bundler, it's a run time, it's a test runner. We intend to replace much of the tool chain with one simple tool.

Each of these things kind of work together, so, like, the runtime uses the bundler. The test runner also uses the bundler and transpiler. The runtime uses the package manager to automatically install packages. If you don't, you have a Node modules folder. The package manager uses the shell to have cross-platform shell scripts, so that way your packaged JSON scripts with like RM or CD or LS or any of those commands just work, whether it's Windows or Postix, so that way you don't need to install RimRath, for example. And we built in a lot of APIs. This list is going to grow. There's still a lot more that we want to do. We have a WebSocket server, we have an S3 client, we have a Postgres client, we have password hashing and verification. A lot of apps can be built without any dependencies. And there's also the bundler.

Nowadays, Buns Bundler has React fast support built in. It has a CSS parser. It also has an HTML parser with HTML re-writer. We also have tree-shaking, a minifier, code-splitting. A slightly less common feature that we have, or like less common relative to other bundlers is you can echo console.log from the browser to the terminal. This is really useful for AI agents where they normally can't debug stuff in your browser very easily. You normally need to install some MCP thing, but we just made it so console.log streams to the browser over the same WebSocket connection it does for HMR. We also have plugins you would expect. You can use it with Tailwind and Svelte.

How do you build a full-stack React application when most of what I just described is very focused on the front-end or the back-end, but, for a full-stack, you need both the front-end and the back-end together? In the next version of Bun, you can just import HTML, and that works both ahead of time and in development. This is what it looks like today. There's routes in bun.serve. You specify where do you want the HTML file to be rendered, and then you can also have API routes in there as well. So then you're running your React app in development, or potentially in production this way. And you can see that the routes also support request parameters. This would be for like a URL shortener. It uses request and response APIs, the web standards. And you can see that there's almost no configuration here. That's all you had to do.

This is what the HTML looks like. So what's happening here is that it's building the front-end and the back-end at the same time with bun build, and it will do that ahead of time. So that way, you don't need to run the bundler in your production server because that's kind of silly. So what that means is with bun build now, you can have on-demand, you can have the build happen on-demand in development, and then in production, you do it ahead of time. This is the way it should work. It feels pretty obvious that this is the way it should work, and it just didn't before, because everything takes time. So that's bun. We're making JavaScript simpler. Thank you. Thank you.

First question is, why is bun so much faster at downloading packages? Isn't network speed the only limiting factor? So this is kind of surprising but it's not the only limiting factor. There's just a lot of stuff that has to happen in order to install packages. You have to extract tar balls, you have to make sure that you also have to parse a bunch of JSON. Early on, when I was profiling, in the initial versions, when I was like, okay, how do we actually make a package manager that's really fast? I noticed that a lot of time in current package managers was spent parsing JSON. One of the tricks we do is when we download the manifest from NPM, we serialize it into a binary format, we check if that manifest matches the server's manifest, and when we deserialize it, it's effectively a mem copy which means it does very little work when deserializing the actual data. So basically bun doesn't spend a bunch of time parsing JSON, or tries really hard to not spend time parsing JSON when it doesn't strictly need to. And then also there's a lot of stuff with system calls. We spend a lot of time on what is the fastest possible way to copy files, what is the fastest way to, and also how to use the least number of system calls. Yeah, that tracks.

Runtime, bundler, package manager, testing, are hard problems to solve. Other tools typically concentrate on only one problem. How can bun maintain all of this? Basically, the tools we chose to build into bun all sort of use each other a lot. So the runtime uses the transpiler, the test runner uses the transpiler, the package manager uses parts of the transpiler as well, even just for the JSON parser. So it looks like it's a lot of different stuff, and it is, but also all that stuff is reused, so we end up, that saves a lot of work. Yeah. Someone also says if bun is a replacement for everything, why isn't it more widely used? We're still pretty new. Honestly, I think the main thing here is that we still have issues with node compatibility, and that's why we're working on it so much. And my expectation is that we fix the node compatibility, but also, there's a bunch of companies using bun in production today. You can see our Discord server has a bunch of people in it.

You can see our Discord server has a bunch of people in it. If you search on Twitter, you'll see lots of people talking about bun all the time. I spend way too much time on Twitter. Yeah, in my experience, bun is one of those things that when you use it, you're like, oh, wow, this is something special.

Monorepo support in bun? When? So, like, we do support monorepos, but there are a bunch of paper cuts that we need to fix that we haven't fixed yet. We did fix some of them recently. We added catalog support similar to PNPM's catalogues. We do support workspaces by itself. You can use the workspace colon version in dependency specifier in package.json. You can use workspaces generally speaking. I don't think the experience is really good yet, just honestly. But we're going to make it a lot better really soon.

Are you planning to work with Tanner, TAN stack, Vercel, or the React router team to integrate the frameworks and routers? Yes, we want to work with everyone. I actually have a PR to Next up right now that has failing tests that they need to fix to make it so that way you can import built-in modules inside of Next. Basically one tricky thing is because Bund has a few built-in modules, the Bundlers don't know that these exist, and they don't show up in node modules, so then they get confused. So basically, yes.

We've got a lot of questions coming in here. Are you planning to work with Tanner, TAN stack, Vercel, or the React router team to integrate the frameworks and routers? Yes, we want to work with everyone. I actually have a PR to Next up right now that has failing tests that they need to fix to make it so that way you can import built-in modules inside of Next. Basically one tricky thing is because Bund has a few built-in modules, the Bundlers don't know that these exist, and they don't show up in node modules, so then they get confused. So basically, yes.

Given the context of the last, well, not the last, but the first talk of the day, will Bund handle running the React compiler? I want it to. There was like a, this was like six months ago, I tried to see how far Dalem could get porting the incomplete Rust implementation of the React compiler, and it totally didn't work. But like basically we support JavaScript plugins in the Bundler and we will make those fast. They're like, well, there's still some stuff we can do there. But they do work. You could run the React compiler today. It would probably be like a 100 line of code plugin. Just like JavaScript. Yes. Yes.

Okay, we can do one more here, because we've got a lot of questions. Just a reminder that there will be a Q&A outside on the balcony as well. So let's pick a good one here. Yes. What about, or no, I like this one quite a bit. Are you working with cloud providers to introduce Bund runtime? We want to more. I don't think there's that much I can say. Yeah. That's a good answer. Thank you so much, Jared. This has been amazing.