Vite Documentary Companion Pod  ## Metadata - Author: [[The Changelog: Software Development, Open Source]] - Full Title: Vite Documentary Companion Pod - Category: #podcasts - URL: https://share.snipd.com/episode/6740c163-b2b3-48ef-80d9-f37e0e3827bc ## Document Notes ## Highlights - **On-Demand Dev Compilation** - Evan wanted a dev server that serves compiled modules on demand to avoid long rebuilds and reproduce bugs quickly. - He leveraged native ESM and on-the-fly compilation to build Vite's fast dev experience. Transcript: Evan You Definitely not. Yeah, VEAT really just started as, similar to Vue. It started as this like random idea. Like, what if I just do this and then just started hacking on it and got something interesting and then kept pushing on. And eventually, you know, more people started using it. Jerod Santo What was that idea? I think this is going back to the Webpack days. I think Webpack was the bundler of the day. And of course, that allowed a lot of things, but it was also complicated and sometimes frustrating and lots of configuration. What was the idea you originally had with Vite that was worth hacking on? Evan You Yeah, so the original idea, so obviously I worked on Vue for a long time. And for Vue, we built this whole CLI that wraps Webpack called Vue CLI. And one day I was just trying to reproduce a Vue bug that are user reported that came with this whole reproduction that requires running Vue CLI. And I was installing all the dependencies and getting the reproduction started. And it was taking so long. I was like, there's got to be a better way of doing this. And the idea was really about loading a Vue single file component directly over the network from the dev server without an actual build step. That was really what I was looking for initially. So the first prototype of Vite was actually back in 2019. It was called Vue slash Dev Server. And it was really just a simple HTTP server that looks at the incoming request. If it's a Vue file, it'll just compile the Vue file on the fly and send it back to the HTTP request. I had that prototype done very early on, played around with the idea. I liked it because the experience I wanted was really something closer to a normal HTTP, local HTTP server that I could just start on demand. And then when I import a view file, I want the file to be compiled into JavaScript automatically when I request it. Later on, I realized, okay, this idea actually applies not just to view files, right? If I load a TypeScript file, if I import a TypeScript file, it should come back with the compile.js too. That was also the time when more browsers started to support native ESM imports. So previously, if we were to write something like import foo from a file, we had to first bundle it with Webpack, right? Because browsers couldn't just load native ESM. But in 2019, it was start, browsers started to ship that. And that really got me started thinking, okay, like, what if we can just use this to build a whole dev environment, right? You just import things on demand, it gets compiled, transpiled on demand on the server side, and you get the compiled JavaScript back. ([Time 0:04:18](https://share.snipd.com/snip/0b731983-1633-40a9-a96b-209d2fc133bd)) - **December Rewrite That Broke The Logjam** - Evan described a December 2020 burst of work when he decided to rewrite Vite and drop 1.0 to ship Vite 2.0 instead. - That intense period cracked the hot module replacement approach and delivered the framework-agnostic redesign. Transcript: Jerod Santo There were other contenders at the time, right? There were other people working on this problem, I think. Yeah. I remember Snowpack. Evan You Yep. Jerod Santo At some point there was one called WMR. I'm not sure the timeframe of that one. Evan You Yeah, I think, yeah. WMR was around the same time. Jason Miller worked on that. I think he also kind of worked on it in stealth for a bit of time. He kind of teased about it on Twitter. When it came out, I believe it was modeled after Rollup's API. That's also the source of inspiration for Vee to support Rollup's plugging API as well. And Snowpack also came around at the same time. The interesting thing with Snowpack is we kind of went from very different directions. Vite started as this sort of, if we can load modules with native ESM and do hot module replacement, and then we realized, okay, if we load every file this way, it will actually be slow. NPM dependency that has like hundreds and thousands of modules. It actually gets quite slow. So we're looking for a way to sort of, first of all, combine these individual modules in Node modules into fewer files. And also, some of the Node modules shipped were in CommonJS, which we can't load natively over ESM. So we had to pre-transform them into ESM so that we can load them in the browser. So we're looking for something that would handle that part. Snowpack started out as something that does exactly that. The first version of Snowpack was explicitly saying, let's convert all your CJS dependencies into ESM. And then they later on added the capability to do, like say, transpile on the fly and to do a hot module replacement. Essentially, they added on a dev server to that. And we started out as a dev server, but then tried to later on add this dependency, uh, dependency compilation part. Right. So we went from like two opposite directions to eventually become very similar in scope. So that was a, there was a period where we were pretty much just shipping features left and right. ([Time 0:08:11](https://share.snipd.com/snip/98612675-23af-4016-b409-b56b0264d9bf)) - **Plugin Abstraction Made Vite Universal** - Vite began as Vue-specific but evolved by adopting Rollup's plugin abstraction to support many file formats and frameworks. - That rewrite and plugin container enabled Vite to become framework-agnostic. Transcript: Evan You Um so the very first version of veet was definitely for view only, right? But I think we got it to, I was working on it halfway. So we got all the way up to like, there was a long period of like 0.x releases, and we got all the way up to 1.0 RC. That time, the internals were still very specifically designed for Vue. For example, the whole compilation logic of handling Vue single file components was directly inside Vue itself for version 1. And it was kind of an afterthought that we added this additional way of transpondency TypeScript. And in version one, we also did that through middlewares. So you need to add your own server middleware that intercepts a custom file format, then transpiled it into JavaScript. And before we shipped to one point, I was looking at this whole API design. I realized, okay, that was the point when I also started looking into WMR a bit more. And I realized, look, WMR is actually having this thing called a plugin container that abstracts away the plugin hosting interface for Rollup. So you can actually run a Rollup plugin without Rollup itself, not in the browser, but in WMR. So WMR is able to run process Rollup plugins, both during the development server and in the production build. So we realize, okay, if we do that too in Vite, we can support not just view components, we can support TypeScript, we can support TSX, JSX, we can support even Svelte. So that got me started thinking about refactoring the way we handle these custom file formats. And that eventually led to a complete rewrite. ([Time 0:10:59](https://share.snipd.com/snip/6981af77-dd1b-4355-8dcc-96a594889dfc)) - **Frameworks Migrated To Vite** - SvelteKit and Astro teams moved from Snowpack to Vite as Vite matured and proved useful for multiple frameworks. - Those early adoptions helped Vite gain momentum beyond the Vue community. Transcript: Evan You Yeah. I mean, that definitely took some time. I think Svelte was the earliest like sort of non-view framework to embrace VEAT. Because I think Rich Harris was working on SvelteKit at that time. SvelteKit was initially built on top of Snowpack. So when we were working on Vite, I think at one point the Svelteam eventually decided to switch from Snowpack to Vite. And then the Snowpack team themselves started working on Astral. And later on, they also decided, okay, we want to focus more on Astral. We want to focus on the framework layer instead of maintaining our own bundler, which our own dev server bundler slash everything that does more or less the same thing as Vite. So Astro eventually switched over from Snowpack to Vite as well. ([Time 0:16:41](https://share.snipd.com/snip/c3413875-8003-499e-a5cd-9748fc512b0b)) - **Empower Contributors With Recognition And Funding** - Recognize and empower active contributors by acknowledging their work and inviting them to take ownership roles. - Redistribute sponsorships to maintainers to enable sustainable long-term contributions. Transcript: Evan You To be honest, with the two projects, I kind of handle things a bit differently. With Vue, I would say we're really lucky to have, you know, first of all, like for any project to have capable and, you know, ambitious contributors stepping up. It's something you kind of, you're lucky to have any kind of these people, right? Regardless what you do intentionally or not. So first of all, you got to have these people. If you're lucky enough to have some people like this, right? It's important to sort of encourage them, acknowledge their efforts, and just make them feel that their contributions are being valued. In a lot of ways, I think for the Vue project, it's very organic. We don't really do any sort of trying to ask for contributions or try to find people explicitly to do these things. Most of the time, we notice a pattern. Someone is already very actively involved. They seem to be passionate about the things they're doing. So what we do is basically acknowledge them and empower them and make them feel like, okay, you're now part of this. Your contributions will now impact a lot of people. Obviously, there's a financial part of it, too. Vue is still independent. We have a decent number of sponsorships, and we redistribute them among the team members. So many of the maintainers who work on Vue now, they are sponsored through our open collective or directly through GitHub sponsors. So we basically redistribute the sponsorships coming into Vue to people who actually work on Vue. ([Time 0:22:09](https://share.snipd.com/snip/54d1d3d7-bcd7-4407-80eb-e788710223a1)) - **VoidZero Backed The Documentary** - Evan and VoidZero sponsored the Vite documentary and secured additional sponsors like StackBlitz and Sentry. - He helped the filmmakers connect to ecosystem companies to fund the production. Transcript: Evan You Yeah, so VoidZero obviously is supporting the documentary. We are the main sponsor, but we also manage to secure a few sponsorships from other companies that are either using Vue or actively involved in the ecosystem. So StackBlitz is one of them, Sentry, Shopify,, bold and super base. Nice. Jerod Santo Yeah. Evan You So yeah. So we have a quite a few, um, interesting companies backing the documentary too. ([Time 0:33:23](https://share.snipd.com/snip/ff2bf28a-0c7a-4554-8c91-dc2c1b07e21b)) - **Donations Don't Scale For Infrastructure** - Donations and lightweight sponsorships rarely scale proportionally to a project's user base or corporate beneficiaries. - Evan concludes businesses, not individual donations, must pay to sustain critical infra projects. Transcript: Evan You There's a project called thank you dev thank you dot dev i believe v2m viewer are actually on there too but we received such a small fraction compared to what we received from let's say Github And given the amount of views usage in the wild, I can kind of imagine how little maintainers of smaller packages actually get. I think this model is fundamental. I think the intention is obviously good. The idea of consumers open source should try support the dependencies you're using. In theory, that's what everyone should do. I think the fundamental problem is the donation or sponsoring open source is just not a thing in many of these companies. So if we think about who are actually getting the biggest value out of open source, it's directly proportional to the scale you're operating at. So an individual developer, if you're just making a sort of side project, you're using open source, you're not even creating value yourself. So asking them to donate to the open source project, maybe they'll like donate one or two bucks a month. That's like, in the grand scheme of things, that's negligible. But if you think about a big corporation, that's like making billions of revenue, they're also using so much open source. But it's for larger products like Linux or Kubernetes, they can operate it in a very, very different way. They have foundations, they have bigger companies just backing those foundations. But many other open source projects kind of fall into this category where you're not big enough for these big companies to say, hey, we need to somehow have a strategic sort of thing to Support it. But you're also large enough that you have such a, you know, maintenance burden that it's no longer sustainable if you're just one person. Right. Or people just like spending after work hours, you know, spare time because you could have been spending that time with your family. But now you're somehow obligated to support all your free open source users. Is that they are creating value for these commercial entities from businesses that's actually sort of using their open source projects. I wouldn't say it's close to free writing in a way, right? But it's also because in a lot of ways, we start a lot of these open source projects just because we want to share with people. We just want to put the stuff out there. But then people unintentionally find themselves in this awkward spot where your thing kind of blew up it's making a lot of impact right now you have a lot more responsibilities but it's Also like very difficult to make the companies that are getting the most out of the thing you create to sort of contribute back properly. ([Time 0:42:17](https://share.snipd.com/snip/b111f75a-991d-49ff-bd76-b7014e728e10)) - **Unified Toolchain To Reduce Ecosystem Churn** - VoidZero aims to build a vertically integrated JS toolchain (parsers to bundler to tasks) to offer a cohesive developer experience. - They plan to target businesses for revenue while keeping core tooling free for individuals and small users. Transcript: Evan You Yeah. So, so at 480, we're building a unified tool chain for JavaScript, right? So the scope is quite large. So we would cover, so obviously there veet which is at the center of it uh it's a dev server it's also a production bundler and then we have vtest which is the test runner then we have the Linkter which is based on oxc and inside veet we were previously relying on esbuildild and Rollup. Like we rely on two different bundlers. There's a lot of reasons we did that because the technical limitations on both sides and we just kind of have to combine the strength of both. So now we built our own Rust-based bundler called Rolldown that kind of combines the strength of ESBuild and Rollup and Webpack. In a way, we needed the best bits of those different solutions that we just couldn't get them working together. But now we actually built something that would perfectly suit the needs of Vite itself while being more powerful. And in order to support Rodan itself, at the lower level, we have all the parser, transformer, resolver, all written in Rust in the form of OXC, which is a collection of these lower level Tools. So essentially, we want to have this vertical, unified, integrated stack that supports all the way up from V, from the parser all the way up to V, and then extend into test, linked, so That you can have a Cardinal-like experience. If you've worked with Rust, right, when you start learning the language, the toolchain you use is Cardinal, and it covers most of the things you need out of the box. For JavaScript, we never had that kind of experience. And in a way, we're so used to when people get into web dev, the first thing you need to do is to decide which framework you want to use, and then which build tool, which linter, which test Runner. There are a bunch of conventions and best practices, but still, it's a lot. People will feel lost when you just try to set things up for the first time. We want to see if we can provide a more coherent and unified experience to that. So one unified tool chain to do all these things. At the same time we want to make sure this thing is you know well funded which means we are planning to do a you know do a business model where we want to charge from businesses actually making Decent amount of money instead of individuals so we'll probably disclose more when we announce Vplus as a product, which is the name of the tool chain is called Vplus. So we'll share more details at the conference. But the general idea is this is not a thing that can be sustainable if you're only trying to get donations from individuals, right? We want to make sure that we are still keeping a very low barrier of entry. Like if you're open source, if you're individual, if you're even maybe a small business or educational, academic entities or governmental entities, you should be able to just use This thing without any restrictions. ([Time 0:55:39](https://share.snipd.com/snip/e16b0c42-31d9-4424-893e-110c28fa6f71)) - **Rust Tooling To Replace Multiple Bundlers** - Vite relied on multiple bundlers historically, so VoidZero built Rolldown and OXC in Rust to combine strengths and simplify maintenance. - Consolidating lower-level tools in Rust aims to solve technical limits and improve performance. Transcript: Evan You Like we rely on two different bundlers. There's a lot of reasons we did that because the technical limitations on both sides and we just kind of have to combine the strength of both. So now we built our own Rust-based bundler called Rolldown that kind of combines the strength of ESBuild and Rollup and Webpack. In a way, we needed the best bits of those different solutions that we just couldn't get them working together. But now we actually built something that would perfectly suit the needs of Vite itself while being more powerful. ([Time 0:56:13](https://share.snipd.com/snip/a0b3b3d5-ec48-4cd8-aa5f-5d066f767074)) - **Charge Businesses, Keep Tools Free For Individuals** - Keep core components open source but offer a bundled, source-available superset with paid value features for commercial users. - Target paying customers as businesses with revenue while preserving free access for individuals and small teams. Transcript: Evan You So we'll share more details at the conference. But the general idea is this is not a thing that can be sustainable if you're only trying to get donations from individuals, right? We want to make sure that we are still keeping a very low barrier of entry. Like if you're open source, if you're individual, if you're even maybe a small business or educational, academic entities or governmental entities, you should be able to just use This thing without any restrictions. But if you are a business that's having decent amount of revenue, right, these are the targets that should be actually paying for the majority of the shares to support these efforts. So this is something we're trying to explore. And in a way, it's also my hope of finding a model that can sort of, because we haven't really seen other projects doing this kind of thing. I think there are maybe a few examples in the wild, but this is something we're trying to explore to see if we can make the right people pay for the, essentially we want the businesses to Be subsidizing the use, wider use of these infrastructure level pieces in the JavaScript ecosystem. Jerod Santo And so to start this, did you raise money? Evan You Yes, we did. Yeah. Jerod Santo And the reason for that was because you needed time to explore this or? Yeah. Evan You So the scope of this whole vision is obviously much bigger than what we can cover with just the sort of sponsorships or donations from like we did with Vue, right? If you want to build this whole thing from the ground up, you need a dedicated team of people, full-time efforts. And it also needs to be more structured than the voluntary model that Vue did, because with Vue, we never had any sort of, you know, goal, like for Vue, there was no concrete goals of like What the end form of Vue should be. In a way, Vue's development was very much sort of user-driven or community-driven. In a way, we work on Vue, we fix issues, and then we discover problems users are facing, then we propose solutions to it, and then we just evolve organically. So Vue doesn't have sort of a fixed scope or a very concrete roadmap of what you need to achieve, say, in five years. But for this, I guess when I started having this idea, I realized, okay, the things you want to do, it's a lot. It's a pretty big scope if you want to build a unified tool chain for JavaScript. And it's something you need a team of full-time members that's fully dedicated to this goal and work closely together. And the best way to do that is still to form a business and have them properly compensated so that they, so that we can sort of in the short term, we don't need to think about how can we like, How can we negotiate sponsorships or how can we like get enough individuals to donate us. Gotcha. Jerod Santo And so when you received the money, did you go out and then start hiring members of the Vite community basically? Evan You Yeah. So we do, we hired quite a few team members from ViteTest, from Vite. But we also had a few folks from Bytedance. They were working at the WebInfo team on Bytedance. So actually a few of the earliest members of the company worked on the RSPAC project at Bytedance. So they have a lot of experience and expertise in the Rust 4.js tooling, which helped us kick off the initial efforts in this area. So the folks working on Rodeon actually worked on RSPAC. Jerod Santo Gotcha. Funny story. I used to call it RSPAC because no one ever told me how to pronounce it. And I had to say it on the show. And I'm like, it looks like RSPAC. They lowercase the S. It doesn't make any sense. But RSPAC makes way more sense than RSPAC for sure. V plus is it v plus other features is it v but you pay for it is it bundled like is it v is multiple things and we put them together and package them and that's what you use like what is v plus I know if you don't haven't actually announced the details but like give me a shape of the object. Evan You Sure. Yeah. So VitePlus is a drop-in superset of Vite. Jerod Santo Drop-in superset. Okay. Evan You If you're using Vite today, you can basically alias Vite to VitePlus and everything will continue to work the same way. In addition to ViteDev and ViteBuild, you can now also do ViteLinked, ViteTest, ViteBench, ViteFormat. I see. Yeah. So it comes integrated with a lot more capability. So it's a tool chain instead of just a built tool. Jerod Santo And where and when is VitePlus? Is VitePlus out there? Is it going to be out there at ViteConf? Evan You So we're going to talk about more details. We're probably going to give a first demo of what VitePlus looks like in action at ViteConf. Right now it's still in active development, so we probably want to save the sort of big reveal at the conference. Jerod Santo Sure, absolutely. So after the conference, if I'm Jared, the open source hacker, and I want Vee Plus, I'll be able to use Vee Plus without any money, with money involved. I'm just Jared the dev. Evan You Jared the dev, if you're just an individual hacker, you can definitely use V without any restrictions. Jerod Santo Okay. Now I'm Jared, the well-funded Fortune 500 company. You'll need cannot use V plus without money. Correct? Evan You So you can still try it. You can still just experiment with it. But if you are using it in any commercial capacity, you'll need to talk to us are the individual components of v plus separately open source or no yes they are so it's the packaged deal That is yep yep so the underlying components which includes vt rowdown oxc vtas they remain open source remain exactly what they are today. ([Time 0:58:42](https://share.snipd.com/snip/cdf9c120-32a1-48c4-b640-8e240e24d901)) - **Cache Smartly And Make Remote Services Optional** - Use an integrated task runner with smart input inference and caching to speed monorepo builds and avoid redundant work. - Offer optional remote caching services but keep local usage fully functional and private-storage friendly. Transcript: Evan You So we are actually working on an integrated task runner slash caching system for Moto repos, which tightly integrates with all these underlying tools. So that allows us to smartly infer the input for each task that you run through the system. So we smartly cache the outcome of the, for example, if you run VT build through V plus, right? We know exactly what the inputs are and outputs are. So we just cache it automatically. If you um edit a file but it doesn't actually affect the the task you're running you would just get a cached output automatically okay and that will be a v plus thing so does that require A void zero server somewhere in there uh it doesn't uh it's right now it. Okay. Jerod Santo Do you imagine a world in which void zero servers are involved? Evan You In the future, maybe, but we don't want to make that a requirement. So these will be probably more like value-added services where it will make your, like remote caching with the system definitely will require some sort of server setup, but we'll probably Make it, like, we'll definitely make it feasible to use your own storage backend gotcha ([Time 1:05:19](https://share.snipd.com/snip/60f399c0-8f7a-45f6-8bff-fa113a11f430))