The Weekly Dev's Brew

From Nuxt to Nitro: How One Engine Is Powering the Modern Web (w/ Alexander Lichter)

• Jan-Niklas Wortmann | Web Development Enthusiast & Podcast Host • Episode 6

Share episode

In this episode of The Weekly Dev’s Brew, we dive into the current state of web development with Alexander Lichter, a core member of Nuxt and DevRel at Void Zero. Join us as we discuss Nitro, the innovative server engine powering Nuxt and its growing influence on frameworks like SolidStart and Analog. Discover how Nitro is transforming fullstack JavaScript development, allowing for leaner and more adaptable backends. Our conversation also touches on Vite, modern server patterns, and the realities of working in open source and developer relations today. Gain valuable insights and behind-the-scenes stories from an expert shaping the tools we rely on in the modern web ecosystem. Whether you’re passionate about Nuxt, fullstack development, or just eager to know what’s next for server-side development experience (DX), this episode is packed with information worth exploring.

Our Fantastic Guest
Alexander Lichter
Alex is a Developer Relations Engineer at VoidZero, a Nuxt.js Team member, Web Engineering Consultant, and open-source enthusiast. He creates tech-focused video content, co-hosts the DejaVue Podcast, speaks at conferences, and leads workshops to empower developers and advance the web ecosystem.

Bluesky 
Youtube 
LinkedIn 
GitHub 
x (formerly twitter) 
twitch 

Chapters

00:00 - Intro
00:14 - The origin of Nitro
03:56 - How to use Nitro?
06:39 - Nitro hidden Gems
07:56 - Nitro under the hood
10:17 - runtime agnostic - a myth?
12:38 - Nitro Project Structure
14:58 - Nitro 3 and Nuxt 4?
16:58 - What's coming with Nitro 3
19:36 - Nitro and Vinxi?
22:24 - What's the Vite Environment API?
26:36 - Vite's out-of-the-box experience
29:05 - Cargo for JavaScript?
31:01 - Void 0, Rome & Biome?
32:37 - Void 0 and standards?
33:58 - OXC's part in Void 0 vision?
35:15 - How do developer benefit?
35:55 - Void 0 on formatting
37:46 - Oxlint and ESLint
40:44 - type checking vs type stripping
42:30 - On Rolldown
44:38 - Complexity of Compatibility
47:08 - Outro

Links and Resources
Podcast with Daniel 
Podcast with Patak 
Interview with Evan You   

Production support for this video was kindly provided by WebStorm. Thanks for helping bring this idea to life!

Thank you very much for listening!

We are also pretty much on all social media platforms, so make sure to like and subscribe!

Homepage - https://www.weeklybrew.dev/

BlueSky - https://bsky.app/profile/weeklybrew.dev
Instagram - https://www.instagram.com/weeklydevsbrew/
TikTok - https://www.tiktok.com/@weeklybrew.dev
YouTube - https://www.youtube.com/@theweeklydevsbrew
LinkedIn - https://linkedin.com/company/the-weekly-dev-s-brew

