One of the most interesting new JavaScript projects is Bun.js, a from-scratch server-side runtime and toolset. Bun is rapidly gaining developer mindshare with, as of this writing, almost 40,000 stars on GitHub. I got a chance to talk with Bun’s creator Jarred Sumner, who recently secured VC funding for his startup Oven.sh to help nurture the project. We discussed what inspired Bun.js, some of its technical aspects, and Jarred’s experience running a startup.
More about Bun.js
You can learn more about the technology behind Bun in this introductory article. Bun recently added initial support for a built-in bundler—putting the project on track to become a one-stop shop for server-side JavaScript tooling.
Tyson: The first thing I think readers want to know is: What inspired you to create a new JavaScript runtime? What are your main objectives with Bun?
Sumner: I’d been frustrated for years with slow and complicated JavaScript tooling. Shortly before Bun, I was building a multiplayer in-browser Voxel game. The codebase got larger and the time from saving code in my editor to seeing the change in-browser was like 30 seconds—long enough to instinctively read Hacker News. So I started working on the build tooling.
Tyson: What are your main objectives with Bun?
Sumner: Bun is an all-in-one JavaScript/TypeScript bundler, transpiler, npm package manager, and JavaScript runtime. We want to make JavaScript faster to run and simpler to write. An important part of that is ecosystem compatibility. Bun is designed as a drop-in Node.js replacement. People shouldn’t have to rewrite their code to use Bun. Many Node.js APIs like Node’s native modules API, fs, path, process, and more are built-in to Bun (though we’re still working on it).
Tyson: Interesting! So, does Bun not require a separate bundler like Webpack or Vite? (Ed note: The built-in Bun.js bundler release coincided with this conversation.)
Sumner: Bun has its own bundler and transpiler implemented in Zig. When you run a TypeScript file, JSX, a CommonJS module, ESM module, etc., it’s transpiled automatically using Bun’s transpiler.
Tyson: With regard to the Node-like aspect of Bun, did you fork Node.js itself? Is there an event loop at the heart of Bun, like with Node and Deno?
Sumner: No, we reimplement Node.js APIs and make them faster.
Yes, there is an event loop and it’s mostly custom built for Bun (excluding the HTTP server, which is based on uWebSockets).
Tyson: Bun is “edge-first” in regard to targeting fast start times (so instances can spin up to meet demand). How did you go about achieving that?
Sumner: JavaScriptCore, the engine Bun’s runtime uses, tends to start faster than V8 (the engine Node uses), so that helps a lot. A lot of Bun’s runtime APIs are implemented in Zig and C++ instead of JS (unlike Node). We spend kind of an absurd amount of time instrumenting/profiling and thinking about performance.
It’s also worth highlighting that Bun isn’t just a runtime—you can also use it as an npm client for Node.js projects (bun install) and as a package.json scripts runner (like npm run, except it’s bun run). It also works as an npx alternative—as described here—called bunx, which allows you to auto-install and run an executable from npm, but it’s 100 times faster than npx.
Tyson: I saw this Tweet from Builder’s Steve Sewell where he’s startled by how fast bun install runs. I’m curious, does bun install run in parallel like Yarn?
Sumner: Yeah—it resolves modules, downloads, parses JSON, and extracts tarballs in parallel. The install step is single-threaded but that’s because I benchmarked it and it turns out installing is faster single-threaded.
Tyson: Are you a *nix/C/C++ guy by nature?
Sumner: Honestly, I spent more time as a front-end engineer. Building that Voxel game was really hard. I learned a lot about performance doing that.
Tyson: Haha, I wonder how many of us got started building games. (Mine was building Ultima clones.)
I see you’ve brought in funding from Kleiner Perkins and also Guillermo Rauch of Vercel. That must be very exciting. When you sat down solo to build this project, did you have a startup in mind?
Sumner: Yeah. I’ve always wanted to do a startup. Bun wasn’t clearly a startup when I first started working on it, though—I just kept expanding the scope.
Tyson: Was the impetus that, “It’s taking too long to see my changes in the page” feeling?
Sumner: Yeah. The game used Next.js for the front end dev server. I wanted to get Next.js to work for Bun’s dev server, which is how I ended up adding a JavaScript runtime to it.
Tyson: Did you get that game finished? Can we play it?
Sumner: No, I stopped working on it after I got really into Bun. If you go far enough back on my Twitter, I tweeted videos of it.
Tyson: Do you have any model or philosophy or mentor(s), or similar, that you are using to pilot through the startup process? (I’m always curious how more tech-oriented founders navigate the business and funding side of startups.)
Sumner: I’ve kind of always been into startups, e.g., I did the Thiel Fellowship in 2014. But from a startup/fundraising perspective, developers are really excited about Bun. A lot of VCs reached out when they saw how developers react to Bun. Personally, though, I definitely still spend too much time coding. It’s kind of my default happy place.
Tyson: Well, you are in good company. Brendan Eich still codes.
The response to Bun is kind of amazing. It’s really interesting how much developers, developer experience, and the community are driving things with this project. By the way, where did the name Bun come from?
Sumner: Yeah it’s been crazy and really awesome.
A friend suggested the name “bun” because she has a bunny named bun. My initial reaction was “I’m not going to name it after your bunny.” And then I thought about it more and it made some sense.
Tyson: Haha, that’s great. I think naming the company “Oven” is funny and clever also.
Sumner: Thanks, that name was our lead investor’s idea.
Tyson: Here’s a left-field question: Do you have any thoughts on AI or Crypto?
Sumner: I’m really optimistic about Copilot-like language models. So much programming is boilerplate code that requires almost no thought and language models seem like they’ll eventually be really good at helping developers spend less time writing code like that.
I think there’s a future where programming languages are designed for language models instead of language models adapting to existing programming languages.
I don’t really have opinions about crypto.
Tyson: That’s interesting. I kind of see that happening at a higher order as well with meta frameworks like Mitosis and jHipster. What’s the experience like coding in the Zig language?
Sumner: Zig is sort of similar to writing C, but with better memory safety features in debug mode and modern features like defer (sort of similar to Go’s) and arbitrary code can be executed at compile-time via comptime. It’s really good for writing performant low-level software.
It has very few keywords so it’s a lot easier to learn than, for example, C++ or Rust.
Tyson: I was going to say, Rust is kind of the go-to systems language for performance these days, and you answered my question as to why you went with Zig instead. comptime sounds interesting.
Sumner: It’s great. instead of C++-template voodoo, it’s just Zig. A lot less stuff to learn.
Tyson: I’ve noticed that you are almost live streaming Bun’s development on Twitter at times. It’s going to be really fun to watch as Bun grows and develops.
This content was originally published here.
