00:00:00(upbeat music)
00:00:02- Hi, everyone.
00:00:06I'm Lydia.
00:00:07My title is actually Head of Propaganda at BUN.
00:00:11And if you know a little bit about me,
00:00:13you know that I love talking about
00:00:14JavaScript runtimes and performance.
00:00:17Actually, before I joined BUN,
00:00:19I was at Vercel for a couple of years
00:00:21to teach next developers how to build apps faster.
00:00:24So I'm very excited to be here today
00:00:26and show you how much better it can get
00:00:29when we combine Next Framework Performance
00:00:32with BUN's runtime performance.
00:00:35But before I talk about BUN itself,
00:00:37I wanna take a small step back and show you
00:00:40like what makes frameworks like Next.js
00:00:43so special in the first place.
00:00:45'Cause they truly redefined how we see performance on the web.
00:00:49It didn't just make websites faster.
00:00:52It streamlined every part of the process.
00:00:55We got smarter bundling with Webpack and now with Turbo Pack.
00:00:59We got a built-in image and font optimization.
00:01:02We got efficient server-side rendering, static-side rendering
00:01:05and now we got ISR and now I guess RSC
00:01:08to bring data fetching into the component itself.
00:01:12And all of these improvements kind of pushed
00:01:15what the framework can optimize,
00:01:17but really only up to a certain point.
00:01:21There's always been this one fundamental layer
00:01:23that Next.js hasn't been able to optimize yet.
00:01:26And this is not because of lack of engineering effort
00:01:29or capability, but it's just outside of Next's scope.
00:01:34And that is the runtime itself.
00:01:37Normally when you run Next dev or you deploy to Vercel,
00:01:40your Next app runs on Node.
00:01:42So this means that Node's runtime executes your JavaScript.
00:01:45It manages the event loop, file IO, everything.
00:01:49And it bridges your JavaScript code to the operating system.
00:01:53And this makes sense 'cause Node has been
00:01:55the default runtime for like the past 15 years or so.
00:01:59It's battle tested, it's reliable, but in 2025,
00:02:03it's also become a bit of a bottleneck.
00:02:06Don't get me wrong, Node is fantastic.
00:02:09It made it possible to run JavaScript on the server.
00:02:13Before that, like before Node was introduced in 2009,
00:02:17JavaScript was really just for the browser.
00:02:20Node changed that by giving us a runtime
00:02:22with a JavaScript engine, an event loop, async IO
00:02:25and APIs to do all the things that browsers cannot do.
00:02:29So like reading files from disk, memory, all that stuff.
00:02:33Now under the hood, Node uses the V8 JavaScript engine.
00:02:37This is Google's fast Chrome engine,
00:02:39which is great for long running tasks,
00:02:41like a tab in your Chrome browser.
00:02:44But of course, V8 is just an engine.
00:02:46It only knows how to execute JavaScript.
00:02:49It cannot open files, make TCP connections,
00:02:52and all that kind of stuff.
00:02:54So that's where Node's built-in APIs come in.
00:02:57So like FS, HTTP, NET, and so on.
00:03:01So these APIs are kind of the bridge
00:03:03between our JavaScript code and the operating system.
00:03:07And these APIs itself rely on a C library called libuv.
00:03:13This isn't built for JavaScript itself.
00:03:16It's more of like a generic abstraction
00:03:19that Node uses to be able to do stuff like file IO, networking,
00:03:23and stuff across all these different operating systems.
00:03:27So when we call something like fs.read file in our JavaScript
00:03:31code, we're really just asking the computer,
00:03:33like, I want to read this file from disk.
00:03:36But before we can get there, it first has to go through V8,
00:03:40or like from a JavaScript code to V8.
00:03:42Then it passes it to the Node C++ binding.
00:03:46This then calls libuv, and this is not even
00:03:48mentioning the thread work and all that kind of overhead.
00:03:52And only then libuv actually makes the system call
00:03:55to our kernel to actually get this file from disk.
00:03:58And while that's all happening, we
00:04:00have the event loop that libuv uses
00:04:02so the rest of our JavaScript code
00:04:04can still execute and so on.
00:04:06And this model works fine.
00:04:08We're still using Node, but it's not optimal.
00:04:13So back in 2009, so again when Node was introduced,
00:04:16our hardware looked very different.
00:04:19Servers maybe had like four cores, limited memory,
00:04:23and storage was pretty slow.
00:04:25Threads were also expensive, so creating
00:04:28a new thread for every connection
00:04:30just didn't really scale well.
00:04:32So Node's model was great for that era
00:04:34because we could use one thread to handle
00:04:36like thousands of connections really efficiently.
00:04:40But fast forward to 2025, our hardware looks very different.
00:04:44We now have hundreds of CPU cores, terabytes of memory,
00:04:48and storage is like 50 times faster.
00:04:51But we're still using like Node's model based on 2009.
00:04:55It's still pushing everything through that same event loop.
00:04:59And again, this is fine.
00:05:00Like Node's architecture is fine when servers ran for days.
00:05:04But in modern times, we often have like serverless functions
00:05:08or we have dev servers.
00:05:09All these more like short burst scripts
00:05:11that need to start up fast and run
00:05:13for a much shorter amount of time.
00:05:16So in these environments, every millisecond
00:05:19of startup and every data layer matters here
00:05:23because they all add to latency.
00:05:24Now again, when you run your next app,
00:05:31you are running it on Node.
00:05:33So this means that everything that your app does,
00:05:36so like rendering pages, serving assets, streaming responses,
00:05:40they all go through all these layers that we just saw.
00:05:43So from JavaScript to VA to Node, all that kind of stuff.
00:05:46And Next has done an incredible job
00:05:49at squeezing every bit of performance
00:05:52despite having the Node runtime still blocking certain things.
00:05:57Because at the end of the day, all these improvements
00:05:59still run on top of Node.
00:06:01So when you spin up like a dev server or rebuild files,
00:06:04hot reloading, you're still hitting those runtime limits.
00:06:09So if we really want to go faster,
00:06:11we have to look beyond the framework.
00:06:13We have to go a level deeper.
00:06:15We have to rethink the runtime itself.
00:06:18So that is where BUN comes in.
00:06:20BUN is not just like another layer built on top of Node.
00:06:24It is a brand new runtime built from scratch for the hardware
00:06:28that we actually have in 2025.
00:06:33So instead of being written in C++ on top of LibUV
00:06:37like you saw with Node, BUN is built in Zig.
00:06:40And this is a modern systems language that
00:06:42runs much closer to the metal.
00:06:45So for the JavaScript engine, BUN
00:06:47uses Apple's really fast JavaScript core engine.
00:06:51And this spins up really fast, mainly
00:06:53because it can defer some of the initialization optimizations
00:06:57that engines like V8 make.
00:06:59And it also just runs really quickly, which, again,
00:07:01is perfect for the modern tasks that we use nowadays
00:07:05with dev servers, serverless environments,
00:07:07and these shorter build scripts.
00:07:10The core runtime itself is written in Zig.
00:07:13So the BUN APIs and all the parts that handle async I/O.
00:07:17So where Node uses LibUV for all of these async operations,
00:07:22so like reading files, network requests, and so on,
00:07:27BUN can implement these as direct system calls to the operating
00:07:31system because it's written in Zig.
00:07:33Now for network requests, we use a useSockets,
00:07:36so it's a bit different.
00:07:37But we're removing so many layers of abstraction
00:07:40by using Zig instead of LibUV.
00:07:44So now if you want to read a file with the BUN runtime,
00:07:47it still goes, of course, from your JavaScript code.
00:07:49It now goes to the JSC engine to Zig,
00:07:52which can then make the direct system call.
00:07:55So again, fewer layers between our JavaScript code
00:07:59and the actual operating system.
00:08:01And the result here is that everything
00:08:03feels so much faster from startup to file access, HTTP servers,
00:08:08and so on.
00:08:09But BUN is not just about performance.
00:08:12We also aim to be 100% Node compatible.
00:08:15So we want to make sure that all of Node's own APIs work.
00:08:19But then it also ships with tons of additional built-in APIs,
00:08:23like S3, SQL, or Squeel, whatever you want to say.
00:08:27Redis, hashing, a shell, so many things.
00:08:30And if you've ever used other programming languages,
00:08:32like Go or Python, this kind of batteries-included approach
00:08:37is very familiar to you.
00:08:39But as JavaScript developers, we've
00:08:40just gotten so used to installing dependencies
00:08:43for pretty much everything.
00:08:45I use password hashing in almost all my apps.
00:08:48But I still have to install a dependency
00:08:50every time I'm using it.
00:08:52So BUN changes that.
00:08:54The stuff that you use pretty much all the time
00:08:56is just built right into the runtime itself.
00:08:59It's just built on the global.
00:09:01And again, these are not just like surface-level wrappers
00:09:04on top of an NPM dependency.
00:09:06They're truly built in Zig.
00:09:08So they're optimized for performance
00:09:10for the modern hardware.
00:09:12So for example, BUN has a built-in SQL client.
00:09:16So you can connect directly to Postgres, MySQL, and SQLite
00:09:21using a single API.
00:09:23You don't have to install any additional dependencies.
00:09:26And again, this is not just calling some NPM package.
00:09:30It is truly all BUN just talking directly to the system.
00:09:35And it's not just convenience that we have these built in.
00:09:38BUN's options are usually also a lot faster
00:09:42than the Node and NPM alternatives.
00:09:44So for example here, BUN.SQL is up to 11 times faster
00:09:48than MySQL 2 on Node, which is really good.
00:09:51Or you can use like BUN's S3 clients.
00:09:54And this works out of the box with any S3-compatible storage.
00:09:58So Amazon S3, Super Base Storage, Cloudflare R2,
00:10:02you name it.
00:10:03And again, also this API is incredibly fast.
00:10:06So here, we can see that it's up to like six times
00:10:08faster than AWS S3 SDK on Node.
00:10:12Now of course, you can still use your normal dependencies
00:10:16with the BUN runtime as well.
00:10:17You don't have to use these built-in APIs.
00:10:20But they do reduce your bundle size a lot,
00:10:23because we're no longer adding these dependencies.
00:10:25And it helps with NPM vulnerabilities
00:10:28that we saw like last month, because you
00:10:30don't have to install them.
00:10:32There's tons more APIs.
00:10:33I highly recommend that you check out the docs as well.
00:10:37But BUN comes with way more than just a runtime.
00:10:40It also ships with a really fast package manager
00:10:44that's up to 17 times faster than YARN,
00:10:47seven times faster than NPM, and four times faster than PNPM.
00:10:51And the good thing, you do not have
00:10:53to use the BUN runtime to use BUN install.
00:10:55And this is just-- you can use BUN install with Node.
00:10:58It will just work.
00:10:59So you don't have to change anything about your project.
00:11:03It also has a really fast built-in bundler and transpiler.
00:11:06So you can serve and build your files instantly.
00:11:09So you don't need Webpack, ESBuild, no extra setup.
00:11:12And the nice thing is it also supports TypeScript and JSX
00:11:15right out of the box.
00:11:18It also has a really fast test runner
00:11:20that's up to 14 times faster than vTest and 23 times faster
00:11:23than jest when we SSR'd like 1,000 React tests.
00:11:26So again, you get really fast tests.
00:11:28You don't have to install anything.
00:11:31So this all sounds great, but how can we use the BUN runtime?
00:11:35And next, honestly, it's really simple.
00:11:38After installing BUN, you just have
00:11:40to update your start command or your dev command
00:11:42and add bun run --bun.
00:11:45That's it.
00:11:46You're now running the BUN runtime.
00:11:48Now you might be wondering, why do I need that --bun?
00:11:51Like, I'm already saying bun run.
00:11:54That's, again, because BUN really
00:11:55cares about node compatibility.
00:11:57So normally, if we just use bun run next dev,
00:12:02BUN will detect that next CLI uses that node shebang.
00:12:07And in that case, BUN will be like, OK,
00:12:09I understand that I have to use node.
00:12:11So then it will just default back to node,
00:12:12even though we said bun run.
00:12:15But with the --bun flag, we're kind
00:12:17of forcing that to skip the shebang and say, OK,
00:12:20we're just using the bun runtime.
00:12:21So just as kind of an extra explanation.
00:12:25So now with this command, bun start your next dev server.
00:12:29The bundler itself is still next.
00:12:31So that's still, you know, Turbo Pack.
00:12:33I guess Web Pack, Turbo Pack, now it's the default.
00:12:35But now the runtime underneath all of that,
00:12:38so the thing that's executing your JavaScript,
00:12:40reading files, serving responses, and so on, that's all bun.
00:12:44And because bun is designed to be node compatible,
00:12:47you shouldn't have to change anything about your code.
00:12:50Or your packages or your middleware.
00:12:51Everything should still be working.
00:12:53If it doesn't, that's also considered a bug in bun.
00:12:57It should be 100% node compatible.
00:12:59So if you're trying this, you run into issues, let us know.
00:13:02But you shouldn't have to rewrite anything.
00:13:05And now that your app runs on top of bun,
00:13:07you get access to all of bun's built-in APIs.
00:13:10So for example, we can just use the S3 client, right,
00:13:13in like a server function, in React server for component,
00:13:16and so on.
00:13:16So we don't have to install any dependencies.
00:13:18So just to compare what it normally would have looked
00:13:21like with this with node, you can see that with bun,
00:13:24we have a lot less code.
00:13:25We have fewer dependencies.
00:13:27And it's instantly compatible with all the other S3 providers
00:13:31as well.
00:13:31So if you want to change from Amazon S3 to like Cloudflare R2,
00:13:35super base storage, all these other providers,
00:13:37that's super simple.
00:13:40Or a more like complete one, we can use S3, the bun shell,
00:13:44and SQL directly in a React server component.
00:13:47So first, we like query the database with SQL
00:13:50to fetch a blog post, generate a presign S3 URL for the image,
00:13:54use the bun shell to count the words.
00:13:57Again, there's no extra like API layer or third party
00:14:00tools that bun is calling.
00:14:01Bun handles the runtime, the database connections,
00:14:05and the shell all natively in SIG, so close to the metal.
00:14:09And again, of course, it's not just S3 SQL.
00:14:12We get access to all of bun's APIs
00:14:14by just adding bun run --bun in front of next dev.
00:14:20But of course, now you might be thinking, OK,
00:14:22I'm not using Postgres.
00:14:24I'm not using S3.
00:14:25I'm not using any crazy dependencies,
00:14:26so why should I care?
00:14:28The thing that got me into bun before I joined
00:14:31was honestly just the incredible DX.
00:14:34You can just run any JS, TS, TSX, JSX,
00:14:38doesn't matter file without any configuration.
00:14:41It just works.
00:14:41You don't have to think about TSNode, Babel, SWC, and so on.
00:14:46So even if you aren't using next,
00:14:48even if you're just developing, you want a quick build script,
00:14:51just using bun run, just try it, it
00:14:53makes your life so much better because you don't
00:14:56need any configuration.
00:14:59Bun also comes with bun x.
00:15:01And this is bun's kind of equivalent to NPX.
00:15:04Again, you don't have to change anything.
00:15:06You don't have to use the bun runtime for this.
00:15:08You can just change NPX with bun x.
00:15:11And you see instant startup improvements.
00:15:13So for example, using bun x create next step
00:15:17is like five times faster than NPX create next step.
00:15:20And again, you don't have to use the bun runtime for this.
00:15:23It's just a lot faster.
00:15:25But of course, there's also bun install, which again, does not
00:15:29require you to change the runtime.
00:15:31It just makes your installs so much faster, also
00:15:33on basic next projects.
00:15:36Now obviously, running bun locally is one thing.
00:15:39But how do we deploy apps that run on bun?
00:15:42Because this is, of course, a whole new runtime.
00:15:46Now you can already use Next.js on bun on several platforms
00:15:50like render, railway, or containerize your app
00:15:53with Docker.
00:15:54But we're all Next.js developers.
00:15:56Ideally, we also want to be able to deploy to Vercel.
00:16:00So naturally, we tweeted Guillermo,
00:16:03kindly asking him for native bun support on Vercel.
00:16:07And we quickly got a pretty promising response.
00:16:10And then a couple weeks later, bun support
00:16:13has been achieved at least internally.
00:16:15So I'm very excited that native bun support will
00:16:18come to Vercel very, very soon.
00:16:20And this means that you'll be able--
00:16:22[APPLAUSE]
00:16:23Yes.
00:16:25Applause goes to the great engineers at Vercel
00:16:28that made this possible.
00:16:29But this is very exciting because this
00:16:31means that we can now run bun apps just as easy
00:16:34as any other Next project on Vercel.
00:16:37So also just a real world example.
00:16:39I'm not sure if you can see it on the screen.
00:16:41But running a HONO API with bun already
00:16:44saw a 30% drop or a CPU drop by just running bun on Vercel.
00:16:49This is, of course, a different framework.
00:16:50This is HONO API.
00:16:51But it's the same runtime benefits
00:16:54that you will get if this was like a server function, RSC,
00:16:56and so on.
00:16:57Because bun saves a lot in CPU and memory usage.
00:17:02Now we, of course, don't have to wait for native bun support
00:17:04to start using it in our apps.
00:17:06The simplest way is kind of to start using it
00:17:09or to adopt it incrementally.
00:17:11So first, I recommend just switch to bun install.
00:17:14Changes nothing in your code base.
00:17:16This just uses bun's really fast package manager.
00:17:18Also, if you're interested in knowing
00:17:20why bun install is so much faster,
00:17:22I wrote an article on this not too long ago.
00:17:24I highly recommend you check it out.
00:17:26It just explains-- you know, we're not just skipping steps.
00:17:28We're doing whatever.
00:17:29It kind of explains the systems engineering behind it
00:17:32that makes it so much faster.
00:17:35Now after using bun install, then try to use the bun runtime.
00:17:39You can just use it locally with bun run --bun.
00:17:42Test your app.
00:17:42See if everything works.
00:17:44It should.
00:17:44If it doesn't, let us know.
00:17:47And then lastly, you can kind of incrementally
00:17:49move to bun's native APIs where it makes sense.
00:17:53You can, of course, still mix and match these NPM dependencies.
00:17:57But the best part is also that each step here is reversible.
00:18:00So if you did use one of bun's native APIs and it didn't work,
00:18:04you can always just switch back to node.
00:18:06But it's definitely worth checking out.
00:18:08Now before I end this talk, I just want to say a really big
00:18:14thank you to the amazing team of engineers at bun.
00:18:17Most people might know Jared, but there's
00:18:19an entire team behind bun that works so hard every day
00:18:23to make bun even faster, more stable, and so much more
00:18:26fun to use.
00:18:27They're truly pushing the limits of what's
00:18:29possible with JavaScript.
00:18:32So next, re-imagined how we build for the web,
00:18:35but bun re-imagines what powers it.
00:18:38Thank you so much for coming to my talk,
00:18:39and I'm so excited to see what you'll
00:18:41be building with bun and Next.