939: Creator of Vite: Evan You

Scott and Wes sit down with Evan You, creator of Vue, Vite, and VoidZero, to dig into the future of frontend tooling. From the speed of Rolldown to why he chose Rust, they explore the evolution of developer experience, bundlers, and what’s next for the web. Show Notes 00:00 Welcome to Syntax! 00:31 Who is Evan You? Vue.js. Vite. Void0 01:19 Making the shift from UI to Toolchains. 02:37 How aesthetics contributed to the success of Vue and Vite. 05:26 Adding Rollup plugins to the Dev Server. 07:31 Brought to you by Sentry.io. 07:56 Rollup and Rolldown explained. 09:29 NAPIRS. 10:02 Why Rust and not Go? SWC, OXC. 12:04 Rolldown’s speed and performance. OXC Allocator. 15:09 Dealing with massive buildtimes. 17:42 How has the transition been? 20:34 Why do we even need a bundler? 23:25 Vite’s superior developer experience. 26:01 Fullstack Vue? 31:45 Node and Vite’s relationship. 35:41 Wes’ wishlist. vite-dir. 37:28 Hot takes. 37:37 Would Next be better with Vite? 41:09 Thoughts on React Server Components. 43:40 Thought on Remix 3. 46:22 Tell us about Void0. 51:36 Sick Picks + Shameless Plugs. Sick Picks Evan: Laravel Lamborghini Shaped Stress Toys Shameless Plugs Evan: Viteconf, Vite, CultRepo. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  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. And we have Evan Yu on. He's the creator of Vue, creator of Veet, 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.

• 0:30Speaker 01

  Yeah, excited to be here.

• 0:31Wes Bos?

  So, real quick, before we get into it, for the like six people who haven't done it, give us the introduction of who you are and what you do and kind of your background.

• 0:41Speaker 01

  Sure, yeah. So, I had been an independent open source developer for over a decade, like since 2015, 16-ish. Two years ago, I founded a company called Void Zero, 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, Veet, probably some people use it, some people know it. But yeah, now I'm mostly focusing on Void Zero and the Veet side of things.

• 1:18Scott Tolinski?

  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 Veet. Did you see yourself making that change from working on the UI code to a tool chain?

• 1:37Speaker 01

  Um, 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 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 built stuff, I'm like, these tools kind of, you know, it's kind of clunky. What about I build a

• 2:18Speaker 01

  framework for myself? And as I build frameworks, I just kind of dig, dug deeper and deeper. It's a wormhole.

• 2:28Wes Bos?

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

• 2:37Scott Tolinski?

  And this might be a weird comment, but, uh, 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, uh, looking JavaScript framework, right? Like, yeah, it's, it's hard to describe many JavaScript frameworks as like looking nice just in a code context. But I, I wonder like how much of that is informed just by your aesthetic awareness?

• 3:08Speaker 01

  It, it definitely played a role because, uh, I think I probably put more effort into the documentation than the average developer who made frameworks. Uh, so that probably helped with, uh, definitely helped with the initial adoption of Vue.

• 3:24Wes Bos?

  We were asking that, um, when we had the, Daniel from Nuxed on, we're just like, look, why is everything in this whole Vue, Vite kind of associated ecosystem? Why is everything so, so polished and, and so simple? And, and even to extend it, um, 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.

• 4:01Speaker 01

  Yeah, I, I think, um, interestingly, because I initially got into web development from a non-engineering back, background, right? So, uh, 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

• 4:44Speaker 01

  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, uh, you know, aligns with a lot of people who um, come into web development from other backgrounds too. Cause uh, 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.

• 5:24Wes Bos?

  Mm hmm. Yeah. I I agree with that, but like if I were to go off and and maybe create V, um, like I I feel like I know the entire V API, you know, I've I've built several lower level plugins in it. I've built very complex, um, like I've migrated old apps that were in Parcel and Webpack and and brought it into one. And I I use the Web Socket Proxy API, like I feel like I know the entire V 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.