Welcome to another episode of the Weekly Dev's Brew. Today, I'm sitting here with Alexander Lichter , now DevRel at Void Zero. Correct. But also part of the Nuxt Core team. And you do like plenty of other stuff. Few things here and there. Yeah, yeah. So I'm very happy to talk to you about like particularly the server side of things today. We probably will also talk a little bit about Vite and stuff, but let's start with Nitro a little bit. So from my understanding, Nitro used to be the server engine that powered Nuxt primarily. These days are getting more and more adoption and other frameworks like TanStack Start, Solid Start, Analog is using it. So where is the idea of like, okay, let's centralize the server engine and take that out of Nuxt because I assume it was first part of Nuxt and then got extracted. Yeah, correct. So this all started like in Nuxt 2, everything was included in Nuxt itself. And that is not only related to Nitro, but also other parts that are now packages in the UnJS's ecosystem. Okay, it wasn't a core, but it had a lot of problems. Like it was hard to test. So people writing tests might know the problem. Like, yeah, ideally, it's a bit like the UNIX philosophy. You want to have a package that does one thing, it does very well, it's isolated, and of course, then you can reuse it. So even in Nuxt 2, Pooya, who is also like leading the Nitro team, the UnJS's initiative and so on, so on. He came up to the point like, we should maybe start extracting certain parts out of the core of Nuxt 2. So that happened in an organization that was called Nuxt Contrib, for contributors or contributions, however I want to name it. And then of course, when the rewrite happened, where I wasn't like eagerly involved, but like Daniel, Pooya, Sebastian, and Anthony as well, of course, then more and more opportunities popped up. And with Nuxt 2, there were a couple of issues, or like say shortcomings, because on the server side, you always had support to say, we could do things on the server, but it was all based on Connect. So like that, let's say, low level web framework, that's also like, let's say express, but even more bare bone. Okay. And there were ideas like maybe switch it out for something like Fastify, this, that, but there were a few challenges, especially as the web was evolving more and more. So there were issues like, okay, serverless was a big thing. And back then it was tricky to just say, let's wrap everything. Like there was a standalone mode was called introduced to say, okay, we have like an output and we can just ship it. But before it was very opaque to see what you actually need to deploy in terms of files. Like do you need all your node modules? Do you need certain parts? And it was a bit tricky. So there was a better solution needed. And now people could say like, why don't you reach out? Yeah. For like express, Koa, Fastify and so on, so on. Well, first of all, express now version five, great, but it is quite an old, battle test, but old framework, not quite bare bone. And the other part is of course, not only modernizing things, but now also considering runtimes, right? We don't only have node.js now like Deno, Bun, the whole, like, you know, the whole setup. The Cloudflare worker is also part of the deal where it's not only like node, but the subset. Now of compact mode, it's also a bit of a different story. But yeah, so it was not only saying, oh, yeah, you should work on serverless and we have to like optimize things for cold starts. Another thing that Nitro is doing. So there were quite some challenges and that's why, yeah, people started working on, back then was called Sigma. I did not know that. Yeah, not many people do. It's usually like when I do some like quizzes, I was like, this is super hard questions because how would people know it was like a code? I think Daniel mentioned like two times openly, so now people know. But it was called Sigma and then it was renamed to Nitro for whatever use. Like I can't tell you why, but it was renamed. It's also not a bad name. Yeah. So the thing that I'm wondering a little bit though is like, because I see usage of Nitro mostly in like those meta frameworks. Nuxt, TanStack start. Like having it extracted kind of implies that it's more useful also for other use cases and also for developers directly. How would I, like I'm developing my fancy server application. How can or should I leverage Nitro in that context? I mean, it always depends on what kind of framework you want to choose. Like nowadays you have a lot of options, right? Right. You have a lot of content around things like Express. So people could say like, okay, Express is the easiest option. I have like ecosystem things around that. You can also use H3. So here comes the tricky part of the whole UnJS ecosystem Nitro in. With all these packages, you have packages building on top of packages and you get this XKCD with dependencies, but we maintain things very well. So it should be fine. Don't debate that. Don't debate that. But, so basically if you take from like a, let's say a complexity level, Express then the equivalent would be, it's called H3. So this is basically the bare bone HTTP framework. Okay. It has no huge integrations that comes with a router. In the past it was called Redix, Redix 3 because it was a Redix tree. Now it's called Route 3 because not only Redix 3 anymore. And you can do a lot of things very bare bone, but Nitro shines because, well, once again, you can deploy it everywhere. So you have all the run times that's possible to do that without setting, I don't know, some weird adapter configs. A lot of things are zero config. So if you say I want to build a server app to come back to your question, you can say, okay, opt in for framework, but you can also choose Nitro. It has a compact layer for Express. You can still use all the things you would use with Express if you build for node, which is pretty amazing. And solve the problem of like, okay, there is like no huge ecosystem around it. Well, there's the solution. But it also has really good integrations for like storing files. Like we have a package called unstorage. So that basically it works as like a, let's say, KV layer, but it's basically you can write drivers for everything. There's even a driver for a GitHub repository or for like HTTP. But of course, Redis, Cloudflare KV store and so on, so on. So I have a lot of integrations in there. And there are a few more. We can come to that like WebSockets as well, where that's experimental though at the time of recording. So not all runtime supported because if you have things like Netlify over cell, where you don't have like long living processes, but like, okay, there's a function. It's spin, it's spun off. It starts, it's closes. WebSockets are a bit tricky. Yeah. But there is support for all of that. So ideally you choose a modern framework. It's super fast though benchmarks. Well, Pooya made a very good slide about that saying benchmarks don't really matter much because your API calls, they are like it calls the database as well. They probably will be ways lower than the framework itself. But still it's fast and it's modern. So I still try to wrap my brain So I still try to wrap my brain around the concept of Nitro a little bit. So maybe to help me understand it better, what is like a feature of Nitro that you like using yourself that's not getting like the attention that it deserves? I would say Nitro as a whole. Because I mean, I think of, so yeah, let me bend the question a little bit here. I think the biggest problem is, and I say that a lot recently, content. So like examples of what Nitro can do, which is also great while we're talking about that. So yeah, all the integrations from like, as I said, WebSockets having like unified KV storage layer to say, no matter where I deploy, I either have a provider that's ready to go and say, okay, if I set it up to, let's say I want to use the Cloudflare KV store, but my whole application should run Netlify, it's not a problem. Or if I have my own VPS and I need to have a Redis instance, you can all set it up without actually changing your code. Like the interface is always the same. You just have to configure your driver if it's necessary, like the Redis credentials. So this is super powerful because you can nicely separate, well, here's the configuration if you need it and the code itself. So like running everywhere where you can run JavaScript, in theory, even the browser, wherever you want to do it, but you could do it because this runtime agnostic is a huge feature nowadays that everybody is like, hey, there's no new runtime, let's go for it. How does that work under the hood? Because like, as you said, like Express for instance has those adapter concept that you need to use if you're like running it on Azure or something like that. If you say it's basically zero config, is that just by using more low level APIs and therefore being agnostic to all those platforms or how is that accomplished under the hood? Yeah, there are a couple of pieces here. So the first thing is we have something called presets. So there will be just an automatic detection setting, okay, if you deploy it and the CloudFlare environment is recognized, then there will be presets set. But there can be multiple presets for a provider. So let's say CloudFlare can be like pages or workers or like the workers in the module format. So you can also change that by setting an end variable or like even hardcoding the config. And the tricky part comes in when it's about, well, not only your code but libraries, right? So, yeah, not all libraries are runtime agnostic and certain runtimes don't support certain things. But another thing, another package in UnJS, I think you all there see the pattern slowly. It's called unenv. So basically what's happening there is that certain parts are polyfilled or just like proxy to do nothing to make sure things don't break. You maybe can't use certain functionalities or they're a little bit different. But at least your application won't break. And of course, we try to keep it as close as possible to what's actually happening. And also, this is one of the packages that, for example, CloudFlare itself uses in Worker D to make things happen for, I think, Node Compact. Don't quote me on that, but it's definitely used in other projects, which once again goes towards the whole like UnJS philosophy. We're like, we have a lot of 428 can use in their projects. Not only saying you need Nitro or H3, we have another package called UFO for handling, well, strings, let's say, in particular URLs. So, URL handling with like trailing slash, no trailing slash, query, no query, and worst. It is, yeah, exactly. It's a pain. And that came also back in times from, we had this handling in the Nuxt core, which would be great to have that separately. And then it happened, and people use it in all kinds of projects, also in normal applications. And ideally, you even have a framework using that already, so you don't even blow up your bundle. I feel like you're plugging Nuxt there. Just, I don't know why, but. I didn't, you said that, you said that. I did. So, one thing I'm still wondering, because when I try to develop code, I try to, implement it as runtime agnostic as possible. But the way you talk about it sounds like, even though this is overall a goal, it's somewhat unrealistic. So, how does this comply with the approach of Nitro to deploy anywhere, because it's runtime agnostic, but the runtimes are not that, they are very different in that sense? Yeah, it depends a lot on, so, it depends. Nice answer. Great. Thanks. Thank you. You can stop here. Perfect. That was great. Now, I think the code you write is usually not the problem. If you are aware. I wouldn't say that. Okay. For being runtime agnostic. For everything else, no guarantee. That's true. But if you use the capabilities of Nitro, that's, it's easier to achieve. So, one easy example is, that I see very often, is people use Nitro, no matter as a part of a meta framework or not, and then, it's about, I have a file, I want to read or write something to the file system. So, what you do with node, fs.read whatsoever. Great. If you now deploy somewhere else, it might not work anymore, because maybe there is no file system. That's a problem. So, yes, in a way, you have to keep in mind that there are a lot of options. If you say, I only want to build a node, then you don't need the runtime agnostic part. That's also cool. But, there is, as I mentioned, un-storage, for example. So, it also has a file system adapter. So, if you use an even composable Nitro called use storage, which is an integration, and you can configure that. You can say, there are also server assets by default, but I can put your server things in there, save there. So, that will just work anywhere, if you do that. The only problem also there is, you have to be a bit mindful about where it deploys. So, if you say, okay, I deploy to, I don't know, some server's functions, yeah, maybe reading and writing file system-wise, except for, like, temporary files, might not be a good idea, because you might need, like, a global storage, and that's not the case. So, let's say Nitro doesn't solve the problem that you don't have to think about your architecture or, like, where to deploy anymore, but it makes it way easier to switch over, because you didn't say, it's not a file system, it's a different storage, and your code stays the same. Okay. I also like to take a moment to talk a little bit about, like, because Nitro is a pretty big open source project by now, with, like, having massive dependencies from, like, a TanStack start, Nuxt Yeah, analog, solid start, more to come, I hope, yeah, yeah. How is the project itself organized? How does that work behind the scenes? Okay. There, important disclaimer that I didn't start with, which is always great. So, I'm contributing, I'm, like, a part of the ArtisNitro team, so to say, but, of course, as I said before, Pooya is the main leader. Okay. Organization-wise, it, I would say, there is no, like, hard structure as in, like, oh, that person is responsible for this. In the end, Pooya is responsible for everything. Mm-hmm. And he has, I think he has a really good vision when it comes to, like, what API, like, how do APIs work well? Maybe where to, where to go, especially down Nitro 3, maybe it's already out when the podcast is airing, maybe not. Like, where this is going. I know a lot of people, especially the Nuxt fans, are waiting for that. And the problem, of course, with this is also, like, breaking changes with other packages, and you have to, once again, you have to start in the very low level to refactor things, to improve things, to take the chance to put them up, do that the same major version, and again, and again, to end up in Nitro. That is not always the case, but if there is the chance, then that might be a good option. But, yeah, organization-wise, there are a lot of people helping with a lot of different parts. There are, like, regular contributors. There is, I would say, not a, like, clear team structure in that way. Okay. But I also think, and I think I talked with, like, Michael and Daniel in another podcast about that as well, where there is a huge chance if the whole, like, organization and the content part is, say, more in focus, which will work better after the next major version, because that's the focus at the moment. If there is more about that, then I think more and more people will realize how good Nitro is, and we'll try it out. For example, the other frameworks out there, right? Hono, for example, is super popular at the moment. Yeah. It's not a bad framework at all, and it's a good choice because you can do, build amazing things with that. Like, I'm not a big fan of framework wars, even though I wear a view into it. Anyway. No, I'm, you can fully do this. But on the other hand, like, having something runtime agnostic is a big bonus, and I think just people don't know about it. So, you mentioned Nitro 3, and I talked to Daniel about Nuxt 4, I think, probably in June last year. Oh, yeah. I talk with him regularly about it. Yeah, I bet. Daniel Roe, the lead of the Nuxt. Yes. Yeah. So, what is happening with Nitro 3? It's in development. Okay. Yeah. So, the TLDR is basically what I mentioned with, like, the package, let's say, dependency pyramid, like, you have to do a lot of work under the hood, start refactoring there, integrating this. We all know there are a lot of difficulties when it comes to software development, like, in hard parts, like, yeah, the old joke with, like, yeah, cache validation, naming things, all by one arrows. But, well, estimation is also not really a strength of most developers. I've heard that before, yeah. I want to not exclude myself there either, right? And the problem is, as well, with the responsibilities there, like, oh, if you at some point realize I need to, let's say, rethink some parts of an architecture or what's happening now with which, let's say, which structure do we use? And Node has, like, request response, right? Mm-hmm. But now we go a lot of that, like, the more, like, fetch-like structure that also, like, workers use and so on and so on. And then think, okay, what makes sense to bring the web ecosystem, like, further into the right direction? That also takes time, unfortunately. And to talk about that, I also, I asked Daniel the same, like, I even said, look, if you could go back to, like, Daniel last year and say, like, hey, I'm from the future. Daniel, Nitro will take a while. He said, like, he would push the button straight away and release Nuxt 4 back then. So, yeah, it is difficult, but the problem is it wouldn't really help to release, like, something half-baked or then people have to migrate and then maybe very soon again. That's, yeah, that's difficult. But from a user perspective, what's the exciting thing about Nitro 3? Well, user, I mean developers, right? Yeah, good, good. I think the key part is that things will get a little bit more ergonomic. Okay, that's good. I would say also that's very important. It's the same as with Nuxt 4. Major versions shouldn't be exciting. Like, this is not a hype version as in, like, they're breaking changes. You might have to fix things. We even keep things backwards compatible. The only thing is if you use, like, event.node, then you request a response that won't be polyfilled anywhere else anymore. So, you have to rely on, well, the actual internal ways of fetching things. If you manipulate directly, that might be a bit tricky. But ideally, you would do that already. So, it's more like, hey. Anyway. Yeah, I think the most exciting thing, personally, for me is that there is more room for more minor versions. Even Nitro 2 got another minor release, right, while working on Nitro v3. We have a lot of changes. I'm also looking forward to see another package being created, which is the caching layer we have right now. Because Nitro is really good at, like, okay, you can do state-wide revalidating on the server. You can have, you can cache certain parts of your, either the whole, like, request handler, so to say. It's called event handler in Nitro. But you can also say, I cache a function. So, like, a smaller part of that, to don't say, let's say you need a user authentication, don't want to cache that. But there is something that's fetched anyway in that request. I can just make a defined cached function out of that and fetch that and it's cached. And you can decide where to save it. So, it uses storage from unstorage to put it somewhere else. That's right now built into Nitro directly. But the plan is also to extract that. Because once again, it will be easier to test. It will make sure it's less buggy, possibly. Not saying it's buggy right now, but there are always edge cases. Caching is difficult. Yeah. So, I'm looking forward to that, for sure. Yeah, also, Nuxt 4 is another big part there, too. But right now, I really think, like, if you feel, oh, should I wait for Nitro v3 or just start using it. Like, nobody stops you, really, from, like, building your product just because there will be a major version coming. That's true. There might be offered to migrate, but you still can ship something. And this is the same for a lot of scenarios where, like, don't wait. Just get going. Maybe the product you're building, nobody cares. Nobody wants to buy it. That would be sad. Sorry out there if that's the case. But it's still better to know that then, like, in a month or so than, like, waiting and then you know it in a year. Bit of wasted time. Yeah. So, one thing I'm wondering, because I think TanStack and SolidStart both went this route of saying, okay, we're not using Nitro and Vite straight away, but they used a separate package, Vinxi, which kind of was like a combination of two of them. But both now also circled back and used the Vite environment API and Nitro. So, can you talk us through that a little bit? Sure. From, like, my perspective, those are technical implementation details that I didn't care enough to look deep into. But it seemed to be important enough that people that are way smarter than I am said this might be a good idea. Yeah. In a way, it's interesting. As you said, Nitro came from being like a server engine to say, okay, you can use it out there. And it was and is a good fit for, like, analog, TanStack start, SolidStart. But, of course, they have different requirements with, like, okay, what's with server functions? How do certain parts should look like in the, let's say, React world or in the mindset of the people like of Tanner, Ryan, and the team as well? Then also saying, okay, yeah, there was no Vite environment API back then. So, Nikhil created Vinxi, like a layer on top of Nitro that's, let's say, the idea was to be not opinionated, but you, in a way, it is opinionated by wrapping the whole thing and doing something on top of it. Ideally, the goal, at least from my perspective, was always that this wouldn't be necessary because Nitro should either have all these, like, needs fulfilled already in a way. Or in this case, with Vite's environment API, it's a bit easier. So, Vinxi was a layer on top of Nitro that, yeah, wraps it and makes sure you can create, let's say, different, they call it like routers. So, let's say environments for different parts of the application. And that was used heavily because it worked out pretty well. Nikhil also, like, from the Solid team worked on that for a while. On the other hand, of course, then, then Pooya, on the Nitro side, we're looking to, okay, what is it that we need to do so we can fulfill their needs while still going the right directions? Not just saying, okay, we just build the same in Nitro, but how can we solve it while still keeping, well, the architecture, the paradigm, and the way that we think, or especially Pooya thinks it's the right way. It's his vision after all. Of course, discussing that also very closely with the people. And now with Vite and the environment API, it's a bit like you don't need that layer in between anymore if you have the connection between Nitro and Vite a bit nicer, which will also come, which is also another reason why Nitro V3 takes a bit long, because tighter integration with Vite and the ENV API would be really nice. Yeah. So, that's also something that's work in progress. So, I think, if I remember that correctly, the environment API for Vite came out with Vite 6. Yes. And the release blog post said something like, oh, this is for framework maintainers. It's pretty exciting. We're super hyped about it. But there were, like, hardly any details of what it is, why it's there, what it does. So, can you help me understand it better? Or help it understand it at all? Yeah, no. Okay, so you don't have more information than I do. I do, because actually, I was talking with Patak, so with Matthias, from the Vite team, who actually also explained it very nicely. I might just delegate people there. I will talk to him too, so I will. Perfect. Then, like, watch the episode. Watch the episode of Patak. I'll ask the same question. And if it's not out there yet, then watch the Deja Vue episode of Patak. No, but to summarize it real quick, the idea was, and please, there might be some more nuanced details that Patak can summarize nicely. But there was always in Vite, there were two environments, server and client. And then what if you say, okay, Cloudflare workers, nice example. I want to run my dev server in a similar environment like Cloudflare worker, like MiniFlare. How to say I want to run part of it only in that. Like, a certain part should run in a worker. Otherwise, the rest is just a client application. It's difficult. So, with the environment API, you would now have not just two environments, but multiple ones. And then, framework authors can use them for whatever they want. So, they say, like, hey, this part is client only. This part should go there. So, that and especially with like, TanStack start and Tan stack router where everything is very focused on the router. Yeah. It's great that you have that granular freedom now. So, coming back to Vinxi as well. Tanner and Ryan both said in the end, okay, not only that Nikhil focused on other parts and Vinxi is not super up to date anymore. It's also not necessarily needed, thanks to Vite implementing the environment API and also Nitro pushing forward and enabling certain things. So, in a way, it feels a bit like the typical community and standard thing where like, here's a community solution ahead of time. And then, showing this is needed or like, this is somehow something people want to accomplish. Not just like a few people, but like bigger frameworks and a multitude of them. Let's find a way to do that and get rid of another extra layer. Okay. It helped me understand it a lot better and now it also makes sense in a way of why the release block post said developers don't need to care about it as much. Yeah. And also, the two environments before, like they still work. So, it's also backwards compatible. Right. Yeah. But that's always, I think that's a super tricky part where like, it is exciting for the people building the tools. Yeah. And, but yeah, for developers like, okay, nothing changed for me. So, I want to talk about that with you a little bit because as DevRel for Void 0, you have some involvement with Vite and the whole tool set in that. So, how do you balance like, building excitement for the people that use the tools and the people that build on top of it? Because those are like, fundamentally different target groups. Absolutely. And also here, important disclaimer, it's my third day as DevRel of Void 0 officially. But, like, I am involved with like, these projects and interest in them for a while. I mean, I haven't like, interviewed Evan in Japan, the conference about that where like, when he announced the company and so on, so on. But, it's difficult as you said, they are two different groups. So, it means also, you have to target them differently. Yes. So, in a way, what my personal goal would be is, for the average web developer, make them understand why, what Vite is. Yeah. Like, this is the first thing. Like, people say, hey, Vite is fast, it's better than Vite pack, this, that. But, what is it? So, ideally try to like, bridge the gap, like, be the glue between the people building the things. Yeah. That can be people at void zero, so they're working on a roll down, OXC. Also, come to that probably. Yeah. If you haven't heard of them, then perfect time. Yes. Let's talk about that. And, of course, the developers either, and they say to target groups, either want to build on top of them, and want to understand some internals, how certain things work there. But, also, the average web developer saying, yeah, okay, that's cool, my framework might use that, great, but what else could it offer? Or like, is there anything else? Do you think in a way, because the way that I like to talk about, or to think about those tools, particularly bundling, I like them to work. Mm-hm. I like them to work out of the box very efficiently. Mm-hm. And, I probably got burned out by Webpack too much, so I'm like, okay, I don't even want to remotely touch those things at all. Mm-hm. Because I'll probably just make things worse at this point. Yeah. So, very burned out on that. I get that. I get that. So, how is that for Vite? I mean, the configuration is a lot more straightforward and everything. Yeah. But is that a goal that like this out of the box, because Vitest, for instance, has a great out of the box experience. Basically, as long as you have Vite config, it just works. Exactly. And you don't even need a Vite config, but that's a different conversation. True that. So, how much of that focus do you put on this target group like me, don't care about bundling as long as it works? Mm-hm. Or really the people that like to tinker with it. And also, if we talk about like FAANG level companies, those need to tinker with it to have that level of control that they really want. Yeah. Good point. But I think also there, Matthias also said it recently, which stuck really in my head and it's completely true. If you just use it and you don't even like see Vite somewhere, like feel like, okay, it just works, that's how it should be. Yes. Like that's the best compliment in the way you could do. Because you don't want to mess around with things. You just want to feature ship things, build stuff, especially if you start. It's getting of course trickier if you either say, as you said, like your enterprise level or like you start with things like, okay, I have all these different tools that I integrated and now my build pipeline is slow. So, there are a lot of things that you can optimize. So, say like, I don't know what Vite plugins do I maybe use because there is a Vite plugin that does that, this here. The bundle optimization is also a thing. And ideally at some point Vite can help with all of them. And maybe even without saying, yeah, I need different tools, right? Yeah. So, right now you still have to like in a way get all the things together and plug them in. And also at Void Zero, of course, the idea is that the unified JavaScript tool chain in the big picture. So, let's have that all included. Okay. Like the cargo for JavaScript, I think it's a nice term of people in the Rust ecosystem like, oh yeah, the cargo is doing everything. And maybe that's a goal we can achieve in JavaScript too. So, my Rust experience is basically nonexistent. Okay. So, cargo doesn't ring a bell for me. Like, help me understand this better. Yeah. So, think about like in Rust if you say like, I don't know, you can build stuff, you can run stuff, you can lint stuff, format stuff. Everything works with that command. So, it's like, I don't know, cargo build, cargo format, whatsoever. So, don't say I need ESLint, I need prettier, I need, I grab that stuff. It's all integrated. And under the hood, now we also come to the JavaScript part again. It would be great if all the tools you use are not only just there together, but they all use the same tool chain. Because right now, you have the big problem. A lot of times, you have every single file that might be parsed and transformed multiple times. So, because maybe people still use Babel or like, we see or whatsoever, and touching things to transform them. Then there's another part running through that. So, if you have a unified tool chain, you can do it all in one go. And that's also no pun here because a lot of the toolings like that will come to Vite eventually with Rolldown, you see it written in Rust, coming also back to that in a little bit. So, it's not only speed, it's also efficiency in a way. And yeah, ideally that means you get crazy speed ups. And ideally, it would be for free because right now, so Vite is using ESBuild in Dev Mode, right? So, that's based on Go. And in Build, they use Rollup, right? So, as a bundler. The choice, well, speed, of course, is one big thing. And being in that unbundled mode, so you basically do the things on the fly and things to go like the native performance that works well. At some point, there will be rolldown. So, a new Rust-based bundler. I mean, people at Void Zero are working for quite a while. I think Evan knows that it's been a little bit. But it's making such a good progress. So, ideally, that Rust-based bundler will just replace both parts. It does sound very similar to that vision of Rome and Biome. Yeah. I asked Evan the same question back then. And it's, yeah, correct. So, what was the answer? Well, the thing is, obviously, like, Void Zero is not the first company trying this. I really think they're the first company that will succeed at doing that, though. I've. I think it's a good thing. So, let's think about that. Adoption. Right? You always have the zero to one problem if you look outside of tech anywhere. Like, okay, we need a critical mass and then we can do certain things. Yeah. Every framework out there is using Vite except Next.js or the people in the React Land that don't like Vite, which is also fine. You don't have to use it. And there's also like RSPack as well, for example. Right, but there's already a pretty broad user base. Exactly. Exactly. So, if you say, okay, look, we want to unify toolchain. Vite is a certain part of that because the adoption, it's just there already. Yeah. Right? So, it will be way easier than saying people, hey, here's a shiny new tool, switch to that. So, for example, of Rolldown, what the plan is at the moment is there will be an extra package release in the future. It's called Rolldown Vite. Mm-hm. And what you can do is just like alias it and it will work. Or then in the future again, maybe just an end variable saying, okay, and that's the better part once again for the whole toolchain. You set an end variable and everywhere in your whole toolchain where Rolldown could be used as a bundler, it will be used. So, everything in your whole CI will then just switch to it if it's possible. So, you mentioned that it's trying to accomplish like a standardized toolchain. How involved are you with like standard forums and like TC39 or something? Is that something that is on the horizon in a way where it's like makes sense to talk to them to like establish or like share that vision of like a standardized toolchain? Yeah. So, Boschen who is working on OXC a lot. So, on the Rust based tools for JavaScript like the transformer, parser, formator, minifier. He's an invited expert at the TC39. Cool. So, he is definitely deeply involved in that. And it always like, the goal is also to like leave no one behind. The goal is to stay in touch with all the framework and library authors with all parts of the ecosystem. And for example, Evan, well obviously with Vite, he's in contact with all the people using Vite, all the framework authors as well. So, that is easier. With the TC39, especially in the lower levels, it's also great to have people being in regular talks. And the other part of the equation is the developers, which you also mentioned in the beginning. So, that will be the part that I cover in a way. What mostly Evan did at the moment with like sharing things. And I also want to make sure that he can spend his time on other amazing things and cover that more. But yeah, that's the idea to make sure we can have the whole ecosystem on board. Yeah. Sorry, my head is still spinning a little bit because you're, we now went from Vite to rolldown to OXC. How, what's the OXC role in that? Yeah. So, as I said, OXC is that like, it's a collection of tools. So, it's like Formatter, Parser, Transformer, Linter, Minifier, which, well, allows to say, okay, if there are tools that want to use, not the whole bundler, sometimes it's like, okay, I want, let's say, I want to parse something and then do whatever operation, don't need to do to bundle. That can be frameworks. So, for example, or like things like Vitest as well. They can integrate certain parts of that. So, if I only need to parse or Transformer, that's great. If I need only Minifier, awesome. Or in case of the Linter or OXLint, you can use OXLint already. There are a lot of rules that just work out of the box where you say, okay, I maybe have rules that are not available in OXLint yet. I use ESLint for that. For the rest, for the speed up, I use OXLint. And it is incredibly fast. I've like retweeted a few posts, people being like, it's not just like a 10x. It's very more than that. And especially for the big enterprise level applications, that's a huge boost in terms of time productivity. Because linting is slow. Is that set of toolchain then basically intended for like plugins mostly? Or how would I as a developer, other than like the linting aspect? The linting is fairly easy to grab. That's something you just use, exactly. Otherwise, it's of course a lot for people building libraries or frameworks to say, we use these parts under the hood either for their build processes or, of course, if you have like rolldown, sure, that's then integrated. As like, I think the average developer building like an application, besides like of course linting, formatting, tools are used under the hood, ideally. So you benefit from the integration speed wise, obviously. But you also benefit that maybe the frameworks integrate that so you don't see it. The formatting aspect is kind of interesting because formatting is severely complex task in a way. I mean, if I just look at like the different syntaxes that we have between Vue and Angular. Like parsing them and then like making sure they are formatted correctly is very different thing. Is, and I mean Prettier use or is the basic standard for that in the industry for that. Is there an attempt to be like replacing Prettier by being compliant or like? Yeah, formatting is complex and I also have to mention the focus is JavaScript, first of all. So that's also, for example, to quickly go to the linting part, I'll come back to the formatting in a second. People were for example asking as someone from the Vue universe or like also Svelte, like what's with the template of a Vue component? Right now the focus is on the script part. Okay. So there is no, let's say, way to lint the template with all excellence at the moment. Which is fine given the scope. Yeah. But there are ways in the future that we have in mind to try out. We didn't like settle on any of these to make sure, okay, maybe there are just ways to like, we support JSX for example. Okay. And someone once said this is a blessing for tools. JSX is heavily underrated. Yeah, I heard it multiple times when we were talking. And maybe there's, for example, a way to say, okay, you don't have to reimplement Svelte or Vue compiler. You could just say, let's take the component template and like lexically transform it. So you make sure, okay, we have not the functionality, but just like, we can transform it to JSX, do some mappings on that and like, do the transformations and port it back. Do you think there is, because if I look at Vue ESLint for instance, there are linting rules for the template. Correct. Yes. Do you think it is reasonable to say at the moment, kind of like you do like unit and integration tests, a separate process because they have like different complexity and different, they run way longer. Do you think there is a space to say, okay, we run OXC Lint for the script part and then ESLint for the template part? Is that something that you would do yourself? Yeah, absolutely. So this is actually when you start creating a Vue application. So if you say PMPM create Vue or whatever package manager, it doesn't matter. Then you have a little wizard with like, do you want to use TypeScript, this, that, and you also asked for ESLint or like, do you want to use linting? And you can say no, yes ESLint or yes, but make it even faster with OXLint. So you can already do exactly that to say all the rules that are supported and we have, I think, 500 plus rules supported right now from the most popular ESLint rule sets. They work, but everything that's out of scope at the moment or like that we didn't settle on, yeah, just use ESLint for that. You still get a big speed boost. Yeah. If you have a Hello World application, it won't matter. If you have a, so that's always the interesting part where like the enterprise part comes in, right? If you have like thousands of components, this will really cut down your time, make you more productive. CI numbers will go down so you don't have to wait that long. And also, well, it's built by the runtime, so it's also a bit cheaper. And like there are companies, for example, like Framer also uses Rolldown now. Like Shopify was also like reporting like how much time was basically cut, not only in half, like magnitudes. And seeing that is amazing because it means more productivity for developers. You tease it in a way, but you are very vague about it. So right now the focus and the scope is scripts. But is there an ambition to say, okay, let's integrate the view compiler to parse a template. Let's integrate this file compiler to, because then you would also leave the Rust runtime and lose some of those speed gains again, depending on how the compilers are written. But usually they are written in JavaScript. I will not say never ever, obviously. As I said, we didn't settle on these parts because the focus is JavaScript. And as I mentioned, ideally, if we don't have to like say we reinvent the compiler, we just use the JavaScript compiler there that's existing. If we can just transform the components to JSX and make the transformations that we can do already, or the checks in terms of linting, and then just say we map it back. That would be a very, let's say, elegant way to solve that. But also there, time will tell. Okay. Because it's like void zero is, of course, not huge in terms of people. So we have to see what to focus on. And JavaScript is the, and TypeScript is the obvious choice. In terms of TypeScript as well, we don't do TypeScript like type checking, right? And with TypeScript and Go, I think that's got a speed out now as well. So really happy to see that too. But having that said, does that mean then, because I mean, in Vue and all those applications, you write TypeScript. So are you still doing the type stripping aspect during the building? Kind of like you do in Node these days. Is that more the vision or is it rather that you would basically run TSC and then the whole tool chain aspect of void zero then works just on the JavaScript aspect? Because then it wouldn't be like super standardized because then you would still rely on TSC in a way. Yeah, we don't want to do type checking, right? So type checking is only for TSC. What is, of course, more interesting is the whole topic of type aware linting, right? But it is, I think, Oxidase is one of the projects, which is built on the OXC tool chain. And for example, does type stripping. Okay. So there are ways to definitely do that. So you're still basically doing the transformation from TypeScript to JavaScript and then doing the whole tool chain aspect of things on top of that. You just don't want to be involved with type checking right now. Yeah, just because type checking, it doesn't make sense. The type checking, that's up for a TypeScript team and nobody can like catch up with the speedest moving target. Yes. I really hope though that's also something that with that Go rewrite and TypeScript. Yes. There will be a few things that are a bit more well defined. Yeah. So that would be great to use that chance to maybe, yeah, have maybe a good plugin API for TypeScript. That would be great. That would be great. That's true. So is there anything, because I mean void zero is still very new. Like I think Evan announced it probably roughly a year ago. October even less. Yeah. Time flies. Yeah, man. Is there anything that JavaScript developer as a whole, doesn't matter what framework you use, should be particularly excited about coming in a grasp near future? Well, a lot of things, right? I mean, rolldown is, I think it's the thing people could just be excited because it's ideally, the idea once again, drop and replacement, things will just work. Using Vite anyway, that's amazing. That's it. Right now, a lot of libraries and frameworks also try to use the OXC tool chain to make, let's say, their own build process a bit easier, but as soon or like easier, faster as well. And when that lands in the user land, thanks to things to roll down, that will have a great impact. I think the other thing people can be really excited about is, and this is a little sidetrack, but the whole E18E project, so the ecosystem cleanup topic. I think there, it will be really good to see how the community can also help. So let's say, as I said, roll down is kind of compatible with roll up, right? So you can use your roll up plugins as before. The problem is, they're JavaScript, right? So that means, how to not lose speed benefits with these. And the idea is that we also want to, maybe it's already out there, so then it will be linked. We want to make sure that we give a little bit of guidance there, and maybe more than a little bit of like, explaining how can you make roll up plugins roll down friendly to make sure they're giving that certain speed boost. Because obviously, if you have to do JavaScript for a longer runtime, then the Rust benefits are like, getting smaller and smaller. So, if there is a way to say, let's say, you know exactly how to efficiently call these plugins, and not for every single change, but maybe you have like a regex whatsoever. So we'll give a bit of guidance there, to make sure that they cannot be used, they're efficient. So, also there, the whole community aspect of like, everybody working together to like, going towards the goal. And once again, it's framework and runtime agnostic. So we also have the double agnostic part there, that would be exciting. So you mentioned that roll down is going to be compatible or a drop in replacement for the use of roll up right now in Vite. Correct. How complex is that from an engineering perspective? Because you have the completely different runtime with Rust versus JavaScript, but you still have that target of like, okay, we want to be a drop in replacement. Yeah. Like an engineering side, that's, those are very big constraints. Yeah. And I mean, not only that, because as I mentioned before, you have roll up and ESBuild being used. Yes. And that's also not the case anymore. And then also roll down implements its own HMR as well, like provides a way to do that, which means Vite can leverage that for the dev server, which might make things even faster. And then other things on the roadmap, like for example, a problem with, with roll up, and let's say limitation is fine-grained chunk control. So to say what code ends up where and how to customize it even further than it's possible. Like you can do it a little bit, but Webpack was really good at that. Yeah. It is not only, yeah, that like feature parity because okay, you have tests. Yeah. Sure. It's also API wise, like, because it's not just like, here's a port one on one. You also want to make sure you, you fit, like you find a good API that's ergonomic. Yeah. It should be fast as well. And then more features. But also that's why like all the people on, on void zero, working on these projects, they're like, they're like just such, like such good engineers. Mm-hm. Not only clever, but also like working super hard on that. They're diving like really into all the low level parts and also contributors out there. That because there are of course, like people interest that if you are also, please come by the discord and let's get in touch. Because like, it's, it's just the sheer, like, yeah, the sheer intelligence and the willpower of these engineers. So kudos to them. And it is difficult for sure. But also the progress that Roldan has made from its announcement to now, people might feel like, oh yeah, maybe in a couple of years, right? Like things usually evolve slower. But also thanks to Void Zero, they can work full time on that. And that makes a huge difference. So it's difficult, definitely. But also seeing the progress right now, I'm super excited what will happen in the rest of 2025. That will be great. And whatever is coming next. Sweet. All right. Thank you so much for joining me. Really appreciate you. Of course. I would be, I'm pretty sure we'll talk again about all the things Void Zero is working on. More than sure. Can't wait for that. Thank you. Thanks for having me.