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

lip uv uses so the rest of our

javascript code can still execute and so

on. And this model works fine like we're

still using node but it's not optimal.

So back in 2009 so again when node was

introduced our hardware looked very

different. Servers maybe had like four

cores, limited memory, and storage was

pretty slow. Threads were also

expensive. So creating a new thread for

every connection just didn't really

scale well. So nodes model was great for

that era because we could use one thread

to handle like thousands of connections

really efficiently. But fast forward to

2025, our hardware looks very different.

We now have hundreds of CPU cores,

terabytes of memory, and storage is like

50 times faster, but we're still using

like nodes model based on 2009. It's

still pushing everything through that

same event loop. And again, this is fine

like nodes architecture is fine when

servers ran for days. that in modern

times we often have like serverless

functions or we have dev servers all

these more like short burst scripts that

need to start up fast and run for a much

shorter amount of time. So in these

environments every millisecond of

startup and every you know like data

layer matters here because they all add

to latency.

Now again when you run your next app you

are running it on node. So this means

that everything that your app does, so

like rendering pages, serving assets,

streaming responses, they all go through

all these layers that we just saw. So

from JavaScript to V8 to note, all that

kind of stuff. And Next has done an

incredible job at squeezing every bit of

performance uh kind of despite having

the node runtime still blocking certain

things because at the end of the day,

all these improvements still run on top

of node. So when you spin up like a dev

server or rebuild files, hot reloading,

you're still hitting those runtime

limits. So if we really want to go

faster, we have to look beyond the

framework. We have to go a level deeper.

We have to rethink the runtime itself.

So that is where bun comes in. Bun is

not just like another layer built on top

of node. It is a brand new runtime built

from scratch for the hardware that we

actually have in 2025.

So instead of being written in C++ on

top of lib uv like you saw with node bun

is built in zig and this is a modern

systems language that runs much closer

to the metal. So for the javascript

engine bun uses uh apple's really fast

JavaScript core engine and this spins up

really fast mainly because it can like

defer some of the initialization

optimizations that engines like V8 make.

Uh, and it also just runs really

quickly, which again is perfect for kind

of the modern tasks that we use nowadays

with dev servers, serverless

environments, and these shorter build

scripts.

The core runtime itself is written in

Zigg. So the bun APIs and all the parts

that handle async.io. So where node uses

lip uv for all of these async operations

uh so like file or like reading files

network requests and so on bun can

implement these as direct system calls

to the operating system because it's

written in zigg u now for network

requests we use socket so it's a bit

different but we're removing so many

layers of abstraction by using zig

instead of lib uv

so now if you want to read a file with

the bun runtime time. Uh it still goes

of course from your JavaScript code. It

now goes to the JSC engine to Zigg which

can then make that direct system call.

So again fewer layers uh between our

JavaScript code and the actual operating

system. And the result here is that

everything feels so much faster from

startup to file access HTTP servers and

so on. But bun is not just about

performance. We also aim to be 100% node

compatible. So, we want to make sure

that all of Node's own APIs work. Uh,

but then it also ships with tons of

additional builtin APIs like S3, SQL or

Squeal, whatever you want to say,

Reddis, hashing, a shell, so many

things. And if you've ever used other

programming languages like Go or Python,

this kind of like batteries included

approach might is very familiar to you.

But as JavaScript developers, we've just

gotten so used to installing

dependencies for pretty much everything.

Like I I use like password hashing in

almost all my apps, but I still have to

install a dependency every time I'm

using it. So bun changes that the stuff

that you use pretty much all the time is

just built right into the runtime

itself. It's just built on the global.

And again, these are not just like

surface level wrappers on top of an npm

dependency. They're truly builtin zig.

So they're optimized for performance for

the modern hardware. So for example, bun

has a built-in SQL client. So you can uh

connect directly to Postgress, MySQL,

and SQLite using a single API. You don't

have to install any additional

dependencies. And again, this is not

just calling some npm package. Uh it is

truly all bun just talking directly to

the system.

And it's not just convenient that we

have these builtin buns options are

usually also a lot faster than the node

and npm alternative. So for example here

bun.sql is up to uh 11 times faster than

my sql 2 on node which is really good.

Or you can use like bun's s3 client and

this works out of the box with any S3

compatible storage. So Amazon S3,

superbase storage, Cloudflare R2, you

name it. And again also this API is

incredibly fast. So here we can see that

it's up to like six times faster than

AWS S3 SDK on node. Now of course you

can still use your normal dependencies

with the bun runtime as well. You don't

have to use these built-in APIs. Um but

they do reduce your bundle size a lot

because we're no longer, you know,

adding these dependencies and it helps

with npm vulnerabilities that we saw,

you know, like last month because you

don't have to install them. There's tons

more APIs. I highly recommend that you

uh check out the docs as well. But Bun

comes with way more than just a runtime.

Uh it also ships with a really fast

package manager that's up to 17 times

faster than yarn, seven times faster

than npm and four times faster than

PNPM. And the good thing you do not have

to use the bun runtime to use bun

install. And this is just you can use

bun install with node. It will just

work. So you don't have to change

anything about your project. Uh it also

has a really fast built-in bundler and

transpiler so you can serve and build

your files instantly. So you don't need

Webpack, ESB build, no extra setup. And

the nice thing is also supports

TypeScript and JSX right out of the box.

Um it also has a really fast test runner

that's up to 14 times faster than Vest

and 23 times faster than just when we

SSR like a thousand React tests. So

again, you get really fast tests. You

don't have to install anything.

So this all sounds great, but how can we

use the bun runtime in next? Honestly,

it's really simple. After installing

