Creator of Vite: Evan You

Welcome to Syntax. Today, we have the goat, the the man who has made web development easier for the entire world, probably kept people in the career, before they had Rage Kit. And we have Evan Yu on. He's the creator of Vue, creator of Vite, which probably everybody listening to this 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, like, six people who haven't done it, give JS an introduction of of who you are and what you do and kinda your background.

Sure. Yeah.

So I had been a independent open source developer for over a decade, like, since 2015, sixteen ish.

Two years ago, I founded a company called Voice Deno, which is centered, you know, with the with the mission to, to build open source tool chains 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,

Voice Deno and the feed side of things. Yeah. So I think that 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 tool chain?

Not really. So I would say a lot of the 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 jobs for development, I thought I was going to be a designer. Mhmm. 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 Vercel, 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 kinda clunky. What about I build a framework for myself? And as I build frameworks, I just kind of dig dug deeper and deeper. Yeah. It's a wormhole.

You just kept solving your the problems that you had until you're, one day you wake up and you're you're writing low level Rust to to solve all your problems.

And this might be a weird comment, but, there's something about the aesthetic of not just, like, the visual aesthetic, but, like, the things that you make that makes it kind of obvious that you wanted to be a designer. Like, Vue is a beautiful, looking JavaScript framework. Right? Like yeah. It's it's hard to describe many JavaScript frameworks as, like, looking nice just in a a code context, but I I wonder, like, how much of that is informed just by your aesthetic awareness.

It it definitely played a role because, I think I probably put more effort into the documentation than the average developer who made frameworks.

Yeah. So that probably helped with the definitely helped with the initial adoption of Vue.

We were asking that, when we had the Daniel from Nuxt on. We're just like, look. Why is everything in this whole VueVite kind of associated ecosystem? Why is everything so so polished and and so simple? And and even to extend it, the API design as well is is really, really simple. So I'm I'm curious if you have any, like, like, core philosophies as to, like, just designing stuff in general, whether it's what it looks like or whether how the what the API design looks like.

Yeah. I I think, interestingly, because I initially got into web development from a nonengineering back background. Right? So, a lot of people probably know that when I started to work on Vue, I was working at Google, and we worked on some projects that used Angular.

And I could tell that Angular was created by someone very engineer 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 allowed 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, you know, do what I want to do? Right? And turns out that probably, you know, 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, you know, it 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.

Mhmm. Yeah.

I I agree with that, but, like, if I were to go off and and maybe create Vite, like, I, like, I feel like I know the entire Vite API. You know? I've I've built several lower level plug ins in it. I've built very complex, like, I've migrated old apps that were in Vercel and webpack and and brought it into one. And Mhmm. I I use the WebSocket proxy API. Like, I feel like I know the entire Mhmm. Vite API, but, like, 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, like, thrashing changes. You know? It's just like, oh, the new version's out.

Stoked to have it. Yeah. Yeah. We made most funny story, we made the biggest breaking change between v two one and v two because, if if if you followed along the early days of v, like, we came all we we went all the way to, like, one point o r c 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's plugging API is based on top of. Mhmm. Mhmm.

And, Vite Node did not have a plugging system.

The Vue logic in Vite one was, like, hard Node.

It it was around that time I started to think about, like, production build. We were using roll up, so we were using roll up plug ins. I was like, can we make the roll up plug ins work for the dev server too? And then I found out, Jason Miller actually did it in his project called WMR.

He he did this, like, Rollup plugging simulator that is able to just run Rollup plug ins 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 plug in system for the dev server and the production build. Right? I had to rewrite the whole thing, and that became Vite two. So we never actually shipped to Vite one.

Oh.

And if you want to see all of the errors in your application, you'll want to check out Sentry at century dot I o 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 century.i0/syntax.

Again, we've been using this tool for a long time, and it totally rolls. Alright.

Let's talk a little bit about the whole roll up and 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 it's no longer technically a rewrite because, originally, the name is Node down because we're like, okay. This is gonna be a rogue port. We're just gonna straight up port it. Yep.

Turns out, you know, Rust works very differently from JavaScript. So a port is like you can 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 JS 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? Wes build kinda just does all of this out of the box. You don't need to use a plug in just to transpile TypeScript.

