Creator of Vite: Evan You

Welcome to Syntax. Today we have the Goat, the man who has made web development easier for the entire world. Probably kept people in the career before they had Rage Kit. We have Evan Yu on, he's a creator of Vue, creator of Vite, which probably everybody listening to this podcast has used many, many times, and it probably powers many of your businesses. So stoked to have him on. Welcome, Evan. Thanks for coming on. Yeah, excited to be here. So, real quick, before we get into it, for the six people who haven't done it, give us an introduction of who you are and what you do and kind of your background. Sure, yeah. So I had been a independent open source developer for over a decade, like since 2015/ish. Two years ago, I founded a company called Voice Zero, which is centered, you know, with the. With the mission to build open source toolchains for JavaScript. Yeah, before that I created Vue Vite. Probably some people use it, some people know it, but yeah, now I'm mostly focusing on Void zero and the Feed side of things. Awesome. I I think one of the interesting things for me was that you were primarily known as like a framework author. Prior to Vite. Did you see yourself making that change from working on the UI code to toolchain? Not really. So I would say a lot of the decisions of like, what do I do next? Just kind of. I never really planned it ahead of time. Like, before I started even doing JavaScript development, I thought I was going to be a designer. I wanted to be a designer. And then after I designed some stuff, I was like, I want to actually build it, but I couldn't find anyone to build it for me, so I had to learn how to build it myself and somehow got more into actually building stuff. And then as I build stuff, I'm like, these tools kind of, you know, it's kind of clunky. What about I build a framework for myself and as I build frameworks, I just kind of dig dug deeper and deeper. It's a wormhole. You just kept solving the problems that you had until one day you wake up and you're writing low level Rust to solve all your problems. And this might be a weird comment, but there's something about the aesthetic of not just the visual aesthetic, but the things that you make that makes it kind of obvious that you wanted to be a designer. Vue is a beautiful looking JavaScript framework, right? Yeah. It's hard to describe many JavaScript frameworks as looking nice just in a code context, but I wonder how much of that is informed Just by your aesthetic awareness. It definitely played a role because I think I probably put more effort into the documentation than the average developer who made frameworks. So that probably helped with. Definitely helped with the initial adoption of Vue. We were asking that when we had Daniel from Nuxt on. We're just like, why is everything in this whole Vue Vite kind of associated ecosystem, why is everything so polished and so simple and even to extend it, the API design as well is really, really simple. So I'm curious if you have any core philosophies as to just designing stuff in general, whether it's what it looks like or what the API design looks like. Yeah, I think, interestingly, because I initially got into web development from a non engineering background, a lot of people probably know that when I started to work on Vue, I was working at Google and worked on some projects that used Angular. And I could tell that Angular was created by someone very engineering minded and it came with a lot of concepts and like terminology to me back then was like, why do I even need to know this when I just want to put some interactive stuff on the webpage, Right? So in a way, this, like not having prior experience in serious engineering actually allow me to just focus on the minimal subset of things that I really cared about, like what is the simplest API that I can design for myself to do what I want to do. And turns out that probably aligns with a lot of people who come into web development from other backgrounds too. Because one thing I found interesting is web development is it's a very big tent. There are people building different kind of things, people coming from different backgrounds, and I think, you know, the simplicity and just focus on doing something with the easiest way possible probably echoed with a lot of people. Yeah, I agree with that. But like, if I were to go off and maybe create Vite, like I feel like I know the entire Vite API. You know, I've built several lower level plugins in it. I've built very complex, like I've migrated old apps that were in parcel and webpack and brought it into one. And I use the WebSocket proxy API. I feel like I know the entire Vite API, but I don't know that I could design something so simple and beautiful. And also just like upgrading from major version to major version, there's never really any major thrashing changes. It's just like, oh, the new version's out. Stoked to have it. Yeah. Funny story. We made the biggest breaking change between Vite1 and V2. Because if, if you followed along the early days of Vite, like we came all, we went all the way to like 1.0 RC. Among the initial design based on the first prototype I made. So here I gotta give credits to two people. Jason Miller, Rich Harris. Because Rich was the original author of Rollup, which a lot of the Vite plugging API is based on top of. And Vite1 did not have a plugging system. The view logic in Vite one was like hard coded. It was around that time I started to think about like production build. We were using Rollup, so we were using roll up plugins. I was like, can we make the roll up plugins work for the dev server too? And then I found out Jason Miller actually did it in his project called wmr. He did this roll up plugin simulator that is able to just run roll up plugins without actually running Rollup itself. So that inspired me to essentially say, okay, let's use this for Vite so we can have the same plugin system for the dev server and the production build. I had to rewrite the whole thing and that became Vite 2. So we never actually shipped Vite 1. Oh, and if you want to see all of the errors in your application, you'll want to check out sentry@sentry IO forward slash syntax. You don't want a production application out there that, well, you have no visibility into in case something is blowing up and you might not even know it. So head on over to Sentry IO syntax again. We've been using this tool for a long time and it totally rules. All right, let's talk a little bit about the whole roll up and roll down and how that works. So like, like Vite is built on top of another tool and then you have recently rewritten that tool. Yep. So it's no longer technique a rewrite. Because originally the name is Rolledown. Because we're like, okay, this is going to be a roll port. We're just going to straight up port it. Yeah. Turns out Rust works very differently from JavaScript. So a port is like, you can never straightforwardly port dynamic JavaScript code to Rust. Right. So we ended up actually going with an architecture that's more similar to esBuild than rollup. And the feature scope also is more like ESBUILD than rollup. So Rollup itself, the core, is very lean. It relied mostly on plugging. So let's say if you want to do Resolve Node modules, if you want to transpile TypeScript or JSX you all need plugins, right? EsBuild kind of just does all of this out of the box. You don't need to use a plugin just to transpile TypeScript. So Rowdown is essentially implemented in Rust. A lot of stuff work out of the box. TypeScript, JSX, node module resolving. But the API is rollups, so we support roll up plugins. It's a Rust bundler, but we support JavaScript plugins. So if you have a rollup plugin that's written in JavaScript, it will actually just work in Rola. How does that work? It relies on something called a project called napirus. So Node JS has this thing called NAPI that allows you to basically do cross language calls. Native API, right? That's what the N is. Yeah. Yeah. So napiers is a project that aims to make it easier for you to write some Rust code and automatically generate the binding so you can call the rust code from JavaScript and vice versa. Okay, we had the TypeScript folks on and so we have to ask this question of why didn't you use go versus rust? And the reason the TypeScript folks gave us is because it's much easier to port JavaScript to go because they're literally just going function by function, rewriting the entire thing. But you said, you just said it's not the same with Rust, so why didn't you pick Go for that? Yeah, so there are a few pretty practical reasons. Right, Because I don't so it like, you know, different projects have different constraints. It's not a purely a technical decision for us. It's mostly because we had a group of people who are already proficient with Rust who are interested in working on this. Right. Second, the Rust ecosystem is already pretty mature for when it comes to like tooling for js. There's. There are a lot of crates and people have worked on things like SWC and oxc. Oxc. These are like low level language toolchains that gives you like parsers and transformers, stuff like that. So when we build a bundler, we got to think about like, what do we build on top of. And in terms of like this layer, Rust actually has a better ecosystem compared to Go. And a final important consideration is we actually do still want our tools to be able to run in the browser. And the webassembly story of Rust is much better than Go's. Okay, interesting. Yeah, I never thought about that. But yet it needs to run in a JavaScript runtime and you do that with webassembly when we run it with. Node Node JS or bun, you know, it's actually the Rust compiled Rust binary. But if you want to run in the browser it has to be webassembly. So that's the distinction. So the roll down webassembly build runs in the browser. Actually I think Quick js, they just migrated their playground from rollup to row down. It's it runs in the browser and it made their playground through to four times faster. Wow. With rolldown. So since it is a port to an extent, a rewrite or evolution, you could say. I've been seeing a lot of the blog posts and mentions about just how much faster it is in various regards. Can you talk a little bit about the speed that comes with moving to something like rolldown in where that speed shows up and then what choices that you made actually allowed that speed to take place as a jest Rust or can you go into some of that? Yeah, so it borrows. So first of all it goes all the way down to like what parser do you use? Right. So one decision we made very early on is we bet on oxc. OXC is the language toolchain. It's an alternative to SWC essentially. Right. So it has its own parser. And I was evaluating the existing solutions and I just found OXC to be very, very fundamentally performance oriented in its design in a lot of aspects. Actually we decided to bet it on OXC before the author Borschin joined the company. So he joined us like a, like, you know, I think like half a year later I tried to convince him to join join earlier but he was like, I need to think about this, but that's a good thing. So oxc, you know, there are a few design decisions at this level, for example memory allocation, because it's actually all about like how do you allocate memory efficiently. Like OXE uses something called Arena Allocator, which means the whole AST is like allocated in a consecutive chunk of memory. So you have like less fragmentation and you can drop the whole thing altogether instead of being having to like more fine grained management of the memory. So I'm actually like less familiar with this layer because it's mostly Motion's domain. But on top of that we also debated a lot on some of the architectural decisions, like do we want to use a string based bundle generation strategy or more AST generated. But most of the gains comes from a clean architecture that allows optimal parallelization, you know, and the raw power of Rust itself. Some of that is indeed, you know, Inspired by how esBuild the design, the pipeline design. EsBuild allows you to essentially kind of divide the different phases of work and parallelize them as much as possible. So that definitely helps. So yeah, so when it's speaking to some numbers, usually you would see if it's just like a simple JavaScript bundle compared between say roll up versus roll down is like 20 to 30 times faster. Is the, the ballpark. And when it, when you put it into a real world project, we've seen anywhere from like 3 to 4 times to 16 times faster in production apps. That's nuts. And we had. Why am I forgetting his name? The author of the webpack Rust. Why am I blanking on this name? Zach. We had Zach who is writing the webpack port for Rust and he was RS Pack. That's what it is. Thank you. And I don't necessarily want to talk about that, but I just love hearing the stories of the builds that you encounter. He was telling us about the builds at ByteDance that are just hours, they're just gargantuan, you know, because like my, our little websites, they build in, in a minute or so, you know, and that's, that's relatively fast. But like, like, what do you, what do you see when you talk to people who are running this stuff at scale? Like how, how big are they? Do you have any stories? Yeah, like we are actually working with Linear to help them land. Actually they're already using Rodout Vite. So Linear was actually using Vite for like from the early beginning. They started using Vite like Vite 2 beta and we helped them started to use Roll Down Vite, which is still in experimental status. But the first pass, their whole build, they generate like 20 megabytes of JavaScript and they got the build three point times faster on CI and we're like, this is like less than we expected. So we actually took a look at the code base, we found some bottlenecks, we tweaked the config a little bit and we realized like they still had a. Because they were using style components. So they actually still use SWC to compile that, which means you are actually transforming every single file. That's an additional whole transform pass for every single file. So we just ported that specific plugin to have it run directly in Oxcure and then they were able to get rid of the extra pass and now the build is like seven times faster. And for a build of that scale, that's like huge, huge time save. Yeah. Yeah. And like, like how, how many minutes or seconds Are we talking that it went from to 2? I only remember the like the. How many times it was faster. I can't remember the exact minutes, but like it was definitely like minutes, like 10 minutes down to like one or two. Oh, wow. Yeah, that's the difference of like walking away to get a coffee because the building's running to just like, oh, hold on, let me just. I'll sit here and wait for this thing to build and then we can merge it. That's amazing. Yeah. How is this transition gone? From an outsider's perspective, it seemed like for replacing, even if it's not like for everyone, replacing this massive of a part of Vite has. Seems like it's gone relatively smoothly from the outside perspective. But like when you push something like this and give people the ability to use it if they want to, like how. How much additional work has that generated? Like is. Is it been a, a lot or does it. Has it been relatively smooth? It. It's It's a lot of work. Like we've been working on Rodound for like almost two years now. Yeah. And so obviously we start from zero, but like we essentially. So when we started working on Rodone, we also OXC mostly only had the poster and resolver. It didn't have the transformer part. So we actually also had to work on essentially replicating the whole Babel transforms in rust on top of oxcure. And then there's the minifier. We had to build a minifier that can match the compression quality of SWC but much faster. And then the bundler itself, there's like advanced tree shaking because we are now matching the build tree shaking capability and output quality of webpack. Webpack is slow, but it has pretty good output quality when it comes to tree shaking and chunk splitting, for example, these are pretty complicated things. You need to just work. You have to try it and implement it and then put it in some production apps to see if it works. So Rollup actually both Rollup and Esbuild actually kind of. They are kind of limited in terms of chunk splitting. Like if you want to more fine grainedly control how your app is split into different chunks of optimal sizes, it's a bit challenge with today's vite. So that's also one thing we kind of wanted to address. So Rollout actually supports the same sort of advanced chunk splitting configuration like webpack does. So it gives you just much more control over how do you want to like how big, the size, the minimum size, the maximum size. Do you want to put these libraries in A specific chunk, et cetera. So implemented that in collaboration with Framer. Framer was previously using esBuild to bundle other customer sites. Some of the sites were just generating too many chunks and it affects loading speed. So we actually helped them migrate over to Rowdown with the new chunk spinning behavior. And now all the sites just, you know, is able to load much fewer chunks and load faster. Let's keep going on that because it's obviously extremely complicated to build that and to worry about performance and whatnot. We've had people on the podcast in the past that say you don't need any of that, just shift ESM straight to the browser. Aside From I need TypeScript, which maybe we'll get that as comments at one point in the browser. But like, is this a stupid question? Why do we even need vite? Yeah, that's a good question. I think it really, like, it goes back to what I said about the web because like, people build all kinds of weird stuff on the web. People build small apps, people build big apps, right? So if you build big apps, even if you build big apps, like some apps care about loading speed. If you're building like ecommerce or marketing sites, right, Loading speed is all you care about. But if you're building like an internal app, it's an spa. And your users, maybe they're okay with waiting for like three seconds for it to load and they just keep the tab open for a whole day, right? So like these different constraints and also developers, right? Some developers, maybe they will switch projects like every few weeks if they're like a contractor or freelancer. But some people just work on the same app for years, like for same big app, and all they do is just think about how do I optimize a certain aspect of it, right? So if you are, say you're building like quick small apps that really, like, you know, a few less than like 100 modules, by all means, go with native ESM, it just works really well. But if you're building anything that loads more than 1,000 modules over native VSM, it's going to be slow, right? Because browsers, even with like HTTP 2 or even HTTP 3, like from what we tested, like the network overhead is a real thing that you just cannot avoid when you have too many modules. So if you just put it over the network, right, it's gonna load slow. So if you really care about performance, care about like loading your website or app fast, then you just gotta optimize it. And if the Tool. Right. So then it comes to a question of like, trade offs. Are you willing, how much complexity is the tooling introduced into your workflow compared to the eventual benefit, like performance benefits you're getting? This becomes kind of a DX versus UX problem. Right. So I guess what we're doing here with Vite and all the additional tooling we're building is we're trying to make the, the, you know, the, the DX cost much smaller to make it transparent and negligible so that you're willing to just apply these tools whenever you can so that all the users get better UX as an end result. Yeah, it does feel like it's all very, from the jump, DX focused and even going back to Vue JS and all that stuff. I think that's something I've always appreciated about your work in general is that it all feels like it's here to make everybody's life easier, where it's not trying to make you feel smarter, not trying to make you, you know, it's, it's here to enhance our lives. And I think it's done such a good job with that. Thank you. Yeah. In regards to the developer experience, many of the things that I think Vite did really well out of the gate, things like not having, you know, the effortless live reloading or just giving you. Was it like the remote links and stuff like that? What informed those decisions that you make? Is it just your own work? I suppose I would say the, the decisions on tooling is a lot of it is informed just by my experience as a framework author. So when I built Vue initially, Vue is also just a pure client side library. So you just pulled it from a CDN and just works. Later on, as we started inventing new more, adding more stuff to the framework, we started having like single file components, we started having TypeScript support. Right. So build tooling becomes kind of indispensable. So we started looking into how can we build our dedicated tooling for Vue users. And that turned out in, that turned into View cli. So we actually maintained Vue CLI for a few years, which was built on top of, you know, webpack, Babel, Jest, all these stuff we've used in the past and some, some probably still use today. And in dealing with these tools that kind of, you know, I just like remembered all the little paper cuts in dx I have Myself. So when I started working on video, it was literally out of frustration with my own experience when I was trying to reproduce a bug that user reported. And they gave me this whole VUE CLI boilerplate for a very simple bug report. And I had to download megabytes of Node modules and wait for it to boot up. And I was like, there's gotta be a better way for this. Yeah, no kidding. So that, that really got me working on Vite. Yeah. Yeah. You know, we both have a background with Meteor, and I was wondering, since you worked for the Meteor company, right, they were called Meteor. Meteor Development Group. Meteor Development Group, yes. Did. Do you ever have the urge to get into the full stack of things with Vue, considering Meteor was like, well known for handling everything, database loading data, that transportation layer. Yeah. I would say, interestingly, Meteor kind of pushed me to do the opposite in the. In the beginning, but it's a timing problem. I think Meteor was just like, way ahead of its time. You know, they came up with a whole, like, full stack JavaScript concept before Node JS was even like a big thing. And that was like, you know, for that time, that was like, revolutionary. But the thing is, what I experienced in Meteor was they decided to essentially treat Node JS as a, like, not as an ecosystem that Meteor runs in, but they want to go outside in and just like, they embed Node JS in the Meteor distribution. Right. They also mandated the database you can use. Like, basically MongoDB was the only option. So this really, like, overly monolithic approach kind of really limited how, you know, the. The eventual audience and media was able to reach. I was actually a strong advocate back then at the company to say, let's distribute media as a set of NPM packages. So we don't need to do our own package manager. We don't need to. We actually. Meteor actually had to maintain their own, like, build farm for people to build Meteor plugins, like, if you just, yeah, built them. Yeah, Yeah, right. Yeah, I remember that whole process. But I will say that there were some really great things about the Meteor package system. Yeah, I actually really still miss just modifying a package file and having it just update the dependencies for me. Like, for some reason, that little bit of developer tooling, I don't know if that's the best way to do things with versions, but for some reason I just really liked how simple that all was. Oh, just paste this into my package file. Next time I run the boot up, it just installs it for me. Yeah, I think at that time, I guess I was really Node JS pilled. I started publishing my own packages on npm. I was like, like, look, we should just like put these little packs together. UNIX philosophy. So at that time I was like, yeah, like, you know, maybe Node JS just don't really need this kind of monolithic frameworks. I guess, like, turned out to be somewhat true. Like even today, like, there are very few, you know, sort of Rails or Laravel equivalent in the Node JS ecosystem in a way, which is also weird. Like, I don't, I haven't figured that out completely myself, but I think, but my experience in media was like, okay, at that stage of the time, if you build something that's overly monolithic and opinionated, then you just have a huge risk of not reaching enough people. So that's why when I coined a term called the Progressive framework for Vue, which is essentially saying, hey, VUE starts as just a rendering library. There's a component system you can use which actually fits perfectly. When people like from the Laravel community picking it up, that's all they needed. They don't want anything else. Right. But then we added additional things like the single page application router, we added a build tool, we added state management, but these things were optional. Like you can use as much or as little you want from the framework. It's still a framework, but it's like you can incrementally adopt it to fit different use cases. Yeah, yeah. You know, I think that I, I do wonder where Meteor would be today had they listened to some of the things that you were saying. I, I, because I do feel like that was such a huge, huge reason. And I remember the conversations in the message boards at that time about supporting things other than Mongo and then led to them focusing on things like Apollo and GraphQL and that was kind of the beginning of the end right there. Yeah. And also, sorry, I just want to like follow up on the original question of, like, do do you want to do? I want to go in full stack. I think when Next JS came out, like Sebastian, who's the author of Nuxt, created Nuxt a few days later, right. I was like, yeah, like someone is working on it already, so I'll let them do their thing. In a way, I was happy that because mostly, like VUE development, it's just me and a few like volunteers or part time contributors back then, it was mostly me, to be honest. So I had limited bandwidth. I was happy to see someone else just like pick up this, like full Stack View framework Idea and just run with it. And Nuxt was, you know, the Nuxt team, they built great things. So I'm like, okay, great. There's a group of smart people working on this Full Stack View framework, so I don't have to just like worry about it. Obviously we have like collaborations and just like exchange of ideas, but for the most part they just did a really good job. And I was able to just say, okay, let me just focus on Vue Core. So we had this nice layer of abstraction where we just focus on different layers of things. Let's talk about Node for a bit and Vite's relationship to Node. Because if someone wants to build this, a node app, right, you might want to build it in TypeScript. Maybe you want like a little bit of TSX. I know there's like Vite Node and I know there's a new Environment API, which I'm not quite sure, but like, why can't I just type like Vite app TS and have that run in like as like a node server, right? Is that, is that a bit more peeled back at like a framework level? It is. So Environment API essentially is the lower level abstraction that allows you to do something like that. So let's say when you use vtest or you use a Vite based Full Stack meta framework, like maybe Tanstack Start or like Sveltekit, they leverage Environment API or Vite's. Previously there is an API called SSRload modules, but they essentially do the same thing. They essentially take the source code, process it with Vite's Transform and result pipeline and turns into something that just runs in a target runtime. It actually doesn't have to be Node. The whole point of Environment API is you can take the same code and decide to run in Node or in Bung or cloudflare Workers, the Wrangler, the local version of it. So that, yeah, surprisingly we never built an API to allow you to just call it from the cli, which is something I've wanted to do for, for a while, but just never actually did. But we are actually thinking about something like that actually. So make it easier for you to essentially say, here's a. Because right now most people think of Vite as a front end build tool, right? The entry point is the HTML and everything assumed is assumed to like run in the browser by default. So when you want to run some backend code on the side, you either have to wire up Environment API itself, which is kind of probably a bit annoying for most average users, or you have to start Express Server or custom node JS process on the side. So we want to make that simpler. So we're actually experimenting with something that allows you to run maybe a server TS and the index HTML together. Just vite dev and it just runs the two things in parallel. Yeah. Yes, please. I want that because like I'll. Obviously I'll usually reach for a meta framework where it has that in. But like when I'm going straight node or straight like typescript node, you got to throw a watch in there. You got to restart the server every time. Like I just want hot, hot reloading for my modules and there are like, I have some ugly hacks that like has still has to use common JS and it deletes the require cache just so that I don't have to restart my server when something has changed. There are a few libraries like I think TSX and like Giti. That kind of does that. Yeah, Yeah, that's what I'm using. Yeah, but Environment API, I guess like having it built into Vite. The nice thing is you know that the same code base is processed by the same set of tools, so it's the same resolution logic, the same transformation logic. That's all from the same tool. So you just have fewer surprises. And environment API also gives you a bit more. I guess it's actually hot module replacement for server side code. So you can actually have like, you can update a handler without restarting your server side process and next visit it actually is calling the updated handler. Yeah, that's exactly what I want. Yes, please make that happen. This is my. This is the only reason we're having you on today is I'm asking you to make that. That's That's good validation. That's good validation. Yeah, yeah. Wes loves giving a wish list to the guests. Yeah, Yeah, yeah. Now that I have you here. Yeah, exactly. Allow Allow me just to ask you for my list of things. Oh, also I want, you know, like in the old PHP days, I'm going to use all your time here for wish list. The old PHP days where you just get a directory of files. I built a plugin called Vite Dir that does that because I have courses that have multiple entry points, multiple index or multiple HTML files that are entry points. If it's not called index HTML, you have to manually type it in. So I built a little plugin that would give you a listing of a directory contents and then you can click on the HTML files and it will parse it through. That's always one thing that I wish Vite would do by default. It's almost like a default HTTP server. Some HTTP servers. Yeah, Yeah, exactly. Exactly. I see. Okay. Okay. Exactly. Exactly. Interesting. Interesting. It It just brings me back to the PHP days where you just click the file and that file will run. Did you open a source that plugin? Yeah. Yeah. You You can NPX Vitdir and it will. It will fire up just a vite with you right there. But I would like for that to be built in. It is nice. I I do find myself using it a lot. Wes. It is really nice. But also, I wonder, like. Like, I'm just a tutorial creator, right? Like, are people who are actually building, like, enterprise software have a need for that or is it just me? Because I spin up so many demos every now and then, but that's my wish list. I'll stop. A little bit spicy. I know you're. You're one to get a little bit spicy on Twitter. And we can cut this out if you're. If you're not comfortable with it, but. Would Next JS be better with V? Yes, Yes, I would say it would. True story. We actually, like, talked with Vercel multiple times about, like, I pitched it. I was like, if you guys want to move Next song to Vite, we're here to help. I think at one point, Next team actually also really thought about it. They were just like, trying to get the pros and cons and just like, trying to make a decision. But I think eventually they just like, okay, we're gonna. It's. It's too risky for them. The. The short story is, right, they have built on top of webpack for so long, and they also invested a lot into turbopack. So in terms, like, for the existing users, right, there are so much, like, so much behavior that's just coupled to the way the things work inside Next js so moving it to a completely different build tool. Especially when Vite's default, like, development behavior is unbundled. So there are just like, so many places things can go wrong. And, you know, the chance of porting it over to Vite and then having existing production Next JS app just work on that new version is very slim. Or you would have to, like, spend years to make it work. So unfortunately, it's very difficult to make that happen. But we did actually prototype something that's like Vite on really Next on Vite, and we were able to like, even get REACT server components working. We were able to get the next 15 app router demo to maybe 90% of features working. Obviously it was still kind of rough, but we were trying to just validate the idea to see if it's possible it end up did not landing in actual Next js. But I think that gave us a lot of insights on how React server components should work with Vite. So that kind of led to the current Vite RSC plugin. Yeah. Because I've used the Turbo pack quite a bit and it's edge cases all the way down because there's so many things that they need to account for. People think oh just use Vite, you know, but like they have so many like little gotchas of like what happens if you use MDX version 1 with a common JS plugin that doesn't have a default export. You know, like there's all these little weird gotchas all the way down. And. And I do not envy anybody who has to build these type of things. Yeah, no kidding. That's why turbopack took so long. I think it's a bit, you know, when they decided to just build something completely different from webpack from the ground up. Right. It's It's bound to be a very risky decision. But I think after a few years it's like the sunk cost is just like they've invested so much into it, just they just had to double down. Yeah. I often feel bad when I, I feel bad for next year users that they don't get to experience the just easy speed of Vite all the time. And when there are people post about oh my next build is faster, I'm like, bro, welcome to what like 2018. When did you release Vite first? It feels like it was a longer than that. 2020? Yeah, just five years ago. Okay, let's talk about React server components. Like do you have any opinions on React server components? I do. So at the very high level, you know, I think it kind of under delivered. Yeah. Okay. I I think the biggest problem is just the promised gang and the cost of dx. First of all, the React server components and the way they are presented in Next JS is kind of two different things. So there are probably simpler ways for you to use rsc. But because the design and implementation of RSC is just so tightly coupled with Next JS right now, the mainstream way of people to use RSC is really through Next js. So the Use Server Use client directives and the mixed RSC graph, you can have a mixed graph of like server components and client components. I think that just adds a ton of mental complexity to any User trying to, like, reason about your application. Like, does this piece of code run the server or run on the client? And to make it worse, they actually don't behave the same way. Like, there are some things you can use on the client but not on the server. And when you have the mixed tree, you have to, like, bail out on the context altogether, you know, So I just think there are so many little paper cuts that makes people have to, you know, you basically have to pay with your developer experience in order to use rsc. But in the end, when you, let's say, put it in production, are. You see, I really haven't heard super convincing stories on how Ric has, like, say, fundamentally made something more performant. So, yeah, you can call me a skeptical. All right. Like, obviously I have, you know, when I talk about NEXT JS or ISC or these things, I always have the utmost respect to the people who work on those things. Right. These are hard problems. They spend a lot of time and energy working on those things. But, like, you know, deep down, if I'm looking at RSC objectively, I just don't feel like it delivered what it promised to deliver. Right. And that is also one of the reasons why Vue just won't do something like that. We just felt like we don't want to do it just because React does it. Beautiful. What about any thought we don't know what it is yet, but Remix three, I'm going to the conference next thing. Any thoughts on that whole direction of just dumping React entirely and building your own templating language? We'll see. Yeah, I, I honestly, I know. I don't think I know enough about it to make a judgment at this moment. Right. Yeah, Yeah, just, just based on the information that Michael and Ryan has been. Has given us. I, I don't know. Like, I, I feel like, like I know they're smart people, right? They might be onto something, but the information I'm given, I'm not super optimistic about the eventual say. Will it eventually become mainstream and be used by a lot of people? I'm a bit doubtful, but I'll reserve that judgment until they reveal what it actually is. Yeah, our running take is that Shopify needs some sort of custom site builder that AI can control. And we think that they are building a dead nut simple thing similar to how people love Liquid for Shopify because it's, it's so simple. But instead of having to code Liquid, they just type in the box, make a huge hero banner that shows my latest three products. That's my Running thought that Shopify needs something before another company comes in with an AI Shopify competitor. So are you saying it's more geared towards like AI auto generating storefront code? I think they're trying to build an API that is friendly for them. LLM can understand very easily and be able to crank out components and components that interact with each other and are able to like a very simple framework that AI is able to consistently create items for. And that will be a very good engine for people building Shopify stores. I see. But would it be equally friendly to humans? I'm actually starting to think, you know, what is friendly to humans may not be fundamentally friendly to AI agents and vice versa. So yeah, I'm curious. That's a great question. Me too. I love talking to people about it because they've been teasing it for so long and I've been in Michael's DMs for months now and he's coming on as soon as he's ready, but I'm curious to see what comes out. Yeah. Void zero, your company, what do you do to make money? Why did you start a company behind a JavaScript bundler? Well, we're frames as the tool chain, not just the bundler. So there's the whole set of underlying parser, transformer, resolver and then there's the bundler, there's Vite, the build tool. Vite is going to get a server API, so it's a bit more full stack than it previously is. There are meta frameworks built on top of it which we support and then we have unit like test runners, linkeders, formatters. So we want to put these things together into a sort of managed solution. Right now it's named Vite Plus. We're going to talk about more details of Vite plus at ViteConf, which is happening next month, October 9th and 10th in Amsterdam. So in short, our first attempt will just be trying to, you know, sell vplus, because there are going to be some additional things that's more enterprise oriented and we want to experiment with a licensing model that is, you know, it's going to be free for individuals, for open source, for non commercial. So and it's free to just try it out. You know, it's the same NPM distribution, you just install it, override Vite in your patch manager config and you can start using it. So it's the same Vite, it's a dropping superset vite dev, vite build, still work exactly the same way, but then you can additionally just do Vite linked vite test and it's built on the existing solutions that you're already familiar with, except they are now used. Part of that a, like a shared build cache as well. For, for people who need to like have, have huge builds, there are a. Build Build caching capability built into the toolchain. Remote caching will most likely be implemented, but you know, it's gonna be. We're not quite sure if we want to like, say, you know, make money on remote caching. That's one possible outcome, but you know, our short term. So my personal hope is we can essentially monetize the toolchain itself by having these bigger companies essentially pay for the advanced features to subsidize the use of the toolchain itself to individuals or open source or smaller companies. Wow. Wow, this is exciting. This has got me really excited for viteconf. So man, that's coming right up here. Yeah. Are you excited to head out to Amsterdam? Yeah, I mean the only downside is I've been to the city so many times. Yeah, I know, right? We, We, yeah, we have like. Yeah, yeah, yeah. It's a great place for conferences though. They, they, they do a great job. They get a lot of people. Yeah, we have a very, very exciting lineup. Like Rich Harris is going to be there, Ryan Kaniara is going to be there. Matt Bielman, Eric from Stack Blitz. So yeah, a lot of smart people. Johannes Schickling. Yeah, yeah, it's a stack lineup for sure. Yeah. Anthony Fu. We've been, we want to get him on the podcast as well. Man, he's, he's prolific. What's he like? You probably know him better than I do, but like prolific dev, cranking out everything. Yeah, he just moved to Japan a while ago. He's now kind of in a transition period, but we're actually having him work on the new GUI dev tools for Vite as well. So there's going to be a GUI interface dev tool that kind of like. I don't know if you've. You've seen Nuxt dev tools. That's what he built. He built that too. Right. So we want to have that in Vite, which allows you to inspect, like how a module is transformed. He previously built a thing called V plugging. Inspect. Yeah. Like, Like, he just built so much stuff. And it's all beautiful. Yes. Yeah, exactly. Yeah. Yeah. He's He's also a design engineer at heart, so. Yeah, totally. He He actually has a Very. He has a talk called Yak Shaving. Essentially talks about how he. The reason he got into so many projects is just when he was working by himself, he would find these little paper cuts in his workflow, and his reaction is, can I build something to make this go away? And that just ends up leading to all these different things he built. Oh, I love his yak map. Oh, man. He built a whole map showing his journey. So dope. Oh, that's great. Cool. Cool. Well, I think we're kind of running out of time here, because I got to take the. Well, at least I am West. You can. Yeah. Yeah. Evan's got to go to bed. Scott's got to go drop his kids off. I'm in the regular time zone here. I talk forever. Yeah. Right. But, yeah, let's. Let's wrap this up. The last thing we have here is sick picks and shameless plugs. I'm not sure if you came prepared with a sick pick or a shameless plug. I did not. Sick pick. Okay. Okay. Yeah. So a sick pick is you pick something that you absolutely love in your life. It could be a pair of headphones, could be a chocolate bar, could be Ryan from Dino and Node. He picked flying a kite and going for a walk. So literally anything in your life where you're like, I love this. Okay, so I got this Lambo stress toy from Larica, and just, like, so squishy. Feels so nice. I just had it on my desk ever since I came back with it. It's the best thing ever. Ben Classics dress toy. That's That's good. Yeah. Shout out to Taylor. Shout out to Taylor for making this. Yeah. I love how he's just totally leaned into the whole Lamborghini thing. That's unbelievable. And then Shameless plug. What would you like to plug to our audience? You can plug as many things as you want. There's Vite. Plus there's viteconf. And one more important thing I want to plug is we are actually premiering the vite documentary @viteconf in person. Nice. Nice. Yeah, so that's being, like, a year in the making. It's made by the same crew that made the Vue documentary, and it's also the Cult Repo Crew, which is previously the Honeypot Crew that made all those other tech documentaries. And, yeah, we're showing it at VidConf in person, and it's gonna also be live on YouTube afterwards, so stay tuned. Sweet. I'm I'm excited for that. They do the best work. And just a really, just lovely group of people over there at Cult Repo, so shout out that YouTube channel. We'll link it up in the notes as well. Awesome. Well, Evan, thank you so much for coming on. Appreciate all your time. This is great to finally have you on. And we'll catch you later. Yeah, I had a lot of fun. Thank you, guys. Next.