Server Components with Bun

♪♪ ♪♪ ♪♪ My name is Jared, and I'm the creator of Bun. Bun is a modern all-in-one JavaScript runtime environment. It's designed to start fast because it has the edge in mind. It's designed to achieve new levels of performance by extending JavaScript core, the engine. It's designed to be a great and complete tool, which means it combines a bundler, a transpiler, a package manager, and a runtime.

And the runtime is designed to be a drop-in replacement for Node.js. Bun installs NPM packages 20 times faster, and what this means is, it's actually creating a new Node.Modules folder, and it's just in— this is designed to be compatible with Node.js, so you can use bun install in Node.js applications without using bun's runtime. Bun run starts package.json scripts 30 times faster, and a lot of that is because we take really fast native code, and we use that to parse your package.json and the rest, and in bun build— in bun v0.6, we introduced bun build, which is a new JavaScript and TypeScript bundler.

A bun build has built-in support for server components. Server components let you use top-level await and react components that run on the server. And you can use RPC, where that lets you mix and match server-side code and client-side code, and it'll call those functions. And through compiler code splitting, it will make network requests and really easily run the code on the server without having a whole API. From Bun's perspective, useServer is mostly just code splitting. There's no React in this transform. I'm going to show you a quick demo of server components in Bun. So I'm going to refresh the page, and you can see just real quick there, you saw it said awaiting child, acing child component, and what that did.

So we have the suspense fallback. We're rendering the server message function, passing it, wait, and we're calling sleep for a reason, a wait inside of a component. Like it's any other JavaScript code, you can do that with server components. And this code is run on the server. If we look in the response, we can see that there's no page for server. There's no page that says hello from server. It's actually in the network. If we look in here in this HTML string, you can see right there. It says hello from server. So that's being streamed on the server. And then if we go back, we can call functions on the server. We call get server timer. We look in button, you can see that we're passing it the greet function. And if we look in the greet function, we can see there's this use server directive.

The idea here is this makes it a code splitting boundary where funcs.ts only runs on the server. And it gives a special annotation to these functions that lets you call this code on the server.

So if we look at button, we can see from buttons perspective, which is a used client component, it's only run on the client, we can just use top level away and it will call this function, which is on the server from the client. And you can still use state and the rest of react inside of these client components because these are fully executed on the client and not on the server.

So the idea here, basically, is it is a really easy way to do RPC with client, which means it lets you call functions on the server, call functions on the server from the client. If we look at the code that's generated here, and yeah, this is a little bit messy. There's a stupid bug I haven't fixed in this with where it's adding two at the end of variable names, but we can see that there's actually no React in any of these imports. This is React, but that's because this is from using JSX, but the actual server components part, which is right here, there's no React in that.

The way this works is if we go to... Think this is the right file? No, it's not the right file. If we go to... Nope, not that one. This file. We can see that we are overwriting the imports using Bun's plugin API to load from a manifest generated in BunBuild to know what each of those client and server imports resolve to. And so, as part of BunBuild, we output this components manifest, and that is a list of all the server and client components bundled in a build. And this is all stuff that we're going to release that's better. What you're seeing right now is a very work in progress demo. This is not clean code. We're going to have a project that has a much better demo app than this that is closer to something that people might actually use. But the end result is that you can run code that streamingly renders React or any other library with the right integration from the server and mix and match client code in there, too. And the end result is you get less JavaScript you send to the client. Because you can have code where it only serializes the result instead of serializing everything.