So, Node is essentially, implemented in Rust. It a lot of stuff work out of the box, TypeScript, JSX, node module resolving, but the API is roll ups. So we support roll up plugins. It's a Rust handler, but we support JavaScript plugins. So if you have a roll up plugin that's written in JavaScript, it will actually just work in ROTA.

So How does that work? It relies on something called, a project called, n a p I r s. So, Node. Js has this thing called n a p I that allows you to basically do cross language calls. So Native API. Right? That's what n JS? Yeah. So nAPI JS is a project that's, that's aim the aim is to make it easier for you to write some Rust code and, auto automatically generate the binding so you can call the Rust code from JavaScript and vice versa.

Mhmm. Okay. And we had the TypeScript folks on, and so we're we have to ask this question of, like, why didn't you use Go versus Rust? And the reason the TypeScript folks gave us is because that like, it's much easier to port JavaScript to Go because it they're literally just going function to by function, rewriting the entire thing. But you just said you just said it's not the same with Rust. So what's the 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 Scott 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.

Yeah. Interesting. Yeah. I never thought about that, but yet it needs to run-in a JavaScript runtime.

Yeah. And and you do that with WebAssembly.

Wes when we run it with Node. Js or BUN, you know, it's actually the Rust Rust binary. But if you want to run-in the browser, it has to be WebAssembly.

So that's the distinction. So the row down WebAssembly build runs in the browser. Actually, I think Quick. Js, they just migrated their playground from roll up to Node down.

It's it runs in the browser, and it made their playground three to four times faster. Wow. With with roll down, so since it JS a a port to an extent of rewrite or evolution, you could say, I've I've been seeing a lot of the 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 roll down in, where that speed shows up? And then what choices that you made actually allowed that speed to take place? Is it just Rust? Or or can you can you go into some of that?

Yeah. So it boils 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 Mhmm. The language tool chain. It's an alternative Wes 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 Pnpm before the author, Bauschian, 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 he eventually joined. So, that's a good thing.

So OXC, you know, there's there are a few design decisions at this Vercel. For example, memory allocation because it's actually all about, like, how do you allocate memory efficiently. Like, OXY 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 grain management of the the memory. So I I'm actually, like, less familiar with this layer because it's mostly Martians domain.

But on top of that, we are also debated a lot on, you know, 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 the 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, ES builds, the design the pipeline design Wes build 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 will see if it's just like a simple JavaScript bundle compared between, say, roll up versus Node down, it's, like, 20 to 30 times faster, is the, the ballpark.

And when you when you put it into a real world project, we've seen anywhere from, like, three to four times to 16 times faster in production apps.

That's nuts. And we had, why am I forgetting his Node? The author of, the Webpack Rust. Why am I blanking on his name? Zack.

Zack. We had we had Zack, who is writing the the Webpack portal for Rust, and he was Yeah. RS pack. That's what it is. Thank you.

And, like, I don't I don't necessarily wanna talk about that, but I just love hearing the stories of the builds that you encounter. Like, he was telling us about the builds at ByteDance that are just hours. You know? They're just gargantuan. You know? Because, like Yep. My our little websites, they build in in a minute or so. You know? And that's that's relatively fast. But, like, look, 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 RodelVeed.

So Oh, okay. Was actually using Veed, like, from the early beginning. They started using Veed in, like, Veed two beta.

And we helped them started to use Node Veed, which is still in the experimental status, but the first pass, their whole bill, they generate like 20 megabytes of JavaScript.

And they got the bill three point times faster on CI. And we're like, this JS, 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 then we we realized, like, they still had a, because they were using style components. So, they actually still use Wes w c to compile that, which means you are actually, transforming every single file.

That's an additional whole transform pass for every single file. Mhmm. So we just ported that specific plug in to have it run directly in o x c, 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 that scale, that's, like, huge, huge time save. Yeah. And, like, like, how how many minutes or seconds are we talking that it went from to two?

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, ten minutes down to, like,

one or two. Oh, wow. Yeah. That's 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 and then we can merge it. That's amazing.

Yeah. How has this transition gone? It's from an outsider's perspective, it seemed like for replacing even if it's not, like, for everyone Mhmm. Replacing this massive of a part of Veet 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 it is it been a a lot, or does it has it been relatively smooth?

