Creator of Vite: Evan You  ## Metadata - Author: [[Syntax]] - Full Title: Creator of Vite: Evan You - Category: #articles - Document Note: --- tags: - #javascript - #vite - #opensource Author: Syntax FM (Interviewers: Wes Bos, Scott Tolinski) — Guest: Evan You Source: Podcast/YouTube Reference: https://www.youtube.com/watch?v=quEc5ZI3_Ys date created: 2025-09-22 12:00 --- # 🧭 Title: Evan You on Vite, Rolldown, DX vs. UX, and Building a Sustainable JS Toolchain ## 🗂️ Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment](#-deib-diversity-equity-inclusion-and-belonging-assessment) - [🧩 Logical Validity + Tone](#-logical-validity--tone) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 📚 References: Include a list of sources consulted and cited in the article. - Video: https://www.youtube.com/watch?v=quEc5ZI3_Ys - Vite: https://vitejs.dev - Vue: https://vuejs.org - Rolldown: https://github.com/rolldown/rolldown - OXC: https://github.com/oxc-project/oxc - NAPI-RS: https://napi.rs - Nuxt: https://nuxt.com --- ## 📝 Summary: Evan You traces his path from aspiring designer to creator of Vue and Vite, and now founder of Void/Void Zero building the modern JS toolchain ([0:34–1:19](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=34)). He explains how Vite pivoted from a framework-first tool to a plugin-architected dev/build system inspired by Rollup and WMR ([6:10–7:30](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=370)). The conversation dives into **Rolldown**—a Rust bundler with Rollup-compatible plugins, leveraging OXC and NAPI-RS for speed, WASM portability, and ergonomic JS interop ([8:10–10:02](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=490), [12:00–13:18](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=720)). Real-world gains include 3–16× faster builds, with case studies like Linear and Framer ([15:01–17:06](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=901), [19:54–20:34](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=1194)). Evan contrasts native ESM vs. bundling for scale and makes the **DX→UX** case for tooling ([21:00–23:26](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=1260)). He critiques RSC’s complexity vs. payoff ([41:12–43:28](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=2472)), previews Vite’s **Environment API** and future “run server + client together” experience ([32:20–34:18](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=1940)), and outlines **V+**: an enterprise-friendly, cohesive toolchain with shared config and caching ([47:00–49:09](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=2820)). The episode closes with community shoutouts and a Vite documentary teaser ([53:07–53:37](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=3187)). --- ## 📖 Main Content: **Origin story & design sensibility** — Evan’s non-traditional path (designer → builder) shaped Vue’s aesthetics, docs polish, and API simplicity ([1:54–5:23](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=114)). Vue’s “progressively adoptable” philosophy emerged from lessons at Google (Angular’s heavy concepts) and Meteor’s monolithic constraints ([4:01–5:21](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=241), [26:00–30:02](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=1560)). **Vite’s pivot & plugin architecture** — Early Vite was framework-tied; inspired by Rollup + WMR, Vite 2 unified dev + build via a Rollup-like plugin interface (V1 never shipped) ([6:10–7:30](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=370)). **Why Rust (Rolldown) over Go** — Team skill, richer JS tooling crates (SWC/OXC/oxc-ecosystem), and superior Rust→WASM story for browser runtimes ([10:02–12:02](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=602)). Rolldown = Rust core + Rollup plugin API, using NAPI-RS for JS↔Rust interop ([8:59–10:02](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=539)). **Speed sources** — OXC’s arenas and performance-first parser, parallelized pipeline (inspired by esbuild), and eliminating extra transform passes (e.g., styled-components) deliver 3–16× real-world speedups; simple bundles can be 20–30× faster than Rollup ([12:37–15:10](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=757), [16:56–17:29](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=1016)). **Chunk splitting quality** — Rolldown aims for Webpack-like fine-grained control (min/max sizes, vendor grouping) to reduce chunk counts and improve load (Framer case) ([19:54–20:34](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=1194)). **When bundlers matter** — Native ESM is great for small apps (<~100 modules); large apps suffer network overhead even on H2/H3. Vite’s goal: minimize DX cost so teams accept complexity that yields better UX ([21:00–23:26](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=1260)). **Server-side story** — Vite’s **Environment API** lets the same transform/resolve pipeline run in Node, Bun, or Workers; path to “run server.ts + index.html” together with HMR for server handlers ([32:20–34:18](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=1940), [35:41–35:51](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=2141)). **RSC skepticism** — Mixed server/client trees add mental overhead, divergent constraints, and unclear net wins; Vue won’t copy features without clear value ([41:12–43:39](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=2472)). **Sustainability** — **V+** packages parsers, transformers, bundler, devtooling, test runner, linter/formatter with shared config, free for OSS/individuals and paid features for enterprises; possible remote caching; announce at ViteConf (Amsterdam) ([47:00–49:09](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=2820)). ### 🗒️ Notes - **👋 Intro & background**: Evan You’s journey; founding Void Zero to build JS toolchains ([0:34–1:19](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=34), [0:55–1:19](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=55)). - **🎨 Design → DX**: Vue’s polish tied to Evan’s designer mindset; docs and API ergonomics drive adoption ([2:37–3:23](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=157), [3:58–5:06](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=238)). - **🧩 Vite architecture**: Pivot to Rollup-like plugins; WMR inspired rollup-plugin simulation ([6:10–7:30](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=370)). - **🦀 Rolldown**: - Why Rust: team proficiency, crates, WASM ([10:02–12:02](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=602)). - API: Rust core + Rollup plugin compat via NAPI-RS ([8:59–10:02](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=539)). - Browser story: Qwik’s playground saw ~3–4× speed in-browser with WASM build ([11:56–12:06](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=716)). - Perf: 20–30× on simple bundles; 3–16× on apps; Linear 3×→7× after removing extra pass ([14:48–17:06](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=888)). - **🧠 Architecture & OXC**: - Parser/arena allocation, parallel phases, esbuild-inspired pipeline ([12:37–15:10](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=757)). - **📦 Chunking**: - Webpack-like chunk-splitting controls, Framer migration for fewer chunks/faster loads ([19:54–20:34](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=1194)). - **📡 Do we need bundlers?**: Native ESM vs. thousand-module apps; DX cost vs. UX payoff ([21:00–23:26](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=1260)). - **🧪 Environment API**: - Run code in Node/Bun/Workers with Vite transforms; towards server HMR; CLI unification desired ([32:20–35:41](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=1940)). - **🧱 Meteor → Progressive Framework**: - Anti-monolith lessons; Vue as incrementally adoptable; Nuxt takes full-stack mantle ([26:00–31:34](https://www.youtube.com/watch?v=quEc5ZI3_Ys&t=1560)). - **⚛️ RSC critique**: - Complexity, “use server/client,” mixed grap - Summary: 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.🔥 Be the ~14,700th person to join our super tasty newsletter https://bit.ly/syntax_snackpack Show Notes 00:00 Welcome to Syntax! 00:31 Who is Evan You? 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? 12:04 Rolldown’s speed and performance. 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. 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. All links available at https://syntax.fm/939 ------------------------------------------------------------------------------ Hit us up on Socials! Syntax: https://x.com/syntaxfm Scott: https://x.com/stolinski Wes: https://x.com/wesbos CJ: https://x.com/CodingGarden Randy: https://www.youtube.com/@randyrektor http://www.syntax.fm Brought to you by Sentry.io #webdevelopment #webdeveloper #javascript #syntax #syntaxfm #webdev - URL: https://www.youtube.com/watch?v=quEc5ZI3_Ys Welcome to Syntax. Today we have the goat, the the man who has made web development easier for the entire world. Um probably kept people in the career uh before they had Rage Kit. We have Evan Yu on. He's a creator of Vue. Um creator of Vit, 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, g give us an introduction of of who you are and what you do and kind of your background. >> Sure. Yeah. Um, so I had been a independent open source developer for over a decade like since 2015 16ish. Two years ago, I founded a company called Voice Zero, which is centered, you know, with a with a mission to uh to build open source tool chains for JavaScript. Yeah, before that I created Vue, Vit. Uh probably some people use it, some people know it, but um >> yeah, now I'm mostly focusing on uh Voy Zero and the feed side of things. >> Yeah. So I think the one of the um interesting things for me was that you were primarily known as like a framework author uh prior to VIT. Uh >> did you see yourself making that change from working on the UI code tool chain? >> Um not really. So I would say a lot of the the decisions of like what 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. >> Mhm. >> 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. um and somehow got more into uh 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 framework for myself? And as I built frameworks, I just kind of dig duck deeper and deeper. It's a wormhole. Yeah, >> 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. >> 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 that I wonder like how much of that is informed just by your aesthetic awareness. >> It it definitely played a role cuz uh I think I probably put more effort into the documentation than the average developer who made frameworks. >> Um so that probably helped with definitely helped with the initial adoption of view. We were asking that um when we had the Daniel from KNX on. We're just like like why is everything in this whole view 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. >> 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 u 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 web page, right? So in a way this like not having prior experience in serious engineering actually allow me to just focus on the minimal subset of things that I really cared about like what is the simplest API that I can design for myself to 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 because 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 >> I I agree with that but like if I were to go off and and maybe create Vit um like I like 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 websocket proxy API. Like I feel like I know the entire Vit 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? was just like, "Oh, the new version's out. >> Stuck to it." >> Yeah. Made most >> uh funny story, we made the biggest breaking change between V1 and V2 cuz uh if if if you followed along the early days of Vit like we came all the we we went all the way to like 1.0 RC on 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 Rolup which a lot of the Vit's plugging API is based on top of right >> and uh V1 did not have a plug-in system the view logic in V1 was like hardcoded >> it it was around that time I started to think about like 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 plug-in 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 Vit so we can have the same plug-in system for the dev server and the production build right. Um, I had to rewrite the whole thing and that became V2. So, we never actually shipped V1. >> Oh, and if you want to see all of the errors in your application, you'll want to check out Sentry at centry.io/sintax. 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 centry.io/sintax. Again, we've been using this tool for a long time and it totally rolls. All right, let's talk a little bit about the whole roll up and and roll down um and how that works. So, like like Vit is built on top of another tool um and then you have recently rewritten that tool. >> Yep. >> So, it's it's no longer technically a rewrite because uh originally the name is rowdown because we're like, okay, this is going to be a role port. We're just gonna straight up port it. >> Yeah. >> 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. Um and the feature scope also is more like ES build than rollup. So um 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 plug-in just to transpile TypeScript. So uh rowdown is essentially uh implemented in Rust. It a lot of stuff work out of the box. TypeScript, JSX, uh, Node module resolving, but the API is roll-ups. So, we support rollup plugins. It's a Rust bundler, but we support JavaScript plugins. So, if you have a rollup plug-in that's written in JavaScript, it will actually just work in ROA. So, yeah, >> how does that work? >> It relies on something called uh a project called uh NAPI RS. So, uh, Node.js JS has this thing called N API that allows you to basically do cross language calls. So >> native API, right? That's what the N is. >> Yeah. So NAPI RS is a project that's uh that's a that aims to make it easier for you to write some Rust code and uh auto automatically generate the binding so you can call the Rust code from JavaScript and vice versa. >> Okay. and we had the TypeScript folks on um and so we have to ask this question of like why didn't you use Go versus Rust. Um 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? >> 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 forjs there's there are a lot of crates uh and uh people have worked on things like swc and oxc ox 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 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 web assembly story of Rust is much better than Go's. >> Oh, okay. >> Yeah. >> Interesting. Yeah, I never thought about that, but yet it needs to run in a JavaScript runtime >> and and you do that with web assembly >> when we run it with Node.js or bun, you know, it's actually the Rust compile rust binary, but if you want to run in the browser, it has to be web assembly. So that's the distinction. So the row down web assembly build runs in the browser. actually uh I think quickjs they just migrated their playground from rollup to roll down >> it's it runs in the browser and it made their playground through to four times faster. >> Wow. With with rolldown so since it is a a port to an extent a rewrite or evolution you could say I' 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 rolldown in uh where that speed shows up and then what choices that you made actually uh allowed that speed to take place? Is it just Rust or or can you can you go into some of that? >> 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 S SWC essentially right so it has its own parer and I was evaluating the existing solutions and I just found OXC to be very very fundamentally performanceoriented in its design in a lot of aspects actually uh we decided to bet it on OXC before the author Bian joined the company so he joined us like a like you I think like half a year later I tried to >> convince him to join join earlier but uh he was like I need to think about this but he eventually 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 oxy uses something called arena allocator which means the whole a is like allocated in a con consecutive chunk of memory so you have like less fragmentation and you can drop the whole thing all together instead of being having to like more fine grain management agement of the the memory. >> So I I'm actually like less familiar with this layer because it's mostly motion 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 stringbased uh bundle generation strategy or more a 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 uh ES builds the design the pipeline design S 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 would see if it's just like a simple JavaScript bundle compared between say rollup versus rolldown is like 20 to 30 times faster 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. >> 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? Zack. Um we had we had Zach um who is writing the the Webpack port Rust 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 Bite Dance that are just hours, you know, they're just gargantuan, you know, cuz like my our little websites, they build in in a minute or so, you know, and that's that's relatively fast. But like like what do you what do you see when you talk to people who are running the stuff at scale? Like how how big are they? Do you have any stories? Yeah, like we are actually working with linear uh to help them land actually they're already using roadown vit. So linear was actually using vit like from the early beginning. They started using V in like V2 beta >> and we helped them started to use Rodown V which is still in experimental status but >> the first pass their whole build they generate like 20 megabytes of JavaScript and they got the build three point times faster on CI and we're like this is like less than we expected. So we actually took a look at the codebase. We found some bottlenecks. We tweaked the config a little bit and then real we realized like they still had a uh cuz they were using style components. So um they actually still use SBC to compile that which means you are actually uh 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 build of that scale that's like huge huge time saving. >> Yeah. >> And like like how how many minutes or seconds are we talking that it went from to two? >> Uh I only remember the like the how many times it was faster. can't remember the exact minutes, but like it was definitely like >> minutes like 10 minutes down to like one or two. >> Oh wow. >> Yeah, that's that's the difference of like walking away to get a coffee cuz 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. >> Yeah. How has this transition gone? It's from an outsers's perspective, it seemed like for replacing, even if it's not like for everyone, replacing this massive of a part of Vit 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 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 zero but like we essentially so when we started working on Rodown we also OXC mostly only had the poser 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 bundler itself there's like advanced tree shaking cuz uh we are now matching the built uh tree shaking capability and output out output quality of webpack right is slow but 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 rollup actually both rollup and ES build actually kind of they are kind of limited in terms of like chunk splitting like um if you want to more fine grainly control how your app is split into different chunks of optimal sizes, right? It's a bit challenged with today's VIT. So that's also one thing we kind of wanted to address. So uh so in ROD 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 maximum size do you want to put these libraries in a specific chunk etc. So we implemented that in collaboration with framer. Framer was previously using ESB 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 spinning behavior and now all the size 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 shift ESM straight to the browser. Um, 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 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 an internal app, it's an SPA and like your users maybe like they're okay with waiting for like 3 seconds for it to load 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're say you're building like quick small apps that really like you know a few less than like a 100 modules right by all means go with native ESM it just works really well. But if you're building anything that loads more than a thousand modules over native VSSM, it's going to be slow, right? Because browsers need like even with like HTTP2 or even HTTP3, 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, um if you just put it over the network, right, it's going to load slow. So if you really care about performance, care about like loading your website or app fast, then you just got to optimize it and if the tool right so then it comes to a question of like tradeoffs are you willing how much complexity is the tooling introducing to your workflow compared to the eventual benefit like performance benefits you're getting. So this becomes kind of a DX versus UX problem, right? So I guess what we're doing here with Vit 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 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. >> Thank you. >> Yeah. In regards to the developer experience, many of the things that I think Vit did really well out of the gate, things like not having, you know, the effortless live reloading or um 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 >> 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 uh 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 >> uh later on as we started inventing new more adding more stuff to the framework uh we started having like single file components we started start 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. Um, so we actually maintained Vue CLI for a few years which was built on top of you know Webpack, Babel, just 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 remembered all the little paper cuts in DX I had myself. So when I started working on video, it was literally out of frustration with my own experience. Uh 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 like download megabytes of node modules >> and wait for it to boot up >> and I was like there's got to be a better way for this. >> Yeah. No kidding. >> So that that really got me working on the Yeah. you know, we both have a background uh with Meteor and I was wondering since you worked for the Meteor company, right? Uh they were called Meteor um >> Meteor Development Group. >> Meteor Development Group. Yes. Uh 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 uh loading data that transportation layer. >> 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 uh what I experienced in Meteor was um they decided to essentially treat Node.js 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 media 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 that media was able to reach. I was actually a strong advocate back then at the company to say let's distribute media as a set of npm packages. >> So we don't need to do our own package manager. We don't need to we actually Meteor actually had to maintain their own like build farm for people to build Meteor plugins >> like if you just rely on Yeah. I built them. Yeah. >> Right. So I I remember that whole process. But 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 uh developer tooling I I I don't know if that's the best way to do things uh 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 uh 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 no.js pill. I started like publishing my own packages on npm. I was like >> like look we should just like put these little packages together. Unix philos philosophy you know. 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 also weird like I I don't I haven't figured that out completely myself but um >> I think but my experience in media was like okay if like at that stage of the time if you were built something that's overly monolithic and opinionated right then you just have a huge risk of not reaching enough people >> uh so that's why when I I have a I coin a term called the progressive Ive 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 Laraveville community pick it up that's all they needed they don't want anything else >> right uh but then we added additional things like this single page application router we added a build tool we added stage 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 uh they listened to some of the things that you were saying. I I cuz I do feel like that was such a huge huge reason and then that I remember um the conversations in the message boards at that time about supporting things other than [ \_\_ ] and then >> led to them focusing on things like Apollo and GraphQL and that was kind of the uh beginning of the end right there. >> Mhm. >> 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? Uh I think when Nex.js JS 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 I'll let them do their thing uh in a way I was happy that cuz >> 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. 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. >> Mhm. Um let's talk about node for a bit. Um and like like what V'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 Vit 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 Vit app.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 so environment API essentially is the lower level abstraction that allows you to do something like that. So um let's say when you use V test or you you use a Vbased fullstack meta framework like maybe tan stack start or like swell kit >> right >> wu wacku >> they they leverage environment API or vit 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 vit's transform and resolve 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 in node or in in bun or cloudflare workers the the Wrangler the local version of it. 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 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 cuz right now most people think of Vit 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 uh, annoying for most average users, or you have to start like express server or or custom Node.js 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 maybe a server.ts and the index html together. Just v build and it just like runs the two things in parallel. Yeah. >> Yes, please. I want that because >> like I 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 got to throw a watch in there. It got to restart the server every time. Like I just want hot hot reloading for for my modules. And there are like >> I have some ugly hacks that like has still has to use common.js JS and like it deletes the require cache uh just so that I don't have to restart my server um when something has changed and I just like I would just love >> node V for this type of stuff. >> There are a few libraries like uh I think tsx and like jitty that kind of does >> that's what I'm using. >> Mhm. Yeah. But environment API I guess like having it built into V the nice thing is you know that the same codebase 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 replacement for serverside code so you can actually have like a you can update a handler uh without restarting your serverside 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 um this is the only reason we're having you on today is I'm asking you to make that. >> That's good validation. That's good validation. Yeah. >> Yeah. Wes loves giving a wish list to the guests. >> Yeah. It's like now that I have you here, >> allow me 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 a wish list. >> The old PHP days where you would just get a directory of files. >> Um I built a plugin called VDR 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 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, um that's always one thing that I wish V would do by default. >> It's almost like uh like a default HTTP serp. Okay. >> Exactly. Interesting. Just brings me back to the the PHP days where you just click the file and that file will run. Did you open source that plugin? >> Yeah. Yeah, it's you can npx v >> npx v and it will it will fire up just a vit with you right there. But I um >> Okay. >> I would love for that to be built in. >> It is nice. I do find myself using it a lot. Wes, >> it it is really nice. But also I wonder like like I'm just a tutorial creator, right? Like are are people who are actually building like enterprise software >> uh need have a need for that or is it just me because I spin up so many demos every now and then? Uh, >> but that's my wish list. I'll stop now. >> Let's get Let's 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 um would NextJS be better with V? >> Yes, I would say it would. Um, true story, we actually like talked with Versel like multiple times about like I pitched it. I was like, if you guys want to move next song to VIT, we're here to help. I think at one point next team actually also really thought about it. Uh 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 going to >> it's it's too risky for them. The the short story is right. Uh they have built on top of Webpack for so long and they also invest a lot into TurboAC. So in terms like for the existing users right there are so much like so much behavior that's just coupled to the way the things work inside Nex.js JS so moving it to a completely different build tool especially when V'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 porting it over to Vit and then having existing production NexJS app just work on that new version is very slim or you would have to like spend years to make it work right so um 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 >> and we were able to like even get uh react server components working were able to get the uh the next 15 app router demo to maybe 90% of the features working obviously it was still kind of rough uh but >> like we were trying to just validate the idea to see if it's possible it end up did not you know landing in actual Nex.js but uh I think that gave us a lot of like insights on how react server components should work with V. So that kind of led to the current uh V RSC plugin. >> 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, 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 CommonJS 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 because that's why >> that's why Turbo Pack took so long. Uh I think it's a bit you know when they decided to just build something completely different from Webpack from the ground up right it's 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 um they just have to double down. >> Mhm. Yeah. I often feel bad when I uh I feel bad for Nex.js JS users that they don't get to experience the just easy speed of of Vit all the time. And when there people post about, oh, my next build is faster. I'm like, bro, uh, welcome to what, like 2018. When when did you release Vit first? >> It feels like it was a long longer than that. >> Like 2020. Yeah, just five years ago. >> Okay. Uh, let's talk about React server components. Like, do you have any opinions on React server components? I do. Um, so at the very high level, you know, I think it kind of underdelivered, >> right? Um, >> okay. >> I think the biggest problem is just the the promised gain and the in 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 Nex.js GS 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 RSC is just so tightly coupled with Nex.js, uh the right now the mainstream way of people to use RSC is really through Nex.js. 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 run on the server or wrong on the client >> and uh 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 all together 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 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 yeah uh like you can you can call me a skeptical right uh like obviously I I have you know when I talk about NexJS 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? Uh but like you know, deep down if I'm looking at RSC objectively, um I just don't feel like it delivered what it promised to deliver, right? And that is also one of the reasons why uh Vue 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. >> Beautiful. Um what about any thought? We don't know what it is yet, but Remix 3 I'm going to the conference next next uh 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. Yeah, I I honestly I know I don't think I know enough about it to make a judgment at this moment, right? Uh >> just uh just based on the information that uh Michael and uh Ryan has been has given us, I I don't know like I I feel like uh like I know they're are smart people, right? they might be on to something. But yeah, >> 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. >> 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. >> So, are you saying it's more geared towards like AI autogenerating storefront code? I think they're trying to build an API that >> is 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. >> I see. But 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. >> So, yeah, I'm I'm curious. So, >> that's a great question. Me, too. >> I love talking to people about it cuz 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? >> Well, it it's I mean we're we're frames as like the the tool chain, not just the bundler, right? So there's >> the whole set of underlying parser transformer resolver and then there's the bundler. There's V the build tool. >> V is going to 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 testr runners, llinters, formatterers. Uh >> so we want to put these things together into a sort of managed solution. Right now it's named V+. Uh we're gonna talk about more details of V+ at Vitcon which is happening in next month October 9th and 10th in Amsterdam. So in short our first attempt will just be trying to you know sell V+ because there are going to be some additional things that's more enterpriseoriented 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 and it's free to just try it out. You know, it's the same mpm distribution. You just install it, >> override vit in your uh patch manager config and uh you can start using it. So it's the same V same it's a dropping supererset Vde dev V build still work exactly the same way but then you can additionally just do VT linked V test uh 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. Um, >> and is part of that a like a shared build cache as well for for people who need to like have have huge builds? >> There are uh a build caching uh capability built into the tool chain. Uh remote caching will most likely be implemented. Uh but you know it's going to be we're not quite sure if you 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 or smaller companies. >> Wow. Wow. It's exciting. And this has got me really excited for uh Vitcom. So, man, that's that's coming right up here. Yeah. Are you excited to head out to Amsterdam? >> Yeah. I mean, the only downside is I've been to the city so many times. >> Yeah. I don't Yeah, we have like few JS Nation. Yeah. >> Yeah. Yeah. >> Yeah. It's a great place for conferences though. They they uh they do a great job. They get a lot of people conference. >> Yeah. We have a very very excited lineup like Rich Harris is going to be there. Ryan Kiara is going to be there. Uh Matt Bman, uh Eric from Stack Blitz. So yeah, a lot of uh smart people. >> Lindsley, Johanna Shickling. Yeah. >> Yeah, it's a it's a stack lineup for sure. Yeah. >> Anthony Fu, we've been we want to get him on the podcast as well, man. He's >> he's prolific. What's What's he like? how you you probably know him better than I do, but like prolific dev cranking out everything. >> Yeah, he he just moved to Japan uh a while ago. >> Uh he's uh now kind of in a transition period. Um but we're actually uh having him work on the new uh guey dev tools for VIT as well. So there's going to be uh a guey interface dev tool that kind of like I don't know if you've you've seen nux dev tools that's what he built he built that too right so uh we want to have that in vit which allows you to inspect like uh how a module is transformed >> he previously built a thing called vpl pluging inspect >> uh yeah like he just built so much stuff but >> and it's all beautiful yes >> yeah exactly yeah he's he's a also a design engineer at heart. So, um >> yeah, totally. >> 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? >> Uh and that just ends up leading to all these different things you built. >> Oh, I love his yak map. Oh man, >> he built a whole map showing his uh journey there. >> So dope. >> Oh, that's great. >> Wow. Cool. Well, I think we we're uh kind of running out of time here because I got to take the Well, at least I am. Uh West, you can certainly >> Evan's got to go to bed. Scott's got to go drop his kids off. I'm in the regular time zone here. I talk forever, >> right? But >> yeah, let's let's wrap this up. The last thing we have here is sick picks and shameless plugs. Um, I'm not sure if you could came prepared with a sick pick or a shameless plug. >> I did. No. Sick pick. >> Okay. Yeah. So, a sick pick is you pick something that you absolutely love in your life. It could be uh a pair of headphones, could be a chocolate bar, could be um Ryan uh from Dino and and Node. He picked flying a kite and going for a walk. >> Um >> so literally anything in your life where you're like, I love this. >> Okay, so I got this Landall stress toy from Lar. >> Oh, and it just like so squishy. It feels so >> 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. >> That's great. I love how he's just totally leaned into the whole Lamborghini thing. That's unbelievable. >> Um, 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+, there's Vitcon, and uh one more important thing I want to plug is we are actually premiering the uh the VIT documentary at VCON in person. >> Nice. >> Yeah. So, that's been like a year in the making. Um it's made by the same crew that made the Vue documentary, and it's also the uh the Cult Reple crew, which is previously the Honeypot crew that made all those other tech documentaries. And uh yeah, we're showing it as feed comp 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. Uh and just a a really just lovely group of people over there at Cult Repo. So uh 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. Um this was great to finally have you on and uh we'll catch you later. >> Yeah, I had a lot of fun. Thank you guys. Thanks guys., Creator of Vite: Evan You, Syntax, 01k5rpx489z8ahcpdxz6488y9m.