React at the Edge: Building a Framework from Scratch (Live)

It's a pleasure to be here and the only thought in my mind at this moment is what idiot picked that talk. My name is Daniel. I am a full-time open source maintainer, which is honestly the best job in the world because I get to collaborate with people all around the world and build cool stuff in the open. I lead the core team building Nuxt, but I'm also on some other open source projects. I'm on the team of Nitro, Elk, Elk is an open source client from Mastodon. I built a few libraries like MagicRegex, Plotfontaine, and feel free to check them out if you want. And go to my website, row.dev, where you can find out how you can send me a direct message if you want to.

If there's not a chance to talk about something in the Q&A after the talk, I'm really delighted if you want to drop me a line. If there's anything I can do to help, really, I would love to do that. I'm a Google developer expert, a Microsoft MVP, a GitHub star, and I recently started as a software engineer at Vercel, where I continue to be working full-time on Nuxt. I live in Edinburgh, in a beautiful city, which is actually a little bit warmer than New York and New Jersey today. So there we go. It's a beautiful place, it has very short days in the winter, and it can be totally miserable when the rain and wind begin.

And someone was at my talk yesterday, and knows that it's possible to send live emojis to my slides through a secret URL, which I'm definitely not going to tell anyone. I'm not here to talk about Nuxt, but I should just say what it is, if you haven't come across it. It's a full-stack framework for building web apps. It's built on top of Vue, Nitro, Vite, and the aim is to have something that's progressively enhanceable. So people should be able to use it without knowing how it works, and then they should be able to configure it as they go. It was started one day after Next.js was started, and I do apologize about the name. It is a bit confusing. We rewrote Nuxt totally from scratch over a period of a few years in 2020 to 2022. And I'm not sure there's a line of code still in Nuxt that is the same in Nuxt 3 as in Nuxt 2. It was a total rewrite. Talk to me about that later. It was deeply scarring for a lot of people, including a lot of users, who found that the migration path from 2 to 3 was not so much a path as a precipice. But I have lots of opinions.

Anyway, we had to do that, and part of the reasons we chose to rewrite Nuxt from scratch was that there were a lot of changes that were happening in the ecosystem. So immediately for us, there was the fact that Vue had had a major release. There was this new version of Vue, Vue 3, which changed how Reactivity worked for Nuxt itself. There was also a big change. We moved from webpack 4 to 5, and then during the whole process of building Nuxt, Evan Yu, who originally created Vue, also created something called Vite, which was wonderful but also extremely frustrating because it meant we had to totally re-architect Nuxt in order to work with it. I mean, we didn't have to, but the developer experience was so incredible.

And it was an opportunity for us to rework Nuxt to be bundler-agnostic, so we built it so it could work with both webpack and Vite, and since then we've added RSPack, and we could add more. Or you could, it's pluggable, anyone can provide their own. But there were other things that were happening too, around that time in the ecosystem. So there was a move from that sort of long-lived server that starts up once and takes requests and just lasts until you need to, I don't know, start up another container or phase it out and replace it with a new deployment, to things like Cloudflow workers, which had very strict size limits, or lambdas, which had things like size constraints, the bigger your zip file, the longer it takes to unzip, and where things like cold starts were incredibly important in terms of returning a good response to the end user.

And other things like Deno, Bun, a move to ESM, and more. And so out of that, we built a server engine for Nuxt, which is totally different from what we had before, and we called it originally Nuxt Sigma, we then called it Nuxt Nitro, and finally we decided to drop the Nuxt and make it a generic server that anyone could use to build performant servers. And we wanted to design it in such a way that people could build their own meta-framework on top of it, and that has happened, so people like Brandon Roberts has built an incredible meta-framework and he uses Nitro under the hood. Equally frameworks like SolidStart or TanStackStart also work with Nitro for that to be the server for them too. And that is the best part of open-source, right?

All of that is powered by UNJS, which is a GitHub org we started at the same time, designed to make stuff that we needed in Nuxt but that we could actually collaborate with for people who were in totally different worlds, like React, for example. Yes, I feel very welcome at a React summit. And it's been really exciting to see. So stuff like Tailwind CSS uses UNJS, stuff like Angular uses UNJS, and lots more.