It it's a lot of work. Like, we've been working on RowDown for, like, almost two years now. Yeah. And so, obviously, we started from Deno, but, like, we essentially so when we Scott working on Node, we also, OXC mostly only have the parser and resolver.

It didn't have the transformer part. So, we actually also had to work on all essentially replicating the whole Babel transforms in Rust Mhmm. On top of o x c. And then there's the minifier.

We had to, build a minifier that can match the compression quality of Bos, but much faster.

And then, the bundle the bundle itself, there's, like, advanced tree shaking because, we are now matching the built, tree shaking capability and output output quality of Webpack.

Right? Webpack is slow, but it, like, it has pretty good output quality when it comes to, like, you know, tree shaking and, chunk splitting, for example. Right? These are pretty complicated, like, things you need to just work.

You have to, like, try it and implement it and then put it in some production apps to see if it works. Right? So, like, roll up actually both roll up and Wes build actually kind of they are kind of limited in terms of, like, 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 challenged with today's Vite. So that's also one thing we kinda wanted to address. So, so in Node 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 bit maximum size, do you want to put these libraries in a specific chunk, etcetera.

So we implemented that in collaboration with Framer.

Framer was previously using ESBuild to bundle on their 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 a new chunk spinning behavior, and now all the slides just, you know, is able to load much fewer chunks and load faster.

Yeah. Let let's keep going on that because, like, it's obviously extremely complicated to to build that and to worry about performance and whatnot. And and we've had people on the podcast in the past that say, you don't need any of that. Just ship Wes s m straight to the browser.

Aside from, like, I need TypeScript, which maybe we'll get that in, as comments at one point in the browser.

But, like, is this a stupid question? Why do we even need v why do we need a bundler? Yeah. That that's a good question. I think, it really like, it goes back to what I said about the web because, like, people built all kinds of weird stuff on the web. People build small apps, people build big apps. Right? So, if you if you build big apps, even if you build big apps, like, some apps care about loading speed. If you're building, like, e commerce 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, like, your users may be like, they're okay with waiting for, like, three seconds for it to Node, and they just keep the tab open for a whole day. Right? Yeah. So, like, these different constraints, like, and and also developers, right, some developers, they maybe they will switch projects, like, every few weeks if they're, like, a contractor or a 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 Yarn, say, you're building, like, quick, small apps that really, like, you know, a few cut less than, like, a 100 modules, right, by all means, go with native ESM. It just works really well. But if you're gonna anything that loads more than a thousand modules over native ESM, it's gonna be slow. Right? Because browsers Node like, even with, like, HTTP two or even HTTP three, 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 Scott a little slow. So if you really care about performance, care about, like, loading your website or app fast, then you just Scott 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 ESLint introduced into your workflow compared to the eventual benefit, like performance benefits you're getting? So it becomes kind of a DX versus UX problem. Right? So I guess what we're doing here with Veed 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 I I think that's something I've always appreciated about your work in general JS that it all feels like it's here to make everybody's life easier Wes it it's not trying to make you feel smarter or not trying to make you you know? It's it's here to enhance our lives, and and I think it's done such a a good job of 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, Wes it like the remote links and stuff like that? What informed those decisions that you make? Is it just your own work? Do many of those ideas for, like, what needs to be out of the box DX? Like, where do those ideas come from, 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.

Right? So, when I build Vue, initially, Vue is also just a pure client side library. So you just pulled it from a CDN and just works.

Yeah. 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 Vue CLI.

So we actually maintained VueCLI for a few years, which was built on top of, you know, Webpack, Babble, just all these, stuff we've used, in the past. 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, like, they gave me this whole VueCLI boilerplate for a very simple bug report. And I had to download megabytes of Node modules Yeah. 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 Veed. Yeah. You know, we both have a a background,

with Meteor.

And I was wondering since you worked for the Meteor company. Right? What what they they were called Meteor,

Meteor Development Group.

Meteor Development Group. Yes. Yeah.

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 kinda 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? And 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 embedded 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.

Uh-huh. So we don't need to do our own package manager. We don't need to Right. We actually media actually had to maintain their own, like, build farm for people to build Meteor plugins.

Like, if you just want I built yeah. Built them. Yeah. Yeah. Right? Yeah. So I I remember that whole process. But I I will say that there were some really great things about the Meteor package system. I, 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 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 just paste this into my package file. Next time I I run the, the boot up, it just installs it for me. Yeah. I I think, like, at that time,