• 6:07Speaker 01

  Stuck to have it, yeah. We made most, uh, funny story, we made the biggest breaking change between V to one and V two. Cause uh, if if if you followed along the early days of V, like we came all, we 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 uh, Rich was the original author of Rollup, which a lot of the V's plugin API is based on top of. Right? And uh, V to one did not have a plugin system. The view logic in V one was like hardcoded. It wa- it was around that time I started to think about like,

• 6:50Speaker 01

  production build, we were using Rollup, so we were using Rollup plugins. I was like, can we make the Rollup plugins work for the dev server too? And then I found out, uh, Jason Miller actually did it in his project called WMR. He, he did this like Rollup plugin simulator that is able to just run Rollup plugins without actually running Rollup itself. So that inspired me to essentially say, okay, let's use this for Veet. So we can have the same plugin system for the dev server and the production build. Right? Um, I had to rewrite the whole thing and that became Veet 2. So we never actually shipped Veet 1.

• 7:30Wes Bos?

  Oh.

• 7:32Scott Tolinski?

  And if you want to see all of the errors in your application, you'll want to check out Sentry at 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 forward slash syntax. Again, we've been using this tool for a long time and it totally rules. All right.

• 7:56Wes Bos?

  Let's talk a little bit about the whole roll up and, and roll down, um, and how that works. So like, like Veet is built on top of uh, so another tool, um, and then you have recently rewritten that tool?

• 8:09Speaker 01

  Yep. So it's, it's no longer Technique Rewrite because, uh, originally the name is Roll Down because we're like, okay, this is going to be a Rollup port. We're just gonna straight up port it.

• 8:20Wes Bos?

  Yep.

• 8:21Speaker 01

  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, uh, going with an architecture that's more similar to ES Build than Rollup.

• 8:40Speaker 01

  And the feature scope also is more like ES Build than Rollup. So Rollup itself, the core is very lean. It relied mostly on plugins. 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? ES Build kind of just does all of this out of the box. You don't need to use a plugin just to transpile TypeScript. So Rodeau is essentially implemented in Rust. It, a lot of stuff work out of the box, TypeScript, JSX, node module resolving. But the API is Rollups. So we support Rollup plugins. It's a Rust bundle, but we support JavaScript plugins.

• 9:21Speaker 01

  So if you have a Rollup plugin that's written in JavaScript, it will actually just work in Rodeau. So yeah.

• 9:30Wes Bos?

  How does that work?

• 9:32Speaker 01

  It relies on something called a project called NAPI RS. So Node.js has this thing called NAPI that allows you to basically do cross-language calls.

• 9:44Wes Bos?

  Yeah, native API, right? That's what the N is?

• 9:46Speaker 01

  Yeah. So NAPI RS is a project that's, that's, 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.

• 10:01Wes Bos?

  Okay. And we had the TypeScript folks on. And so 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 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 what's the, why didn't you pick Go for that?

• 10:28Speaker 01

  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. Uh, and people have worked on things like SWC and OXC. OXC, uh, these are like low level language tool chains that gives you like parsers and transformers, uh, stuff like that. So when we build a bundler, we got to think about like, what do we build on top of?

• 11:12Speaker 01

  And in terms of like this layer, uh, Rust actually has a better ecosystem compared to Go. And a final important consideration is, uh, 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.

• 11:27Wes Bos?

  Hmm, okay. Yeah. Interesting. Yeah, I never thought about that, but yet it needs to run in a JavaScript runtime. Uh, and, and you do that with WebAssembly?

• 11:37Speaker 01

  When, when we run it with 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, uh, I think QuickJS, they just migrated their playground from roll up to roll down. It's, it runs in the browser and it made their playground through to four times faster.

• 12:04Wes Bos?

  Wow.

• 12:04Scott Tolinski?

  With, with roll down, so since it is a, a port to an extent, a 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? And, uh, where that speed shows up? And then what choices that you made actually allowed that speed to take place as a Jest Rust? Or, or can you, can you go into some of that?

