About this talk
This talk covers the advancements made in Nitro version 3, a tool developed by Pia Mantha for managing server-side applications within the Vite ecosystem. The speaker introduces how Nitro has evolved to be smaller, faster, and more integrated with various workflows, simplifying the development of full-stack applications by allowing easy API route integration. They explain the concepts of server-side rendering and the importance of creating a seamless development experience, emphasizing that integrating Nitro with different frameworks is straightforward. Furthermore, the session discusses how Nitro enables flexibility across various platforms through agnostic primitives for databases and caching, making deployments versatile. The speaker shares an innovative leap into leveraging Nitro alongside AI agents to create an operating system experience entirely in the browser, showcasing real-time capabilities of the framework and its integration with modern technologies.
Full transcript
[music] >> Thanks. >> [sighs] >> Hi, everyone. I'm really excited to be here and sorry my voice might be a little bit tired because it was really excited in the last 2 weeks and I was actually awake till 4:00 in the morning. It was not the first night. Uh a lot of interesting things that are happening with agents and like I'm still learning about it. Uh So,
I'm so glad to be here like one more year with amazing view ecosystem that has started to grow like everything that we build in Knox ecosystem, everything we did with view ecosystem, with wheat ecosystem, all coming together into something greater and greater every year. And uh well, again, yet another year. Uh I'm so glad to introduce and share some more updates about Nitro. I'm Pia Mantha. I'm
creator of Nitro on ZS and H3 framework. They are more back-end servers and more focused on the server tool chain in Knox and rest of the ecosystem, but they are really relevant uh I think nowadays to be. Um >> Let's start. I'm going to uh first introduce what we have built in last year uh for wheat plus Nitro. But how we even revolutionized Nitro into something way
way smaller, way faster, and way better to be integrated into different workflows. And uh we just yesterday announced wheat version 3 beta is ready for public testing. I really recommend you to read the blog article to see uh what we have changed. And uh quickly before going really exciting stuff that I actually I tried to make a demo of it uh for view today. Uh I'm trying
to introduce uh some of the things that uh introduce and how you can use Nitro actually in your wheat applications together with view. So, imagine you have a pretty normal application with wheat. Uh Usually you import a configuration, you add some plugins for React your or for view for your favorite favorite framework. And it makes an optimized server, a client that you can deploy. And uh in
development time you have HMR and everything. But what if you want to have a server? There are multiple ways of doing it. You can use a separate back-end like PHP, you can use Express, you can deploy different place. You can use meta frameworks that actually wrap wheat or like most of meta frameworks actually wrap wheat, so there is no other options. you can use them that they
do some dark magic to make it possible to add a back-end or some API routes to your server. But many of the times you just need a simple API. You need to add some API routes for a back-end even if you have dedicated back-end for your front-end uh you need a back-end for front-end, you need some caching, you need to reshape the API points. So, in many
cases you need the some sort of back-end and you need to also make sure that this back-end can deploy anywhere. Like it can work in a Docker container, you can deploy it to one of the managed platforms like Vercel or Cloudflare. And uh it should work consistently. With Nitro it's now super simple. Like we just have one wheat plugin, you add it to wheat and it would
become full stack. From SPA to full stack is just one plugin. Um you can have just Nitro itself as a plugin. So, you have basically deployment to everywhere, you have SSR, you have base integrations, and you can also use Nitro for adding server stuff. Before in Nitro version 2 it was kind of base of the framework, but now it's completely opt-in. If you need API routes, just
add a server in config. And that's all. It's a full stack application. Uh also we spend a lot of time to refine what is simple and you know simple is the hardest thing. Uh the simplest API how you can add an API route without having the complex context, without returning complex responses, without like doing these crazy stuff. Sometimes you just need an API route that just returns
a mock response. It is just a function. You don't need to serialize the response, you can return a file from it, you can return I don't know uh anything. You can return a stream from it, you can return response from a React SSR in a view application. It doesn't matter. As long as it is serializable, Nitro understands it and makes something really optimized for production. Uh so,
that's basically the simplest way to create a hello world API route after we add the wheat application uh with Nitro plugin. Also before in Nitro version 2, Nitro was tied with one framework. So, you could use Nitro with H3, which is super simple, is really efficient for Knox. Like basically if you have Knox, you have Nitro and you have H3 for server routes. But there are so
many interesting frameworks and uh to be honest in the end they are basically fancy way to manage your code. They are like fancy wrappers over standards and servers. So, it's pretty much an opinion. I we really wanted to make sure that if you have an opinion, if your team already is familiar with Express, is Hono, with ADL, whatever framework is there, it's as simple as possible to
just add it to the Nitro workflow. And that's it. You don't even the configuration. We introduced the super simple concept called server.ts. Uh you can add it to your project, you can export any framework from it. It could be a web standard framework, which like three of them are like probably the best recommended ones today. And uh the only requirement is that these frameworks export a fetch
function, which all these three standard frameworks export it. So, it just works. Alternatively you might have some frameworks that are based on legacy Node.js APIs like Express and Fastify. They are great, but in the new ecosystem everyone is moving to the web standards and they are a little bit lagging behind. So, we spent a lot of time and research to make a full compatibility layer and that
is so so fast uh that can wrap these frameworks. And actually these wrappers like it pass through. Uh so, even though everything is based on web APIs, we can still use these frameworks. So, if your team is already having an Express application you can upgrade it to a modern server, you can add like uh other API routes, but also your entry could be just a server Express
application. You have best of both. You have like a Node.js compatibility layer which is almost close to native. And you can also have start adding web APIs. The only difference is that you need to add like a note suffix so we know that we need this conversation layer to convert a Node.js application to a modern web Also server-side rendering. I mentioned black magic and I think like
every conference I'm going I'm saying black magic because we made meta frameworks, I made it like many times, we maintain them and to be honest it is black magic. Like the things that we have to internally do to make things just work, the experience that just works out of the box, it's not easy. The reason I was just even into the view ecosystem was that I was
starting to understand what is SSR, I read Evan You's uh like examples how to see how SSR works. And it is complex. The the simplest thing is that you need to build the same application one time for client, we need to one time make it for server, and you need to make manifest to map them, and then you have to bundle everything to deploy. That's basically the
thing that meta SSR meta frameworks do. With wheat and really really thanks to the contributions from wheat ecosystem and wheat team uh to the new advancements way easier way to do this. So, like before, like I mentioned uh also adding server-side rendering it's just one server entry we add to the projects once we have Nitro. It is also a standard fetchable export. You can export a function
like the previous one we saw, like a normal function. It could be like a traditional web export. Inside it we do the simple logic. But this is the magic. This is something really smart that is actually proposed by wheat team by Hiroshi. And uh basically the whole client manifest management because before we had to like in Knox we have to build one time for the client, then
we have to collect a manifest, and we have to make it bundle with the server. So, basically we need a framework to do that for us. But now because wheat has a concept called environment API, it's like a build orchestrator, it has knowledge about different builds like server, client, or React server components. We could just use an import query. It's built into the Nitro from the a
plugin. And by just doing that we can have this asset mapping. So, essentially if you want to have server-side rendering with any framework like React on solid sta- solid uh like view that's the only requirement. We have to just import the manifest and bind it somehow like render the headers. And uh if you go to the Nitro documentation, we have examples for most of these frameworks and
most of them are as easy as this. Maybe React even is easier because if you want to have like route matching. But overall, this is the new world. You can make your own server-side rendering, you can make your own meta framework with just few lines of code. We came a long way after years we learned how to solve the problems. Now they are solved at the core
where they belong like in wheat. So, this is the experience with Nitro. Nitro also provides some agnostic primitives. What are primitives? So, imagine if you want to like if you have a server with Node.js, you probably have to have some sort of file system. You need to store your files server files, you need some sort of database with MySQL, there's Postgres. Uh you need to store data
somewhere. If you are going to deploy to some platforms, most of them have their own unique features, like their own key-value system, their own database features. And uh it is a hard choice, like you can choose one platform and go with it, but what if you change your mind? You have to refactor the whole code again to make sure it works with other platform and you can
just try and compare two of them at the same time because you are locked into one of them, even if that's super super great. So, with Nitro, we have some optional features, like storage, we have cache handler, we have database. They are like a layer, it's a generic abstraction layer that they can connect with the providers, like it's just basically a configuration in Nitro and by default
it's configured. Uh it's configured for the platforms. We use the same interface for them, like if you have like if you want to cache something, it doesn't matter how this cached, where this is stored. It knows the platform. So, it just works. If we convert to another platform that doesn't even support cache, no problems, it just uses in memory in worst-case scenario and it keeps working. Same
for database, we have like a abstraction layer for database. So, there is like a SQL query, but it doesn't matter it's connecting to SQLite, which is by default enabled, or a Postgres server, or whatever we want. And this is also one of the powerful features in Nitro that can help to make sure that our applications are not locked into one We are also recently working on some
concept called local dev emulation, which is also important, as important as agnostic agnostic abstractions. For so many reasons, uh abstractions doesn't always work, like you know, imagine like there is something very unique to a platform, like abstractions usually try to make all these like together, but sometimes we need to uh like have something especially to the platform. And the hardest part is trying it out in development.
You want to see exactly what is the behavior when you deploy your application. And uh using this new configuration that we are introducing in Nitro version 3 is also as simple as just adding a configuration. You say, I want to deploy to a Bun server, so in my dev, even if I'm using Node, I want to have a Bun like environment. And we try to just emulate
it as close as possible. Headers, the available globals, everything. So, you are not surprised when you deploy. And in the end, yeah, you can deploy anywhere. You can deploy to any local runtime you have, your own server system, you can deploy to managed services, or like any provider. That's the story of Nitro. Like that was what we had been building for years, that's what we had been
perfecting and improving over years, and Nitro version 3 beta is almost the latest state of the But it's also super fast, it's based on V8 and Rollup, it's like less than half a second for building a super complex application, it's like the build time is way way different now from before. there are new areas to cover. And this is the exciting part that almost two years two
two weeks ago, I started to think about it, like say, can we do it? And that's the next question. Look, uh we can build any server, like there are super simple primitives, you can render everything, you can run it everywhere, you have agnostic primitives, is deploying the only way to make an application? Like there are so many ways, like imagine the Q screen, like shops, imagine like
CLIs that you can bundle with application, CLIs that can run a documentation, imagine CLIs that in editing era that like agents are like a layer now between humans, us, and the computers. It's like before we used to use write assembly code, but now we write better code. So, CLIs really understand agents can really understand CLIs, they can work with them. If we can make sure that Nitro
can be deployed or locally built in a way that agents can use it, just imagine, like it's a new target. It's a completely new target, it's really relevant to what we was building. And thanks to that like all the abstractions that we made through Nitro, it would be as seamless as possible, like you can just build a server and just give it to agents. It it would
be really cool, right? And I started to think like, you know, it's a cool different pivots concept and like I didn't want to just change the direction of Nitro to just do this. And I was thinking that how much flexible is Nitro today? Can we actually tries it out in real world? Can we try a CLI service using Nitro that can be a CLI not a server
that you deploy or run? And the answer is yes. And I probably went a little bit too much crazy and uh I can show you like the first inspiration why I made it. This is was the first time. Sebastian was uh my friend. He was crazy and he was saying like, "Hey, you can just everything in your browser." I was like, "Yeah." I also had a package
from 11 years ago, I think. I can Can you hear the cat? I can hear it here. So, yeah, I'm glad you asked. Links. Open my assist. And everything is in my browser, there's no server, nothing. Like we went to a very far away. It is also plain a JS application, everything is in my browser, I can also speak to it. I probably it's not working now,
but I can speak to it, it can answer, I can load the LLM model, it's like less than 200 megabytes. It's amazing, right? And uh this was a random weekend project, I was bored and I was just refactor it. I am Bonzi. Nice day. Oh, by the way, this is also synthesized by Chrome. It is built in your browsers, in your phone. You can open this URL
and just try it out. Your phone is capable of synthesizing different voices, like running LLMs, many so many things. We pay a lot for our phones, we are not using it. So, anyway, it was like a random project and it inspired me, like I tried to think about these and CLIs and Nitro and now we are like we have everything ready, what we can do with it.
it was maybe a little bit crazy in the weekend, but I uh did something. I made an operating system, a real operating system using Nitro and Vite and Vue.js. Of course, a front end because browsers are really advanced. Like I see like sometimes I randomly just see open source like working like Num, you know, like desktop environments in Linux, they are like legacy JavaScript code that is
really hard to maintain and hard. We use beautiful. We have something really really fast that can build a whole like full-stack big application in half a second. We can bundle it, we can optimize it. Why not make an operating system with it? So, I decided to try to get out and uh I two weeks ago like I was tired, I just wanted to also try something new,
so I tried to trust Cloud to write the code for me, but I observe every step of it. well, actually it happened, like uh you can open pi.cloud.ss. It's actually a real operating system. You can As you can see, this is not macOS, this is web. But it can run as an OS. It can like open a chat window, you can ask it, "Hey, can you open
a terminal for yourself, write code for yourself?" And open it in your own browser, you can also connect any model to it. Uh it's it's really cool stuff. And the coolest part is that I didn't have to like spend so much time for making it. It was made by agents for agents. And there is a big difference between these, to be honest, for me, and uh I
also tried to try Open Cloud for a while. Uh also, you know, I have my home lab, like it's not like I'm uncomfortable with CLIs and everything, but CLIs are not for humans, to be honest. I I also don't like to maintain it every day, like I don't want to see what's happening in my server and don't trust what is running. I want to see what my
AI is doing. I wanted to have same features of Open Cloud. You How many people have not heard about Open Cloud, by the way? Cool. Like no one, like everyone heard about it. And like I I don't know if you saw the pictures in China, like people are just having like uh lines to form them to set up Open Cloud, like it's crazy. Like I think everyone
in the planet is probably already heard But how many of you have heard about Pi? 1 2 3 4. You know, Pi is powering Open Cloud. Pi is an SDK made by another Austrian guy, uh Mario, and that's basically the SDK behind it. So, Open Cloud is like uh nearly like combination of all these solutions together and like tied to each other, like it's huge, like thing.
It works, but it's the power is from something way way simpler, which is like a monorepo that you can build your own agent, and the cool part is that it's fully documented. You don't have to write code for it. It can read its own documentation and make your agent for you. This is how it started. Like I said, like read your docs, make an operating system for
me. No, it wasn't like that, but something like that. Uh [sighs] I'm going to show you more, uh but I guess probably just coming back to the code is probably easier. I was also showing it to others later Something I learned, like you know, I tried like I don't know, more than 20 30 times uh different projects to see how I should use LLMs, how I should
use agents, and it was very different experiences I had. And uh I also tried the skills, like to be honest, like every time was pressuring me, you have to make your own skills. Like I was like, "Yeah." And I spent actually I made the whole monorepo, I spent like two days for it. it it wasn't working even, to be honest. And this line of the code, to
be honest, it this was the start. You don't believe, like this this is how I learned. You have to create a memory for your agents because they need to restart the context. If you want to change your model, if you want to make them focus on different things, they have to maintain a context. And there are like tons of systems for memory or whatever. I They don't
make sense. Even Open Claw is also adopting this system. Uh they have their own documentation in simple markdown files. So, when I started work on this, I said like the first line, keep your agents updated, and then I asked, "Hey, please create documentation for yourself for the rest of the journey." And then I said, "Hey, create a Vue application with all the zero skills." Because it already
knows there are tons of stuff in internet. It knows about Vue. Even if it doesn't, it's capable of fetching it about it. I said, "Set up Vue and a simple index.html application. I want window management. I want to add Vue." Uh for Nuxt, it was a little bit hard because by the time it wasn't uh beta ready. So, the documentation wasn't ready. I had to share the
link to it. So, they read that documentation. But in the end it found a way, and it made like the whole documentation system for for systems like like I wanted Apple design. I asked like, "Hey, do a proper research to see like how is it pixel perfect?" Like the UI of Pi Claw is almost close to macOS application. You can see like the experience. Uh so, it
made the documentation by itself. Like I wanted to add a display application with Electron and I wanted it to have like system architecture, which is super important. Every time you are going to one focus area and you're saying, "Hey, add an application for me. I want I text editor application." It has to know where it has to go. If you don't have these files, and if you
you don't reference them from agents.md, it works. Yeah, of course. Like you can also use it AI that way, but it's going to take time. It has to grab every file. It has to guess where it really has to start. Just imagine like if you're a person. Every time you're asking them if they if they don't have memory, if they forget, they have to try to remember.
If if even if they are super smart, like it doesn't matters. Even if they know like they're super good developer, they have to remember. If you don't give them documentation, if you don't force them to write documentation for themselves, it doesn't works. And basically this is the concept of Open Claw and all these modern agents. They don't have complex memories. They just use a like simple text
file. There's a lot I want to share more about these stories, but maybe we don't have But uh just to show you uh yeah, this is like the whole configuration. I see like so many simple projects in like enterprise projects. Like they have 200 lines of Vue configuration for nothing. This is enough for making an operating system. And like it's full of stack. It has CLI. It
has front end. It has back end. We don't need extra configuration. This is more than enough to just add Vue, Nuxt, and Tailwind. The rest it can build for itself. Actually, I was reading an article from OpenAI that they figured adding more libraries is more burden for LLMs. Like if they can make a small tools for themselves and they can maintain it for themselves, like I don't
even know how the fetching works. Uh To be honest, I don't know. Like I don't have to know. Uh it's just I trust it and it works way better than I imagined. So, like it it maintains all of this. Like for so many of them, you know, in Node.js we have so many popular libraries. I may have like libraries for CLI, for many other things. I'm not
using them because AI is not benefiting from them. It can benefit from directly writing code itself for itself, for small utilities. So, nothing complex, to be honest. Like Vue, like yeah, it can't rewrite Vue without rewriting Vue. You have to rewrite the whole Vue. Without like Nuxt, we have to invent a lot of layers. But without Vue, we don't have a build system. But it's to be
honest, it's more than enough now to build anything with this stack. Just three software. Yeah, it can make its application. It can make its prompt. Uh By the way, let's me run it for you. Did anyone tried it yet? It's super exciting. Like you can also run the command. It's just It seems like a big thing, but if you just run this command, it runs your operating
system. >> [snorts] >> Make it full screen. It also has a feature called uh like uh sandboxing. So, agents, you know, agents are like loops. They run a model. They have tools for reading and writing files and executing commands. And Open Claw is unsecure by default, right? Because it's super cool to give the whole access to your system, but then what happens if it does something bad?
So, I think the first part was that Actually, I did it last word, but the first part was that add a security layer. Add a sandboxing layer. So, if you are going to run your agent as like a Twitter account manager, you can sandbox it. It can't do everything it wants, but in its own memory, not modifying your system. Pi is super intelligent. If If you probably
tried Open Claw, I don't know how much you heard about like all the features it has. That it has connectors for OS providers, which are based on subscription. It supports like uh token keys. It's It's not easy to understand it. Even myself, I spent like I don't know, 1 hour to understand what even models it supports. Uh yeah, you will have a lot of models. And by
the way, all of these are generated by AI, and the data is coming from Pi SDK. So, it's just like a package. If you want to make your own agent, if you want to make your own operating system, you can just use Pi SDK. And uh well, it has all these features. It's just visualized well because I made a framework to visualize it for me. It has
its own settings. Like we have this also visual UIs and the great framework that uh will also visualize. But anyway, uh this is like the setup. So, if you start the system like with Pi Claw, you just have to connect your Um you can start chatting with it. Also, this is something simplified. Like multi like I see this multi-agent and my agent orchestrators, whatever whatever. Uh bottom
line is that we need some groups. We need some agents that are assigned to directories. Like it's They understand file system and bash. They don't understand anything else. Like don't overcomplicate it. Uh like I don't know, coding agent. Like I can ask it, "Hey, Open it in a terminal tab. Let's see what it does. Yeah, it can open a terminal tab itself Oh, it did something wrong.
Yeah. Fix it. It's thinking. Oh, cool. Now I can say, "Open it in Yeah, I think it can be stupid, to be But it could at least understand that it has to open it in browser. But let me show you the cool part. Like what is this opening browser? This is a tool I give it to it. Like I basically define it using Pi SDK also again.
Just this is how you open a browser for yourself. And uh like there is some uh like system for like it can send a message to the front end. Hey, this is how you can open a browser tab or whatever. But this is the whole concept. Like we have features for more things. Like it can send a notification. It can open a terminal tab. It can search
on the internet. These are just simple prompts and tools that you can just define for it. So, it's super simple with Pi SDK if you want to do it. Also, I didn't know how by the way how to do it. Just it taught me. And you can have like a reviewer agent. Uh you can give a soul to it. For example, you love Bun. Uh and review
code. So, you can make them a little bit biased. I think something is down. Yeah, this is what happens when you do it 4:00 in the morning. Yeah, I'm not going to work more than that, but uh the whole concept is that you can do it yourself. Uh it's super cool. I really recommend to read about it. And you can also build your applications using Electron. You
can make like deploy your Nuxt applications as a standalone macOS application with just 40 lines of code. It's like fully signed. It can has auto updates. It's like 20 MB bundled with Bun and everything. Uh Vue is super cool. Like uh this is only the Pi SDK. Like this is happening in the whole ecosystem. Like everything you do is like a black hole in node modules. But
let me just build this for Yeah. This 800 ms. Like every time I see it, I don't know if you can see here. It's in down. I'm super surprised. Like Look, uh it's 155 MB of bundle. And together with Nuxt smart configurations that like defines a chunking system. And with fast Vue 8 and Rollup, like the whole thing I don't know how much is it. It's 47
MB. It's not just Pi SDK. It's like the full front end, all the other libraries. It's less than a second. I probably like you have other projects that takes like minutes to build. This is how impressive the new stack is. And the new stack is just, you know, Vue plus Nuxt. Um thank you so much for your attention. and hope you enjoyed the match. >> [applause]
