Next.js at the speed of Bun

[Music] Hi everyone, I'm Lydia. My title is actually head of propaganda at Bun. Uh, and if you know a little bit about me, you know that I love talking about JavaScript runtimes and performance. Uh, actually before I joined Bun, uh, I was at VCEL for a couple years to teach next developers how to build apps faster. So, I'm very excited to be here today and show you how much better it can get when

we combine next framework performance with Bun's runtime performance. But before I talk about Bun itself, I want to take a small step back and show you like what makes frameworks like Nex.js so special in the first place because they truly redefined how we see performance on the web. It didn't just make websites faster, it streamlined every part of the process. We got smarter bundling with Webpack and now with Turboac. We got a built-in

image and font optimization. We got efficient server site rendering, static site rendering, and now we got ISR and now I guess RSC to bring data fetching into the component itself. And all of these improvements kind of pushed what the framework can optimize, but really only up to a certain point. There's always been this one fundamental layer that Nex.js hasn't been able to optimize yet. And this is not because of lack of engineering effort or you know

capability, but it's just outside of next scope. And that is the runtime itself. Normally when you run nextdev or you deploy to versel your next app runs on node. So this means that node's runtime executes your javascript. It manages the event loop file IO everything. And it bridges your javascript code to the operating system. And this makes sense because node has been you know the default runtime for like the past 15 years or so. It's battle tested. It's

reliable. But in 2025 it's also become a bit of a bottleneck. Don't get me wrong, Node is fantastic. It, you know, made it possible to run JavaScript on the server. Before that, like before Node was introduced in 2009, JavaScript was really just for the browser. Node changed that by giving us a runtime with a JavaScript engine, an event loop, async.io, and APIs to do all the things that browsers cannot do. So like reading

files from disk, memory, all that stuff. Now, under the hood, Node uses the V8 JavaScript engine. This is Google's fast Chrome engine, which is great for long running tasks like you know a tab in your Chrome browser. But of course, V8 is just an engine. It only knows how to execute JavaScript. Um, it cannot open files, you know, make TCP connections and all that kind of stuff. So, that's where nodes builtin APIs come in. So, like FS, HTTP, NET, and so on. So these

APIs are kind of the bridge between our JavaScript code and the operating system. And these APIs itself rely on a like C library called lib uv. Um this isn't built for JavaScript itself. It's more of like a a generic abstraction that node uses to be able to do stuff like file IO networking and stuff across all these different operating systems. So, you know, when we call something like fs readad file in our JavaScript

code, we're really just asking the computer like, I want to read this file from disk. But before we can get there, it first has to go through V8 then or like from a JavaScript code to V8. Then it passes it to the node C++ binding. This then calls lib UV. And this is not even mentioning like the thread work and all that kind of overhead. And only then lib uv actually makes the system call to our kernel to actually get this file from disk. And you know while that's all happening we have the event loop that