• 12:36Speaker 01

  Yeah, um, so it boils, so first of all, it goes all the way down to like, what parser do you use? Right, so uh, one decision we made very early on is we bet on OXC. Uh, OXC is the language tool chain, um, it's an alternative to SWBC 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, uh, we decided to bet it on OXC before the author Bochin joined the company. So he joined us like a, like, you know, I think like half a year later.

• 13:19Speaker 01

  I tried to convince him to join, join earlier, but uh, he was like, I need to think about this. But he then he joined, so uh, that's a good thing. Um, so OXC, you know, there's, there are a few design decisions at this level. For example, uh, memory allocation, because it's actually all about like, how do you allocate memory efficiently? Like, OXC 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, the memory.

• 13:59Speaker 01

  So I, I'm actually like less familiar with this layer because it's mostly Bochin's domain. Uh, 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 uh, bundle generation strategy or more AST-generated? But most of the gains comes from a clean architecture that allows optimal parallelization. You know, uh, and the raw power of Rust itself. Some of that is indeed, uh, 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.

• 14:43Speaker 01

  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 rollup versus throwdown is like twenty to thirty times faster.

• 14:56Speaker 01

  Uh, is the, uh, the ballpark. And when it, 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.

• 15:09Wes Bos?

  That's nuts. And we had, um, why am I forgetting his name? The author of, uh, the Webpack Rust. Why am I blanking on his name? Zach. Um, we had, we had Zach, um, who is writing the, the Webpack port.

• 15:24Speaker 01

  RSPack.

• 15:25Wes Bos?

  And he was, RSPack. That's what it is. Thank you. Um, and like, I don't, I don't necessarily want to 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, cause like,

• 15:42Speaker 01

  Yeah.

• 15:42Wes Bos?

  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 the stuff at scale? Like, how, how big are they? Do you have any stories?

• 15:56Speaker 01

  Yeah, like we are actually working with Linear, uh, to help them land. Actually, they are already using Rodeo Beat. So Linear was actually using V for like, from the early beginning, they started using V in like V2 beta. And we helped them started to use Rodeo Beat, 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 were like, this is like less than we expected. So we actually took a look at the codebase. We found some bottlenecks, we tweaked the config a little bit. And then we, we realized like, they still had a, uh, cause they were using style components.

• 16:41Speaker 01

  So, um, they actually still use SBC to compile that, which means you are actually.

• 16:49Speaker 01

  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 OXC. And then they were able to get rid of the extra pass. And now the build is like seven times faster. And for a builder that scale, that's like huge, huge time save.

• 17:09Scott Tolinski?

  Yeah.

• 17:10Wes Bos?

  And like, like, how, how many minutes or seconds are we talking that it went from to two?

• 17:15Speaker 01

  Ah, 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.

• 17:29Wes Bos?

  Oh, wow. Yeah, that's, that's the difference of like, walking away to get a coffee because the build is 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.

• 17:42Scott Tolinski?

  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, replacing this massive of a part of VEET has, uh, 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, uh, if they want to, like, how, how much additional work has that generated? Like, is it, has it been a lot? Or does it, has it been relatively smooth?

• 18:15Speaker 01

  It, it's a lot of work. Like, we've been working on RODA for like, almost two years now.

• 18:21Scott Tolinski?

  Yeah.

• 18:22Speaker 01

  And so obviously, we started from zero, but like, we essentially, so when we started working on RODA, we also, uh, OXC mostly only have the poster and resolver. It didn't have the transformer part. So, uh, we actually also had to work on all, essentially replicating the whole Babel transforms in Rust on top of OXC. And then there's the minifier. Uh, we had to, uh, build a minifier that can match the compression quality of SWC, but much faster. And then, uh, the bundle, the bummer itself, there's like advanced tree shaking, because, uh, we are now matching the