But I did promise that I would live-code a framework on Nitro, and I will in all honesty tell you I have no idea how this is going to go because this morning, I was pulling my hair out after a realization in the shower that I needed to totally change what I was going to build. So that's great, isn't it? So I have here a totally empty project. And let's get going. I'm going to add NitroPack and h3. And out of the box, you can actually just directly start NitroPack.

So you could say Nitro dev. And we can, let's see, we can open that in the dev server. Actually, before we do that, let me just create a root, something to actually return a response. So I'll create an index root here. And I'll just return a response, hey there. And if I start the dev server again, we have a response. In fact, if we were to request that in the terminal, you'll see we even have a HTML content type.

In fact, if we were to request that in the terminal, you'll see we even have a HTML content type. But you can do a lot more. You could do stuff like return an object. You just return whatever it is you need to return. So in this case, we would get an object. It's going to be a JSON response.

Now there are a few red squiggly lines here. And that is because Nitro, by default, has a number of behavior patterns which we need TypeScript to help the end user. So both IDE and also any type checking step. So we provide a generated TS config, which exactly tells the IDE how things work.

So in this case, we know that DefineEventHandler is auto imported. You can turn that off if you want. But it also means we can do very cool things, like imagine for a moment we wanted to create a root here called foo. And we're going to return this is foo. Yes, it is. We can actually fetch from that with type safety. So we could do something like fetch. And actually, you see we get type hinting on the available roots in this particular app.

And when we do fetch from foo, we actually get data that comes back, which is very strongly typed. We can also do things like specify other fetch API things here, like a method. So we could say there's going to be a get request. And imagine that foo was, in fact, going to be a post-only root. Well, actually, if we do that, we're now going to have a type error because we have to pass post. So there's lots of cool things that we're able to do with Nitro.

So in this case, we're performing a fetch call. We could actually use just a normal fetch and have to pass the response. That would work just as well. But one of the things that should stand out is that we're not passing a base URL because when you run this on the server, Nitro knows and doesn't actually perform a network request. It performs an internal function call that emulates a network request. It means we don't have to hit the network layer, and the whole thing is much, much faster.

But anyway, I could get lost in this. I want to show you how you might build a full-stack framework. So we're going to add a Nitro config file because we probably do need that. In our Nitro config file, we are going to create a handler, which is going to handle every other root, basically. So we can create our file-based roots, but we want to be able to render some React. And so we're going to have a root, which is going to be everything, basically. We're going to have a handler, and we're going to call it app-server.tsx. We also need to just pass some esbuild config to say that jsx is automatic, please. And we should create that file. So here we go, app-server.tsx. And we can just return... Oh, that's amazing. Okay, let's just return... Sometimes when a compiler is really helpful, isn't it? This is definitely one of those times. Whoa, that is amazing. I'm in a project called React Summit. Anyway, this is very cool.

Anyway, this is very cool. We should probably install the dependencies, though. So let's install React, React-DOM, and the types for them. And start our dev server one more time. Now if I hit, I think if I still hit my foo root, I should still get some... No. Oh, I have to post to it, I guess. I should get some JSON data, but if I don't, I'm going to get some HTML. Yay! We're rendering React. And we probably want to do a little bit more than that. We want to have a template or something, some kind of HTML document. So we'll say, hello, React Summit 2025. And we're going to need some body, that will do. And that is our template. That's where we're going to return back. Now one of the things that Nitro has is a concept of key value storage, which is agnostic, like so much about Nitro. It can be deployed anywhere. That's a very key value. I think user choice is one of the, if not the, most fundamental values of the web. So we have the ability to use a storage primitive, which in this case we're going to use something called the root prefix, which is just the files in our app. And we're going to get a template. Storage. Get item. And that's going to be a string. It's index.html. Copilot can't be right all the time. And we're going to render our HTML from our app. And then we'll return it like, please do this for me. Is that correct? I copied it. It looks right.

You can never trust it for sure. Okay. This looks good. So now what we should be able to do is actually just return, just fetch our app. And there we go. We're server rendering HTML with a full stack meta framework. Cool. It's working.

Let's add some styling. We'll add Pico CSS. And let's add our client side integration. So we need Vite for this. This is going to give us our hydration on the client side. So it's not just HTML and MPA. We want to have something that's interactive, right? It's a much better experience for our end users.