I guess I was, like, really Npm, like, Node. Js build. I started, like, publishing my own packages on npm. I was like, like, look. We should just, like, put these little packages together, UNIX philosophy.

You know? So Yeah. 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 it's it's it's also weird. Like, I I don't I haven't figured that out completely myself. But, I think but my experience in media was like, okay, if, like, at that stage of the time, if you were build something that's overly monolithic and opinionated, right, then you just have a huge risk of not reaching enough people.

Uh-huh. So that's why when I I have a I call it a term called the progressive framework for Vue, which is essentially saying, hey. Like, 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 Scott management, but these things were all 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 then I I remember, the conversations in the message boards at that time about

supporting things other than Mongo and then Mhmm. Led to them focusing on things like Apollo and GraphQL, and that was kind of the beginning of the end right there. Mhmm. Yeah. And, also sorry. I just want to, like, follow-up No. No. No. Bos original question of, like, do do you wanna 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 JS working on it already, so I'll I'll let them do their thing.

In a way, I was happy that because mostly like view 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 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, you know, for the most part, you know, they just did a really good job, and I was able to just say, okay. Let me just focus on Viewcore.

And you know? So we have this, like, nice layer of, like, abstraction where we just focus on different layers of things.

Mhmm.

Let's talk about Node for a bit, and, like, look, what Vite's relationship to to Node. Because, like, if if someone wants to build this a Node app, right, you might wanna build it in TypeScript. Maybe you want, like, a little bit of TSX.

Yeah. 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, viteapp.ts and 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 Viteast or you or you you Wes you use a Vite Bos full stack meta framework, like maybe 10 stack start or, like, SoundKit.

Right? Wakeroom.

Yeah. Yeah. They they leverage environment API or Vite's.

Previously, there JS an API called, SSR load 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. Right? Environment the whole point of environment API is you can take the same code and decide to run a node or in in one or Cloudflare workers, the the regular, the local version of it. Right? So, that yeah. Surprisingly, we never built an API to allow you to just, like, Scott from the CLI, which is something I've wanted to do 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 assume is assumed to, like, run-in the browser by default.

So when you want to run some back end code on the side, you either have to wire up the environment API itself, which is kind of probably a bit, annoying for most average users, or you have to Scott, like, express server or or a 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 dot t s and the together.

Just feed that, feed build, and it just, like, runs the two things in parallel. Yeah.

Yes, please. I want that because Yeah. Like, I'll 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 gotta throw a watch in there. You gotta restart the server every time. Like, I just want hot hot reloading Yeah. Yeah. For my modules. And there Yarn, like I have some ugly hacks that, like, has still has to use common JS, and, like, it deletes the require cache, just so that I don't have to restart my server, Wes something has changed. And I'm just like, I would just love

Node v for for this type of stuff. There are a few libraries, like, I think TSX and, like, Jitie that kind of does that. I That's what I'm using.

Mhmm. Yeah. But environment API, I guess, like, having it built into Vite, the nice thing is you know that the same code Bos is processed by the same set of tools. Right? So it's the same resolution logic, the same transformation logic that's all from the same tool. Mhmm. Yep. So you just have less fewer surprises.

And environment API also gives you a bit more, I Wes, it's actually hot module replacement for Vercel side code. So you can actually have, like, you can update a handler,

without restarting your Vercel side process. And next visit, it actually is calling the updated handler. Yeah. That's exactly what I want. Yeah. Please make that happen. This is my, this is the only reason we're having you on today JS I'm asking you to make that. That's good validation.

That's good validation.

Yeah. Yeah. Wes loves giving a wish ESLint to the guests. Yeah. Yeah. It's like, now that I have you here Yeah. Exactly. 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 I'm I'm gonna use all your time here for WishList. Yeah. The old PHP days where you just get a directory of files.

Mhmm.

I built a plug in 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. Right? And if it's not called index.html, you have to manually type it in. So I built, like, 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 it will parse it through. So, that's always one thing that I wish Vite would do by default.

It's almost like,