• 19:05Speaker 01

  Built uh 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 uh 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 uh roll up actually, both roll up and ES build, actually kind of, they are kind of limited in terms of like chunk splitting. Like uh if you want to more fine-grained control how your app is split into different chunks of optimal sizes, right? It's a bit challenged with today's VIT.

• 19:49Speaker 01

  So that's also one thing we kind of wanted to address. So uh, so in, Rowdown actually supports the same sort of advanced chunk splitting uh configuration like Webpack does. So it gives you just much more control over how do you want to, like, how big the size, uh, the minimum size, the bit 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 ES build to bundle all 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 the new chunk splitting behavior. And now all the sites just, you know, is able to load much fewer chunks and load faster.

• 20:34Wes Bos?

  Yeah, let's, 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 ESM straight to the browser. Um, aside from like, I need TypeScript, which maybe we'll get that in uh as comments at one point in the browser. But like, is this a stupid question? Why do we even need VIT? Why do we need a bundler?

• 21:03Speaker 01

  Yeah, that, that's a good question. I think uh 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 uh 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 internal app, it's an SPA and like 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, like and and also developers, right?

• 21:43Speaker 01

  Some developers, they 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're say you're building like quick, small apps that really like, you know, a few less than like a hundred modules, right? By all means, go with native VSM, it just works really well. But if you're building anything that loads more than a thousand modules over native VSM, it's gonna be slow, right? Because browsers like even with like HTTP two or even HTTP three, like from what we tested, like

• 22:29Speaker 01

  the network overhead is a real thing that you just cannot avoid when you have too many modules. So um 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 tool like 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.

• 23:02Scott Tolinski?

  Right.

• 23:03Speaker 01

  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 DX cost.

• 23:13Speaker 01

  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.

• 23:26Scott Tolinski?

  Yeah, it does feel like it's all very, uh, from the jump DX focused and even going back to uh, Vue JS and all that stuff. I, I, 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 um, it, 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, and I think it's done such a, a good job of that.

• 23:54Speaker 01

  Thank you.

• 23:54Scott Tolinski?

  Yeah. In regards to the developer experience, many of the things that I think Veet did really well out of the gate, things like not having, you know, the effortless live reloading or just giving you, um, what was 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? Uh, like where do those ideas come from, I suppose?

• 24:27Speaker 01

  Um, 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 built Vue, initially, Vue is also just a pure client side library. So you just pulled it from a CDN and just works.

• 24:45Scott Tolinski?

  Yeah.

• 24:46Speaker 01

  Later on, as we started inventing new more, adding more stuff to the framework, uh, 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. Uh, so we actually maintained Vue CLI for a few years, which was built on top of, you know, Webpack, Babel, Jest, all these uh, stuff we've used uh, in the past and some, some probably still use today. And in dealing with these tools that kind of, you know, I just like.

• 25:28Speaker 01

  Remembered all the little paper cuts in DX I have myself. So when I started working on V, 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 view 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.

• 25:56Scott Tolinski?

  Yeah, okay.

• 25:58Speaker 01

  So that that really got me working on V. Yeah.

• 26:01Scott Tolinski?

  You know, we both have a background with Meteor and I was wondering, since you worked for the Meteor company, right?

• 26:09Speaker 01

  Yes.

• 26:10Scott Tolinski?

  They were called Meteor.

• 26:12Speaker 01

  Meteor Development Group.

• 26:14Scott Tolinski?

  Meteor Development Group, yes. Did, do you ever have the urge to get into the full stack of things with view? Considering Meteor was like well-known for handling everything, database, loading data, that transportation layer.

• 26:35Speaker 01

  Yeah, um, 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 embedded Node JS in the Meteor distribution.

• 27:17Speaker 01

  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 that Meteor was able to reach. I was actually a strong advocate back then at the company to say, let's distribute Meteor 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 rely on

• 27:52Scott Tolinski?

  I built, yeah, built them, yeah.

• 27:53Speaker 01

  Right?

• 27:54Scott Tolinski?

  Yeah, I, I remember that whole process. But I will say that there were some really great things about the Meteor package system.