So we've added Vite. And now we're just going to tweak our config here. So we are going to want a dev handler. This runs only in development mode. And we're going to need some imports here from H3. We're going to use define lazy event handler, define event handler. What else do we need? From node middleware. I think that's probably good enough.

So our root here is going to have a... We'll use the Vite prefix. We're going to need to have a handler, which in this case is just going to be a lazier event handler. And a lot about Nitro, it happens when it's needed. So when you actually build an app and use it in production, each individual root is split. So it's a lazy import. So it means that it's able to get going faster.

And when we moved from Nuxt 2 with a long-running server, it took 300 milliseconds to start up a Nuxt instance, a totally minimal one in production. With Nitro, it was less than one millisecond. So the whole pattern here makes a huge difference for optimizing cold starts. And what we want to do here is start server... Dev server is... What is it? Create server from Vite, I think. And we're going to want to pass it a base. I think it's a base. We're going to want to say app type is custom. I think middle... No, not SSR. Server, maybe? Middle remote. There we go. And we are going to return an event handler in this case, which is why it is lazy. So you don't create it in the first place until it's needed.

So we're going to return from node middleware Vite, dev server middlewares. Cool. Let's just check if that's going to work. I think so. You check that really by hitting Vite and pulling down the Vite runtime. No, that doesn't work. Why not? We should have Vite. Alright, dev server.

This is a bad moment for it not to be working, right? Base. Maybe. Do I want root now? Base. App type. I probably want to pass JSX as well, but that's not the issue here. Maybe let's drop the... Let's try that. Yes. Cool. So we've got that coming in, which means that we can now add something to our HTML and say we're going to actually add a script, and it's going to be Vite client. Let's try that.

Yes. We've got Vite working. But it's not working all the way, of course, because there's no... We have an HMR event all hooked up, but there's no actual React app in the program yet. So let's create one. So if you have a React app, we'll export a function app. This is what you all do, right? Seems good. And we'll just import that in here. I think we can drop that. And we will just render the app here. Let's hope that works.

Cool. Still working. Now we need a client side thing for that. What we're going to do is, I think, we're going to use React DOM client, and we instead have... What is it? Hydrate root. So we're going to hydrate root. Yes. Yes.

Who needs to write code anymore? Right? Except we also want to have HMR support. So we're just going to persist this on the window. So we're going to export app, which exposes it as a module, which means we can do stuff with import meta hot. So we can do... Oh, I think I probably need to pull in our... Yeah, reference. Yeah, that. We're going to do import meta hot except. And we're going to pull in our module. And if there's a module app, then we will rehydrate. I think it should be something like... This. So we want to do... Let's see, window.root. Is window.root or hydrate it? I think we will do window.root render mod app. I have no idea what I'm typing, but I'm very much hoping that's going to work. Let's try sticking an app client here. And... Okay, we have some React dev tools appearing. That's a good sign, right? And let me see if I can stick this over to one side of the page. Hide that. And let's see if we get HMR.

No. We did not. What is it? Functions are not valid as a React child. Oh, do we need to do this? Is it as simple as this? Let's try that one more time. Yes! Ha-ha! Good news. Let's add a little bit more here. Let's stick in some styling. We'll pull in Pico CSS.

And we will stick in SVG. There we go. That should be... No, not that. Another SVG. We'll stick in this one. Cool. And I will create a little button to prove that it is really working on the client side. So what we need is const account setCount is useState. And then we'll just render a button here. Excellent. Okay, is that working? Yes! Amazing.

So we have client-side rendered React app. And that's all being built by Vite and Nitro. Now, I have a little bit of a worry here. Because I'm pretty sure we are approaching the end of this talk. And there's probably quite a lot more that we could still do. There is so much that you can do to create a meta framework. In this case, we have some really, really useful utils that you can use.

So I'll just show you the beginnings. And we won't go too much more. But we have a utility in Andreas called Kitty. And another called C12. And you can build your own CLI very, very easily with this. You can pull in run main from Kitty. You can pull in load config from C12. And you can pass any arbitrary config file. And you can very easily create your own CLI with just calling run main. Passing in some subcommands. We could pull in dev and build.