like a default HTTP Vercel some HTTP service. Exactly. Exactly. I see. Okay. Exactly. Interesting. Brings you back to the the PHP days where you just click the file and and that file will run. Did you open source that plug? Yeah. Yeah. It's you can n p x v v n p x v dir, and it will it will fire up just a vite with you right there. But I, K. I will check for that to be built in. It is nice. I do find myself using it a lot, Wes. It it is really nice, but I also wonder, like like, I'm just a tutorial creator. Right? Like, are are people who are actually building, like, enterprise software, knee have a need for that, or is it just me because I spin up so many demos every now and then? Uh-huh. But that's my wish list. I'll stop there.

Let's get let's go a little bit spicy. I know you're you're one to get a little bit spicy on Twitter, and and we can cut this out if if you're if you're not comfortable with it. But,

would Next. Js be better with v Yes.

I would say it would.

True story. We actually, like, talked with Vercel, like, multiple times about, like I pitched it. I was like, if you guys wanna move Nexon to Vite, we're here to help.

I think at one ESLint, Nexon 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 Yarn so much, like, so much behavior that's just coupled to the way that things work inside Next. Js.

So moving it to a completely different build tool, especially when, Vite's default, like, development behavior is unbundled.

Right? 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 ESLint, or you would have to, like, spend years to make it work. So, unfortunately, it's 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 Vercel components working. We're able to get the, the next 15 app router demo to maybe 90% of features working.

Obviously, it was still kinda rough.

But Yep.

Like, we were trying to just validate the idea to see if it's possible.

It ended up did not, you know, landing in actual Next. Js, but, I think that gave us a lot of, like, insights on how React server components should work with Vite. So that kind of led to the current,

Vite RSC plug in. And, yeah, I because I've used the turbo pack quite a bit, and it's it's edge cases all the way down because there's so many things that they need to account for. People think, just use Vite. You know? But, like, they have so many, like, little gotchas of, like, what happens if you use MDX version one with a common JS plug in that doesn't have a default export? You know? Like, there's all these little weird gotchas all the way down, and and and it's I do not envy anybody who has to build these type of things. Yeah. No kidding. That's why all the way down.

That's why TurboPact took so long.

I think it's a bit you Node? When they decided to just build something completely different from Webpack from the ground up, right, 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. It just, they just have to double down. Mhmm.

Yeah. I often feel bad when I, I feel bad for Next. Js users that they don't get to experience the easy speed of of Vite all the time. And when there are people who post about, oh, my next build is faster, I'm like, bro, welcome to, what, like, 02/2018? When when did you release Vite first? It feels like it was a long longer than that. Yeah. 2020?

Yeah. Just five years ago.

Okay.

Let's talk about rack server components. Like, do you have any opinions on rack server components?

I do.

So at the very high level, you know, I think it kind of under delivered.

Right? Yeah. Okay. I think the biggest problem is just the the promised gain and the in and the, and the cost of DX.

You know? Like, first of all, like, the React server components and the way they are, you know, presented in, in Next. Js JS kind of two different things. Right? So there are probably simple simpler ways for you to use RFC.

But because the the design and implementation of RFC is just so tightly coupled with Next. Js, the right Node, the mainstream way of people to use RFC 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 wrong on the server or wrong on the client? And, to make it worse, they they actually don't behave the same way. Like, there are some things you can use on the ESLint, 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, like, say, put it in production, are you see I really haven't heard super convincing stories on how RSC has, like, say, fundamentally made something more performant.

Mhmm. So

yeah, I'll let you can you can call me a skeptical. Alright? Like, obviously, I I have you Node, when I talk about Next. Js or ISC or 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. Right? But, like, you know, detail, 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, few just don't won't do something like that. Wes just felt like, like, we don't Wes don't want to do it just because Wes acknowledge it. Beautiful.

What about any thought we don't know what it is yet, but Remix three, I'm going to the conference next next, thing. Any thoughts on on that whole direction of just, like, dumping React entirely and and building your own, I guess, 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.

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 Yeah. Be onto something. But Yeah. You know, the the information I'm given, I'm not super optimistic about the, the eventual, like, say, will it, like, be eventually become mainstream and be used by a lot of people? I'm a little bit doubtful, but I'll reserve that judgment until they reveal what it actually is.

Mhmm.

Yeah. Our 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 nuts 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. Can understand with 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 Yeah. Would it be equally friendly to humans? I'm actually starting to think, you know, what is friendly to humans not Yeah. May not be fundamentally friendly to AI agents and vice versa.