• 28:00Speaker 01

  Yeah.

• 28:00Scott Tolinski?

  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.

• 28:26Speaker 01

  Yeah, I, I think like at that time, I guess I was like really MP, like Node.js pilled. I started like 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, it's, it's, it's also weird. Like I, I don't, I haven't figured that out completely myself.

• 29:05Speaker 01

  But um, I think, but my experience in Meteor was like, okay, if like at that stage of the time, if you built something that's overly monolithic and opinionated, right? Then you just have a huge risk of not reaching enough people. So that's why when I, I had a, I coined 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 pick 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.

• 29:47Speaker 01

  We added a build tool, we added state 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.

• 30:02Scott Tolinski?

  Yeah, yeah, you know, I think that I, I do wonder where Meteor would be today had a 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 remember, um, 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.

• 30:29Speaker 01

  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 NextJS came out, like Sebastian, who's the author of Nux, created Nux a few days later. Right? I was like, yeah, like someone is working on it already, so I'll, I'll let them do their thing. Uh, 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 Nux was, you know, the Nux team, they built great things.

• 31:14Speaker 01

  So, uh, 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. Right? Obviously we had 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 view core. And, you know, so we had this like nice layer of like abstraction where we just focus on different layers of things.

• 31:45Wes Bos?

  Mm hmm. Um, let's talk about node for a bit. Um, and like, look what Veet's relationship to, to node. Because like if, 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. Um, I know there's like Veet 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 Veet app dot 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?

• 32:20Speaker 01

  It is so Environment API essentially is the lower level abstraction that allows you to do something like that. So um let's see, when you use V Test or you or you you when you use a V based full stack meta framework like maybe ten stack start or like spellkit, right?

• 32:38Wes Bos?

  Waku, Waku, yeah.

• 32:40Speaker 01

  They they leverage Environment API or V's um previously, there is an API called SSR load modules. But they essentially do the same thing. They essentially take the source code, process it with V'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 write in node or in in Bun or CloudFlare or workers, the the renderer, the local version of it. Right, so um that. Yeah, surprisingly, we never built an API to allow you to just like call it from the CLI, which is something I've wanted to do for a while,

• 33:25Speaker 01

  but just never actually did. But um we are actually thinking about something like that, actually. So uh make it easier for you to essentially say, here's a because right now, most people think of V as a front end uh build tool, right? The entry point is the HTML and everything assume is assumed to like run in the browser by default. Uh 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 an Express server or or custom Node.js process on the side. So we want to make that simpler. So uh we're actually uh experimenting with something that allows you to run.

• 34:10Speaker 01

  Maybe a server dot E S and the index html together. Just beat that beat build and it's just like runs the two things in parallel. Yeah.

• 34:19Wes Bos?

  Yes, please. I want that because 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, um, you gotta throw a watch in there. It 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 like it deletes the required cache, uh, just so that I don't have to restart my server.

• 34:51Wes Bos?

  When something has changed, I just like, I would just love node V for this type of stuff.

• 34:56Speaker 01

  There are a few libraries, like, uh, I think TSX and like Giddy that kind of does that.

• 35:02Wes Bos?

  Yeah, that's what I'm using.

• 35:04Speaker 01

  Uh huh. Yeah. But environment API, I guess, like having it built into the, the nice thing is you know that the same code base 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. Uh, so you just have less, fewer surprises. Uh, and environment API also gives you a bit more, um, I guess it's actually hot module placement for server side code. So you can actually have like a, you can update a handler, uh, without restarting your service side process. And next visit, it actually is calling the updated handler.

• 35:41Wes Bos?

  Yeah, that's exactly what I want. Yeah. Please make that happen. This is my, um, this is the only reason we're having you on today is I'm asking you to make that.

• 35:48Speaker 01

  That's good validation. That's good validation. Yeah.

• 35:51Scott Tolinski?

  Yeah, Wes loves giving a wishlist to the guests.