And we could create it. I'm going to push all this up, by the way, to GitHub. So you can have a look. We'll just call this init. And publish it. But I'm aware we're out of time.

So I'm not going to do too much more right now. But do feel free to take a look. Because I will push some other stuff. So we actually show you what a CLI might look like. How you can build and deploy that very same meta framework that we started.

Having said that, though. Everything that I just showed you is out of date. And irrelevant. Because this is what we did for NUX 3. And this is how we built NUX 3. We used Nitro under the hood. We do lots and lots of different things. We configure it. We make it play nicely with VEET.

We start a VEET dev server. But this isn't going to be needed at all with Nitro version 3. We're already in alpha. And we're expecting to release it in beta pretty soon. It comes as a VEET plugin. So you don't need a meta framework. You just use VEET and stick it in your VEET config as a plugin.

It uses the new environment API. It has built-in React support. So actually you don't have to do any configuration of that either. It uses web standards. I didn't dive too much into how Nitro works under the hood. But in Nitro version 2, it was its own event format.

But we've moved entirely to request and response events. So you can even drop in if you want Hono or Elysia into your Nitro app. And everything plays nicely and works well together. We believe in coalescing with this sort of growing move of frameworks across to use this new pattern. It is so much faster than Nitro version 2.

Nitro version 2 is insanely fast. But Nitro version 3 is a different order of magnitude. Because a lot of what we do at runtime in Nitro 2, we've moved to actually be a build time optimization. So stuff like the router. We don't even have a matching syntax. We emit if-else statements. It's so much faster. And we use a tree-based thing. So it's not just a case of matching every possible route.

There is so much more to say about it. But if you are interested, please check out the NUX docs. And also the Nitro docs at nitro.build. Feel free to follow us on BlueSky. That QR code will take you to a pack of people building stuff in the NUX ecosystem. You can look me up on any social media network you want, except Twitter, for obvious reasons. I do have a page on my website, row.dev.chat. Feel free to go there. You can book a video call with me any time. I'm more than happy to chat about anything in any way that I could possibly help if I can.

Thank you very much. Particularly if you want to get involved in open source, whether in NUX or Nitro or one of the other projects I'm involved in, you would be really welcome to do that. Even if it's something else totally different, drop me a line, book a calendar invite. That's particularly true if you are not sure you would be welcome or if you're not sure that you're exactly like the maintainers of the project. I would love to do what I can to help and tell you that you certainly would be welcome in any project I'm maintaining. There's so much more to say, and I'm sorry I only covered a very little bit of building a full-stack framework with Nitro. But it has been such a privilege to be here with you. Thank you very much.

Thank you. Who's going to go home and write a better framework? Yeah? A few hands in the audience? Yes. So you've definitely inspired some people to use the cool stuff that you've built.

We don't have any questions yet. Is there anything you didn't get to say that you maybe want to tell the audience? Well, thank you, CJ. As it happens, there were one or two features I could have built, yes. Okay, nice.

Can you talk a bit about NJS? I don't know if people are as familiar with it, but we've seen you talk about it a few times. There's a lot of really cool stuff in there, and similar to how even things that aren't Vue are using Vite, a lot of things that aren't like Nuxt or Vue are using NJS. Can you talk a bit about the NJS ecosystem? Absolutely. So again, the core concept is that it should be something which is universal.

So a lot of what we're doing there is creating utilities that work the same everywhere, so in different runtimes. So there's a project called unenv, which was actually adopted by Cloudflare, and they did incredible work on it, by the way. I mean, it was a collaborative project, but they really dived in particularly at the end, and it powered a lot of the compatibility layer for people using, I think, Wrangler. There's stuff like crossWS, which is building WebSocket servers that work seamlessly everywhere, whether that's Node, Deno, Bun, or whatever.

Stuff like OFetch powered the dollarsignfetch thing that you saw there. It's a Fetch-compatible API, but with hooks, automatic unwrapping of responses and things like that. I don't know. There's so much. Check out unjs.io. There's a lot of font-related stuff, which I'm particularly involved in. I don't know. There's just so much. Yeah, it's a lot of cool stuff. Definitely go out and explore it. That's all the time we have, but thank you so much. It's a pleasure. Thank you. Proof. Proof.