Framework Bun: "Faster than anyone would believe" – Interview with Jarred Sumner
Jarred Sumner is the brains behind the Node.js alternative Bun. A conversation about his motivation, company, and why he dropped out of high school.
(Bild: Volodymyr Burdiak / Shutterstock.com)
- Timo Zander
- Silke Hahn
(Diesen Beitrag gibt es auch auf Deutsch.)
Since 2021, Californian software developer Jarred Sumner has been in charge of developing the JavaScript runtime Bun. The open-source project is intended to be an all-in-one tool for bundling, transpiling, installing and executing JavaScript and TypeScript code. Sumner founded his own startup Oven in 2022, which is driving the development of the new runtime environment – he was previously a frontend engineer at Stripe.
Bun is comparable to Deno and Node.js. Unlike Deno, Bun is supposed to be more compatible with Node.js. Some users call it a "drop-in replacement". It is open source, written in the Zig programming language and the first public version has been available since July 2022 (as heise Developer had reported). Heise author and JavaScript developer Timo Zander tried out the runtime and talked to Jarred Sumner about the background for the heise Developer editorial team. This interview is part of our Young Professionals series.
heise Developer: Bun is experiencing a significant hype at the moment. Can you give me the elevator pitch for it?
Jarred Sumner: Bun is an all-in-one JavaScript runtime, bundler, transpiler and npm package manager. And basically, it takes quite a lot of the existing ecosystem of tools, bundles them into one tool and makes it really, really fast. The idea is that everything in JavaScript can be a lot faster. And the way to make it faster is by moving some things into native code and choosing faster system calls. A lot of software is thought to be IO-bound – but this is really not true. In reality, most of the software is system-call-bound. So people think the bottleneck is reading something from the disk, which is what IO-bound means. But actually, the time spent parsing data from the disk often ends up taking up a significant amount of time. And people underestimate that, very often. So Bun really focuses on the performance benefits that come from reducing this system-call-time.
So it is all about parsing and evaluating the code and not so much about reading or writing?
Not exactly. Bun is twenty to a hundred times faster than existing npm clients on Linux. Also, hard drives in 2022 are very fast as long as you are not using a spinning disk – which most people are not. The bottleneck is no longer "time spent writing". But if you, for example, install one thousand npm packages of which most have been downloaded before, it is the amount of things we have to tell the computer, the system calls, that need most of the time. So by focusing on reducing system call overhead, you can make things much faster.
And the way Bun does that is through a combination of native code – doing things in native code instead of JavaScript – and by choosing really carefully what is the fastest way to do something. And it is usually something very mundane. For example, I spent probably a week trying to figure out the fastest way to copy files on a computer. On Linux and then also on macOS because the answer for both of them is actually pretty different.
You talked about macOS and Linux. What are your plans for Windows?
The Windows support will come in more than a month and less than six months from now. You can use Windows Subsystem for Linux 2, this works already today as long as you have the newest kernel.
Where does your focus on performance originate from?
Mostly just personal frustration. I was frustrated for years with how slow everything in JavaScript is. I just remember the first time I wrote Objective C and I saw just how much faster it was to use NSLog compared to console.log, and I thought: There is no reason why the basic things you do all day long in JavaScript cannot be as fast as native code for those types of tasks. When everything is just system-call-bound, it is about the overhead between sending something to hardware and the computer processing it.
Did you have any previous experience with system-near programming?
Not really, honestly, which sounds kind of bad. Well actually, it is not quite true. My experience mostly came from spending about a year building this performance-sensitive Voxel multiplayer game in the browser. Like Minecraft, but in JavaScript. It was just tough to build that and eventually the code base just got big enough that the build times and, therefore, the iteration cycle time – so the delay between saving a file and seeing the change – slowed down extremely. I tried using esbuild, I tried upgrading the tooling but it still wasn’t fast. It was enough that I would start reading Hacker News while waiting for something to reload and this just totally kills the creativity. It is really hard when you get out of the zone because you are just waiting for the build.
So what did you try then?
At first, I thought, okay I will port esbuild to this low-level language called Zig. And I did that, benchmarked it and it turned out that it was about three times faster for things like JSX transpilation. And then, eventually, I tried to get Next.js to work. And there were just so many rabbit holes so that, at first, it was merely getting the transpiler to work, and then after that, it was "I want to have server-side rendered pages". Well, for this, you need a JavaScript runtime. So, I said to myself, Node doesn’t start very fast, how can I make this faster?
What did you do next?
I looked at V8 isolates and this was faster but I wanted to see whether it can get even faster. So I started experimenting with JavaScriptCore, which is the JavaScript engine used by Safari. On all benchmarks that I could find, JavaScriptCore was faster on startup times. There is a tradeoff to make here though. For example, Hermes from Facebook starts a little bit faster but does not have a JIT. So you have to run a separate JIT which hurts runtime performance pretty quickly.
So I chose JavaScriptCore and spent around a month figuring out how to embed this thing. Because WebKit is a very monolithic codebase and there are very easy docs on how to use the C API but those are really intended for smaller usage. Maybe a game that wants to embed JavaScript for a part of the game but not for a whole runtime. So I spent a lot of time reading WebKit source code and then along the way, I was also really frustrated with npm install times, which is why I built Bun install.
Why did you choose Zig as your language of choice?
Initially, I wanted to use Rust but I had a lot of trouble being productive in Rust. What is really nice about Zig is that it is a very simple language. It is really easy to understand everything that is going on which is very important for performance. For example, in C++ there are destructors that are automatically called when an object is destroyed or you have functions that are called when they leave the scope. And this is a very common source of hidden behavior. When you can understand everything that is going on in a program, it is easier to optimize it. And Zig also has this really cool feature called "Comptime" where you can execute arbitrary code at compile time, using regular Zig.
Other languages have macros or templates and usually, they are a much more limited version of the language. But in Zig, because it is arbitrary code, it is really simple. This is also how it does generics: Instead of having a specific syntax, you just pass a type. And this type is a comp-time parameter and then you can return a new type. I thought that was very cool. I got productive in Zig within like two weeks, which is probably very close to Go’s learning curve since it does not have a lot of syntax and is light on abstractions. It is not too hard to learn.
Is experience with Zig mandatory for the engineers you hire or do they just learn it on the job?
The latter, people will just learn Zig because it is a really simple language. If you have experience with C or C++, you can learn Zig really quickly.
Why did you decide to build Bun instead of contributing to existing projects like Deno?
Honestly, I did not really think about Deno that much. Mostly, I believe it is very important to focus on compatibility to make it easy for people with existing codebases to just drop in and use Bun and immediately get a performance benefit. Either from the build system – like if you use TypeScript, it automatically loads – or from runtime through things like fs.copyFile being multiple times faster. Usually, it is around three times faster, but it depends.
Was Bun trying to be a fully comprehensive tool from the beginning?
It very much didn’t start that way. It was really just trying to make the iteration cycle time faster and then gradually expanding the scope and still gradually expanding the scope today. I just added a loader API last night. Basically, I think we can make JavaScript much faster in virtually everything. There is just so much complexity in modern JavaScript today with so many different tools. So I think, moving all of them into one tool that is a lot faster and will just make people’s lives much simpler.
Did you consider integrating existing fast tools, like pnpm, instead of building Bun install yourself?
I think it would be really hard to base it on an existing tool. Because for it to be fast, it really needs to be integrated with the rest of Bun’s existing tools. For example, the JSON parser in Bun is a custom one. The same one used for parsing package.json in Bun install is also used in the transpiler. They share a lot of code by having one tool for all these things. And it is a lot easier to optimize. Also, in Bun install’s case, none of it is in JavaScript. It’s all in Zig.
What is your timeline for Bun’s first stable release?
In about five months. It is a lot of stuff!
Anything you have not really talked about yet?
The thing I haven’t really talked about all that much is Bun test. There are currently no docs on this but it is a very fast test runner for small day-to-day tests. It is Jest compatible so companies can just use it for their existing tests. It is not there yet, to be clear. But it will come. It is around fourty times faster than Jest for small scripts and, if it is a lot of code, it is closer to four times faster. However, if you have TypeScript in there, I have seen it being two hundred times faster which is a little faster than anyone would actually believe, including myself.
But it is pretty crazy. This is mostly caused again by architecture. In Jest’s case, they have a separate loader system for TypeScript. And then they have to do a lot of runtime prototype modification. All that stuff – when you have low-level access to the runtime – you can just change it to do whatever you want. There is a lot of performance gain that comes from that. So I think Bun test will be really cool.
I also think that Bun install will be really cool once it gets workspaces support and is more stable. And then it can be adopted by larger companies. Bun’s runtime will also obviously be really exciting. One of the really exciting things is that it is going to have a client-side focused bundler. So Bun will have Bun build and it will be completely usable without a runtime, as an alternative to esbuild. And there is a lot more that people will figure is interesting. For example, it has a whole AST Plugin API directly integrated within the runtime. It works very similar to Macros where you can call small functions during build time and then you can return ASTs instead of Strings. But in Bun’s case, you can just return an object, like a response object in the Web API.
And if this response object has JSON in it, then it will automatically be converted to AST format. You can also pass context data into those macros. For example, you can have an HTTP request that returns dynamically generated JavaScript which will be very good for dead code elimination. Because previously, API responses were never statically analyzable since they were fetched in a way that the minifier and transpiler were unaware of. So by moving that to a macro, you can generate much smaller builds because you have a better idea of which code is actually used. So, it will have a Minifier too. But it will take more than six months since there is so much to do.
What is your stance towards TypeScript? Will Bun come with first-class support?
I really like TypeScript personally but Bun’s TypeScript integration essentially is only a transpiler. So, similar to esbuild or swc, Bun removes the types before the code is executed. And this works built-in, there is nothing to install. It also reads tsconfig.json, so if you have an existing project that uses, for example, paths, that just works in Bun. You don’t have to do any extra setup. It also doesn’t do type-checking, so this is a tradeoff. I think it would be reasonable longer-term to integrate tsc directly for that case. But it is not currently planned, we need to cut scope somehow.
Is there anything else left out at the moment?
I think the approach that would be interesting – which Bun is not taking – is to create a lighter version of TypeScript. After the TypeScript Type Annotation proposal ships, it would be much more straightforward to implement as a fast version. But this is a whole different can of worms because then you would need to build a different LSP and you are suddenly incompatible with existing tools. It just gets really complicated. Yes, I am not doing that right now.
You speak in the first person, but you have also founded Oven, a start-up that is behind Bun's development. What size team are you aiming for?
We are still hiring! The team size will be somewhere between three and five engineers in the next six months, mostly Zig engineers.
In one of your tweets you said that “Oven is going to be a grind”. This caused a serious outrage on Twitter. Can you give us your view on this?
I did not expect that. Some people are still mad at me. If I would be to communicate it again, I would have just said that Oven is an early-stage startup and it is going to be a lot of hard work. And I think that there is just so much to do and it is important that people who are interested in joining Oven are told ahead of time. I think it is important to just be honest with people. I think using the word “grind” was a mistake.
And I also think that people sort of assume the worst and negative intent on Twitter. I should have said, for example, that the first few employees are especially getting a lot of equity as part of this. When you are an early-stage startup, this is a very important part of compensation. Engineers get extremely meaningful equity in the company in addition to compensation – the reason why we raised seven million dollars is so that we can pay people good salaries. So I think I should have said that because people assumed that they were going to be paid nothing to work hard. That wouldn’t make any sense.
Why did you found Oven instead of making Bun a purely open source project?
It was kind of the plan from the beginning. I just always wanted to build a company, do startups. That has been like forever what I wanted.
Did your time at Stripe facilitate the decision to found Oven?
Previously, I tried a lot of random consumer apps. This was the stuff I did before I was at Stripe. Like, a Pokémon Go map that 4.9 million people used. And I built a Chrome extension with which you can give access to websites without sharing your password that a couple of million people used. So I build a lot of random things that were not really startups. And I learned a lot from doing that. But I think Stripe didn’t really have an influence on me wanting to do a startup. I read a lot of Hacker News when I was 14. This honestly was most of the influence there.
Your Twitter biography says that you are a high school dropout. Tell us the story behind that.
I was really lucky that I lived in the Bay Area. I spent basically all my time on the computer growing up. Eventually, I started learning Ruby on Rails, and this was almost ten years ago now, I built this app and showed it to my teachers who decided to try it out. And if I could build this whole thing just by myself, then maybe I could get a job doing that. Because I really hated school and I was also really bad at it. So, I cold emailed some companies nearby and one of them agreed to take me on as an intern. And the way I looked at it was that I could spend the next six years in school, trying to get a job or I could just do it now. And it worked out pretty well for me.
How did your friends and family react to this decision?
My parents didn’t really like that I dropped out of high school. They were just very worried. They still asked me when I would go to college until maybe two or three years ago. Though it wasn’t really a problem, mostly because of Silicon Valley and startups. I think in other industries it would be harder. But I think one thing that I did a really good job at – that other people should copy – is to cold email people. I think a lot of people, especially engineers, underestimate the effect of a good cold email. This is how I got my first job and how I got other jobs, too. So, I would say that the high school dropout thing for me worked out well because I got really lucky but also because I work really hard. And I spent a lot of time writing code.
A cold email is an email which is sent unsolicitedly in order to gain a potential client, receive a job opportunity or gain some other kind of benefit. Compared to spam, it is highly personalized and usually sent within a professional context.
Can you share your personal tips for cold emails?
I think just talking about why the company that you are applying to is interesting in very normal, casual language. Also, I think it is good to cold email the CEO directly because most of the time, people don’t do that. You could also cold email the Hiring Manager, depending on the company. And just talk about stuff you have done or relevant experience in very concrete detail. Or maybe even having a project that shows a special amount of interest in that company specifically.
One example that a friend of mine did is when he did an internship at a t-shirt startup when he was sixteen. So he made a t-shirt designer, as a mini clone of their project. As a demonstration that he can write code and that he is really interested in the company. And he showed it to them and they were really impressed. Because it was really impressive! For Bun and Oven specifically, I don’t expect anyone to do something like that.
In your early job postings, you asked people to present something they built with Bun. Does this come from this experience?
I think that was all stupid. There were two hours between me tweeting about Oven’s fundraising and receiving the wire in the bank account. So I really didn’t put enough thought into any of those tweets. Basically, I think what would be more interesting are any relevant projects for demonstrating low-level systems software experience.
Oven is really not hiring full-stack at all right now. And I think, it is sort of strange. Because there are the people who are most excited and most aware of Bun, that are going to use it. Unfortunately, most of those people are not the ones who will build it. The skillset is different because a lot of it is low level system stuff. Any sort of past experience with C or Rust or C++ or Zig is therefore very relevant. Especially if it is about JavaScript interpreters or any kind of interpreted language.
What exactly will Oven's role be, besides driving the development of Bun?
Bun is a runtime so it is directly embedding the engine. But I think we are still going to work on the engine. And what is really fun is seeing all the performance improvements from JavaScriptCore recently. One today, I tweeted it out, was that they made Proxies like four to five times faster when you call a getter. One that I haven’t tweeted about yet is String.replace. They made that about two times faster, too. Oven will also help with that because it is important to us that the Runtime API as well as the actual implementations of various things built into JavaScript get faster too.
Why should people be excited about Bun?
Everything in JavaScript can get a lot faster and also a lot simpler. People very often complain about how complex everything is in JavaScript. And a lot of the reason for that is because there are so many different tools that do one thing and then you have to understand where all of them fit. And they are also very often pretty slow. So Bun puts everything into one tool and makes it much faster, while still being compatible with the ecosystem.
Thank you for your time, Jarred!
The interview was conducted by Timo Zander, external author for Heise in our Young Professionals series. Zander studied applied mathematics and computer science. As a developer, he is interested in open source and the JavaScript universe.
(sih)