• 35:54Wes Bos?

  Yeah, yeah. Now that I have you here, uh, allow me to just to ask you for my list of things. Oh, also I want, um, you know, like in the old PHP days, I'm, I'm, I'm going to use all your time here for wishlist.

• 36:06Scott Tolinski?

  Yeah.

• 36:07Wes Bos?

  The old PHP days where you just get a directory of files. I built a plugin called Veeter 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 dot HTML, you have to manually type it in. So I built like a little, um, 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 V would do by default.

• 36:42Speaker 01

  It's almost like like a default HTTP server, some HTTP server.

• 36:47Wes Bos?

  Yeah, exactly.

• 36:48Speaker 01

  Exactly. I see. Okay.

• 36:49Wes Bos?

  Exactly.

• 36:50Speaker 01

  Interesting.

• 36:50Wes Bos?

  It just brings me back to the the PHP days where you just click the file and that file will run.

• 36:55Speaker 01

  Did you open source that plugin?

• 36:57Wes Bos?

  Yeah, yeah, it's you can NPX V V NPX Vite and it will it will fire up just a V with you right there. But I um, I would love for that to be built it.

• 37:08Scott Tolinski?

  It is nice. I do find myself using it a lot, Wes.

• 37:10Wes Bos?

  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 now.

• 37:28Wes Bos?

  Let's get 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 you're not comfortable with it, but um.

• 37:38Scott Tolinski?

  Would next JS be better with V?

• 37:40Wes Bos?

  Yes.

• 37:42Speaker 01

  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 want to move next on to V, 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.

• 38:23Speaker 01

  For the existing users, right, there are so much like so much behavior that's just coupled to the way that things work inside NextJS. So moving it to a completely different build tool, especially when the VIT's default like development behavior is unbundled. Right? So there are just like so many places things can go wrong. And, um, you know, the chance of pouring it over to VIT and then having existing production NextJS app just work on that new version is very slim. Or you would have to like spend years to make it work. So, uh, unfortunately, uh, it's, it's very difficult to make that happen. But, uh, we did actually prototype something that's like VIT on Next on VIT.

• 39:08Speaker 01

  And we were able to like even get, uh, React Server Components working. We're able to get the, uh, the next fifteen app router demo to maybe ninety percent of features working. Obviously, it was still kind of rough, uh, but

• 39:23Wes Bos?

  Yeah.

• 39:24Speaker 01

  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 NextJS, but uh, I think that gave us a lot of like insights on how React Server Components should work with VIT. So that kind of led to the current, uh, VIT RSC plugin.

• 39:43Wes Bos?

  And yeah, I, cause I've used the TurboPak 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, oh, just use V, 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 plugin 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.

• 40:16Speaker 01

  Yeah, that's why TurboPak, that's why TurboPak took so long. Uh, I think it's a bit, you know, when they decided to just build something completely different from WebPak 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, uh, they just had to double down.

• 40:41Scott Tolinski?

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

• 41:04Speaker 01

  Beat was like 2020. Yeah, just five years ago.

• 41:08Wes Bos?

  Okay. Uh, let's talk about React server components. Like, do you have any opinions on React server components?

• 41:17Speaker 01

  I do. Um, so at the very high level, you know, I think it's kind of under delivered. Right? Um, okay. I think the biggest problem is just the, the promised gain and the ink and the, uh, 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, uh, in next to yes, is kind of two different things. Right? So there are probably simple, simpler ways for you to use RSC. But because the, the design and implementation of RSC is just so tightly coupled with next to yes. Uh, the, right now, the mainstream way of people to use RSC is really through next to yes.

• 42:02Speaker 01

  So the use server, use client directives and the mixed RSC graph. Uh, 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 the server or wrong 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 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, uh, 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.

• 42:46Speaker 01

  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. So.

• 43:00Speaker 01

  Yeah, you can't you can't call me a skeptical, alright. Like, obviously, I I have, you know, when I talk about NextJS, R I C, 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 R I C objectively, I just don't feel like it delivered what it promised to deliver, right? And that is also one of the reasons why a few just don't, won't do something like that. We just felt like, like, we don't, we don't want to do it just because React does it.