bun, you just have to update your start

command or your dev command and add bun

run- bun. That's it. You're you're now

running the bun runtime. Now you might

be wondering why do I need that d-bun?

Like I'm I'm already saying bun run. Uh

that's again because bun really cares

about node compatibility. So normally

like if we just use like bun run next

dev bun will detect that next CLI uses

that node shebang uh and in that case

bun will be like okay I understand that

I have to use node so then it will just

default back to node even though we said

bun run but with the d-bun flag we're

kind of forcing that to skip the shebang

and say okay we're just using the

runtime so just as kind of an extra

explanation.

So now with this command bun start your

next dev server. Uh the bundler itself

is still next. So that's still you know

turboac I guess webpack turopac now

that's the default. Uh but now the

runtime underneath all of that so the

thing that's executing your javascript

reading files serving responses and so

on that's all bun. And because bun is

designed to be node compatible you

shouldn't have to change anything about

your code or your packages or your

middleware everything should still be

working. Uh if it doesn't, that's also

considered a bun or a bug in bun. It

should be 100% no compatible. So uh if

you're trying this, you run into issues,

let us know. But you shouldn't have to

rewrite anything.

And now that your app runs on top of

bun, you get access to all of bun's

built-in APIs. So for example, we can

just use the S3 client, write in like a

server function in React server

component and so on. So we don't have to

install any dependencies. So just to

compare what it normally would have

looked like with this with node you can

see that with bun we have a lot less

code we have fewer dependencies and it's

instantly compatible with all the other

S3 providers as well. So if you want to

change from Amazon S3 to like cloudflare

R2 superbase storage all these other

providers that's super simple

uh or a more like complete one we can

use S3 the bun shell and SQL directly in

a react server component. So, first we

like query the database with SQL to

fetch a blog post, generate a pre-signed

S3 uh URL for the image, use the bun

shell to count the words. Again, there's

no extra like API layer or third party

tools that Bun is calling. Bun handles

the runtime, the database connections,

and the shell all natively in SIG. So,

close to the metal. And again, of

course, it's not just S3 SQL. You get

access to all of bun's APIs by just

adding bun run-bun

uh in front of nextdev. Um but of course

now you might be thinking okay I don't

like I'm not using postgress I'm not

using s3 I'm not using any crazy

dependencies so why should I care the

the thing that got me into bun before I

joined was honestly just the incredible

dx. Um you can just run any js ts tsx

jsx doesn't matter file without any

configuration. It just works. So you

don't have to think about you know ts

node babel swc and so on. So even if you

aren't using next even if you're just

developing you want a quick like build

script just using bun run honest just

try it. It makes your life so much

better because you yeah you don't need

any configuration.

Uh bun also comes with bun x and this is

bun's kind of equivalent to npx. Again

you don't have to change anything. You

don't have to use a bun runtime for

this. You can just change npx with bunx

and you see instant like startup

improvement. So for example uh using

bunx create next step is like five times

faster than npx create next step and you

again you don't have to use the bun

runtime for this. It's just a lot

faster. Uh then of course there's also

bun install which again does not require

you to change the runtime. It just makes

your installs so much faster also on

basic next projects.

Now obviously running bun locally is one

thing but how do we deploy apps that run

on bun because this is of course a whole

like new runtime.

Now you can already use Nex.js on bun on

several platforms like render railway or

containerize your app with docker but

we're all next.js developers ideally we

also want to be able to deploy to

versel. So naturally we uh tweeted at

Giermo kindly asking him for native bun

support on Versel and we quickly got a

pretty promising response and then a

couple weeks later bun support has been

achieved at least internally. So I'm

very excited that native bun support

will come to Verscell very very soon and

this means that you'll be able

[applause] yes

applause goes to the great engineers at

Verscell that made this possible but

this is very exciting because this means

that we can now run bun apps just as

easy as any other next project on

Verscell. So also just a real world

example. I'm not sure if you can see it

on the screen, but running a Hono API

with bun uh already saw a 30% drop or

CPU drop by just running bun on Versel.

This is of course a different framework.

This is Hono API, but it's the same

runtime benefits that you will get if

this was like a server function RSC and

so on because bun saves a lot in CPU and

memory usage.

Now we of course don't have to wait for

native bun support to start using it in

our apps. The simplest way is kind of to

start using it or to adopt it

incrementally. So first I recommend just

switch to bun install changes nothing in

your codebase. This just uses buns

really fast package manager. Also if

you're interested in knowing why bun

install is so much faster. Uh I wrote an

article on this not too long ago. I

highly recommend you check it out. It

just explains, you know, we're not just

skipping steps or doing whatever. It

kind of explains the systems engineering

behind it that makes it so much faster.

Now after using bun install then try to

use the bun runtime. You can just use it

locally with bun run-bun. Test your app.

See if everything works. It should. If

it doesn't let us know. Um and then

lastly you can kind of incrementally

move to bun's native APIs where it makes

sense. Uh you can of course still like

mix and match these npm dependencies. Uh

but the best part is also that each step

here is reversible. So, if you did use

like one of Bun's native APIs and it

didn't work, you can always just switch

back to Node. Um, but it's definitely

worth checking out.

Now, before I end this talk, I just want

to say a really big thank you to the

amazing team of engineers at Bun. Most

people might know Jared, but there's an

entire team behind Bun that work so hard

every day to make Bun even faster, more

stable, and so much more fun to use.

They are truly like pushing the limits

of what's possible with JavaScript.

So, Next reimagined how we built for the

web, but Bun reimagines what powers it.

Thank you so much for coming to my talk

and I'm so excited to see what you'll be

building with Bun and Next.

[music]