You know? So, yeah,

I'm I'm curious. So 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 for months now. And he's coming on as soon as he's ready, but I'm curious to see what what comes out.

Yeah.

VoidZero, your company.

Yeah. What do you what do you do to make money? How do you why did you start a company behind a a JavaScript bundler?

Well, it it's I mean, we're we're framed as, like, the the tool chain, not just the bundler. Right? Right? So there's the the whole set of underlying parser, transformer, resolver, and then there's the bundler. There's v to build tool. V just gonna get a survey API. So it's a bit more full stack than it previously is. Mhmm. There are meta frameworks built on top of it, which we support.

And then we have unit like test runners, linkers, formatters.

So we wanna put these things together into a sort of managed solution.

Right now it's named v plus.

We're gonna talk about Node details of v plus at VidCon, which is happening next month, October in Amsterdam.

So in short, our first attempt will just be trying to, you know, sell v plus 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 Node, it's going to be free for individuals, for open source, for non commercial.

So and 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. Same it's a dropping superset.

Veed dev, Veed build still work exactly the same way, but then you can additionally just do Veed linked, Veed Wes, and it's built on the existing solutions that you're already familiar with, except they are now use they now use a centralized configuration so that they also understand how each other works out of the box.

And JS 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 caching, capability built into the tool chain.

Remote caching will most likely be implemented, but, you know, it's gonna be we're not quite sure if we want to, like, see, 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 tool chain 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 of smaller companies.

Wow. Wow. It's exciting. This has got me really excited for, VITCONF. So, man, that's that's coming out right up here. Yeah. Are 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 don't Wes yeah. We have, like, few hours. Nation.

Yeah. Yeah. To yeah. Yeah. Yeah.

Yeah. It's a great place for conferences, though. They they, they do a great job. They get a lot of have a conference.

Yeah. We have a very, very exciting lineup. Like, Rich Harris is gonna be there. Ryan Coniarra JS gonna be there.

Matt Bealman, Eric, from Stackblitz.

So, yeah, a lot of, smart people Lindsley,

Node Schickling. Yeah. Yep. Yeah. It's a it's a stack lineup for sure. Yeah.

Anthony Fu, we've been we wanna get him on the podcast as well, man. He's Yeah. He's prolific.

What's what's he like? How you you probably know him better than I do, but, like Yeah. Prolific dev cranking out everything.

Yeah. He 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 gonna be a GUI interface dev tool that kind of like I don't know if you've you you've seen Nuxt's 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 Vite plugging inspect.

Yeah. Like, he just built so much stuff. But And and it's all beautiful. Yes. Yeah. Exactly. Yeah. He's he's a also a design engineer at heart. So, yeah, totally. 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 Yac map. Oh, man. Yeah.

He built a whole map showing his journey.

So dope.

Oh, that's great. Cool. Well, I think we're we're,

kind of running out of time here because I gotta take the well, at least I am. West, you you can Yeah. Certainly keep going. Bed. Scott's gotta go drop his kids off. I'm in the regular time zone here. I talk forever. Yeah. Right. Yeah. 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 could came prepared with a sick pick or a shameless plug.

I did not. Sick pick. 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 Deno. And and, Node, he picked flying a kite and going for a walk. Yes.

So literally anything in your life where you're like, I love this.

Okay. So I got this Lambo stress toy from Laracon.

Oh. Hey. Just, like, so squishy.

Feels so nice.

I just had it on my desk ever since I came back with it. It's it's the best thing ever. Man, classic stress toy. That's good. Yeah. Shout out shout out to Taylor. Shout out to Taylor for making this.

Yeah. That's great. 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 v plus. There's v Scott.

And, one more important thing I want to plug is we are actually premiering the, the Vite documentary at VidCon in person. Nice.

Yeah. So that's been, like, a a Yarn in the making.

It's made by the same crew that made the View documentary and it's also the, the Cult Repo crew, which JS previously the Honeypot crew that he made all those other tech documentaries.

And, yeah, we're showing it Ashby content in person, and it's gonna also be live on YouTube afterwards.

So stay tuned.

Sweet. I'm excited for that. They do the best work, and just a really just lovely group of people over there at CultRebo. 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. A hell Scott of fun. Thank you, guys.

Thanks, guys.