• 43:39Wes Bos?

  Beautiful. And what about any thought? We don't know what it is yet, but Remix 3, 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? Um, I guess templating language, we'll see.

• 43:58Speaker 01

  Yeah, I I honestly, I know, I don't think I know enough about it to make a judgment at this moment, right?

• 44:04Wes Bos?

  Yeah.

• 44:05Speaker 01

  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, uh, like, I know they're smart people, right? They might be on to something, but, you know, the the information I'm given, I'm not super optimistic about the, uh, the eventual, like, say, will it, like, be 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.

• 44:41Wes Bos?

  Mm hmm. 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 nut, simple thing, similar to how people love Liquid for Shopify, because it's, it's so simple. Um, 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.

• 45:19Speaker 01

  So are you saying it's more geared towards like AI auto generating storefront code?

• 45:24Wes Bos?

  I think they're trying to build an API that is friendly for that. LLM 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.

• 45:49Speaker 01

  I see. But would it be equally friendly to humans? I'm actually starting to think, you know, what is friendly to humans not

• 46:00Wes Bos?

  Yeah.

• 46:01Speaker 01

  may not be fundamentally friendly to AI agents and vice versa. Now, so yeah, I'm curious. So

• 46:08Wes Bos?

  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. Um, Void Zero, your company, um, what do you, what do you do to make money? How do you, why did you start a company behind a JavaScript bundler?

• 46:33Speaker 01

  Well, it's, I mean, we're, we're framed as like the, the tool chain, not just the bundler, right? So there's a the whole set of underlying parser, transformer, resolver, and then there's the bundler, there's need to build tool. We just kind of get a survey 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, linkers, formatters. So we want to put these things together into a sort of managed solution. Right now it's named V plus. Uh, we're gonna talk about more details of V plus at VITConf, which is happening in next month, October 9th and 10th in Amsterdam.

• 47:18Speaker 01

  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 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 VIT in your patch manager config and you can start using it. So it's the same VIT, same, it's a dropping superset. VIT dev, VIT build, still work exactly the same way, but then you can additionally just do VIT linked, VIT test.

• 47:59Speaker 01

  Uh, and it's built on the existing solutions that you're already familiar with, except they are now used, they now use a centralized configuration so that they also understand how each other works out of the box.

• 48:14Wes Bos?

  And is part of that a, like a shared build cache as well? For, for people who need to like have, have huge builds?

• 48:25Speaker 01

  There are a build caching capability built into the tool chain. Uh, remote caching will most likely be implemented. Uh, 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. Uh, that's one possible outcome, but you know, our short term, uh, so my personal hope is we can, uh, essentially monetize the tool chain itself by, uh, having these bigger companies, uh, essentially pay for the advanced features to subsidize the use of the tool chain itself to individuals or open source of smaller companies.

• 49:09Scott Tolinski?

  Wow, wow, it's exciting. And this has got me really excited for, uh, Vietcong. So man, that's, that's coming right up here. Yeah. Are you excited to head out to Amsterdam?

• 49:20Speaker 01

  Yeah, I mean, the only downside is I've been to the city so many times.

• 49:25Scott Tolinski?

  Yeah.

• 49:25Speaker 01

  Because we, yeah, we have like.

• 49:27Scott Tolinski?

  JS Nation, yeah, yeah.

• 49:29Speaker 01

  Yeah.

• 49:30Scott Tolinski?

  Yeah. Yeah, it's a great place for conferences, though. They, they, uh, they do a great job.

• 49:34Speaker 01

  Yeah.

• 49:35Wes Bos?

  Love that.

• 49:37Speaker 01

  Yeah, we have a very, very exciting lineup, like Rich Harris is gonna be there, Ryan Condiaro is gonna be there. Uh, Matt Bieleman, uh, Eric, uh, from Stackblitz. So, yeah, a lot of, uh, smart people.

• 49:52Wes Bos?

  Tanner Lindley, Johann Schickling, yeah.

• 49:55Scott Tolinski?

  Yeah, it's a, it's a stack lineup for sure, yeah.

• 49:58Wes Bos?

  Anthony Foo, we've been, we want to get him on the podcast as well, man. He's, he's prolific. What's, what's he like? How, you, you probably know him better than I do, but like.

• 50:08Speaker 01

  Yeah.

• 50:08Wes Bos?

  Prolific dev, cranking out everything.

• 50:11Speaker 01

  Yeah, he, he just moved to Japan, uh, a while ago. Uh, he's, uh, now kind of in a transition period. Uh, but we're actually, uh, having him work on the new, uh, GUI dev tools for Vite as well. So there's gonna be, uh, a GUI interface dev tool that, kind of like, I don't know if you've, you, uh, you've seen Nux Dev Tools. That's what he built. He built that too. Alright, so, uh, we want to have that in Vite, which allows you to inspect like, uh, how a module is transformed. He previously built a thing called V-Plugin Expect. Uh, yeah, like, he just built so much stuff.

• 50:53Scott Tolinski?

  And it's all beautiful, yes.

• 50:55Speaker 01

  Yeah, exactly. Yeah, he's, he's a, also a design engineer at heart, so, um.

• 51:00Scott Tolinski?

  Yeah, totally.

• 51:01Speaker 01

  He actually has a very, uh, he has a talk called Yak Shaving. Uh, essentially talks about how he, uh, 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?

• 51:19Scott Tolinski?

  Hmm.

• 51:20Speaker 01

  Uh, and that just ends up leading to all these different things he built.

• 51:24Scott Tolinski?

  Oh, I love his Yak map. Oh, man. He built a whole map showing his, uh, journey.

• 51:33Scott Tolinski?

  So dope.

• 51:35Wes Bos?

  Oh, that's great.

• 51:36Scott Tolinski?

  Wow, cool. Well, I think we're kind of running out of time here because I gotta take the, or at least I am. Wes, you can certainly keep this going.

• 51:44Wes Bos?

  Scott's gotta go drop his kids off. I'm in the regular time zone here. I talk forever.

• 51:49Scott Tolinski?

  Yeah, right.

• 51:50Wes Bos?

  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.

• 52:02Speaker 01

  I did not. Sick pick?

• 52:04Wes Bos?

  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 note, he picked flying a kite and going for a walk.

• 52:24Wes Bos?

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

• 52:28Speaker 01

  Okay, so I got this Lambor stress toy from Laricon.

• 52:35Speaker 01

  And it's just like so squishy. It feels so nice. I just have it on my desk ever since I came back with it. It's the best thing ever.

• 52:43Scott Tolinski?

  Man, classics dress toy.

• 52:45Wes Bos?

  That's good.

• 52:46Speaker 01

  Yeah. Shout out, shout out to Taylor. Shout out to Taylor for making this.

• 52:50Wes Bos?

  Yeah, right. 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.

• 53:02Speaker 01

  There's V plus, there's V conf. And one more important thing I want to plug is we are actually premiering the the V documentary at V conf in person.

• 53:14Wes Bos?

  Nice.

• 53:15Speaker 01

  Yeah. So that's been like a year 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 is previously the honeypot crew that made all those other tech documentaries. And yeah, we're showing it at V conf in person and it's going to also be live on YouTube afterwards. So stay tuned.

• 53:38Wes Bos?

  Sweet. I'm excited for that.

• 53:40Scott Tolinski?

  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.

• 53:49Wes Bos?

  Awesome. Well, Evan, thank you so much for coming on. Appreciate all your time. This was great to finally have you on and we'll catch you later.

• 53:57Speaker 01

  Yeah, I had a lot of fun. Thank you, guys.

• 53:59Scott Tolinski?

  Thanks, Adam.

• 53:59Scott Tolinski?

  Thanks.