The Changelog: Software Development, Open Source - Vite documentary companion pod (Interview)

Episode Date: October 8, 2025

Our friends at Cult.Repo launch their epic Vite documentary on October 9th, 2025! To celebrate, Jerod sat down with Evan You to discuss Vite's adoption story, why he raised money to start VoidZero, how developer documentaries get made, open source sustainability, and more.

Welcome, everyone. I'm Jared and you are listening to The ChangeLog. Where each week, Adam and I interview the hackers, the leaders, and the innovators of the software world. We pick their brains, we learn from their failures, we get inspired by their accomplishments, and we have a lot of fun along the way. Our friends at Coltripo launch their epic Veet documentary on October 9th, 2025. So on this episode, I sit down with Evan Yu, creator of Veet and View to discuss Viette's adoption story, why he raised money to start Void Zero, how developer documentaries get made, open source, sustainability, and more. But first, a big thank you to our partners at Fly to I.O.

The public cloud built for developers who ship. We love Fly. you might too learn more at fly.io okay evan you and vete on the change log let's do it what's up friends i'm here with Kyle Galbraith co-founder and CEO of Depot depot is the only build platform looking to make your builds as fast as possible but Kyle this is an issue because GitHub Actions is the number one CI provider out there, but not everyone's a fan. Explain that. I think when you're thinking about GitHub Actions, it's really quite jarring how you can have

such a wildly popular CI provider, and yet it's lacking some of the basic functionality or tools that you need to actually be able to debug your builds or deployments. And so back in June, we essentially took a stab at that problem in particular with Depot's GitHub Action Runners. What we've observed over time is effectively GitHub Actions, when it comes to actually debugging a build, is pretty much useless. The job logs in GitHub Actions UI is pretty much where your dreams go to die. They're collapsed by default. They have no resource metrics. When jobs fail, you're essentially left playing detective, like clicking each little drop down on each step in your job to figure out like, okay, where did this actually

go wrong. And so what we set out to do with our own GitHub actions of observability is essentially we built a real observability solution around get of actions. Okay, so how does it work? All of the logs by default for a job that runs on a depot get of action runner, they're uncollapsed. You can search them. You can detect if there's been out-of-memory errors. You can see all of the resource contention that was happening on the runner. So you can see your CPU metrics, your memory metrics, not just at the top level runner level, but all the way down to the individual processes running on the machine. And so for us, this is our take on the first step forward of actually building a real

observability solution around GitHub actions so that developers have real debugging tools to figure out what's going on in their builds. Okay, friends, you can learn more at depot.dev. Get a free trial, test it out. Instantly make your builds faster. So cool. Again, depot.dev. Today we have a special treat. It's Evan. You from Veat. Welcome, Evan. Nice to be here. happy to have you now as we record this we're together but as it ships out to our audience you are going to be at the first ever in-person VietConf that has to be exciting yeah we're looking forward to it beats come a long way I think since you first started it to a live in-person conference with a cult repo formerly honeypot classic documentary as well shipping about

Viet, you probably didn't have such grand ambitions when you first got started, did you? Definitely not. Yeah, VET 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. What was that idea? I think this is going back to the Webpack days. I think Webpack was the 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 Viet that was worth hacking on? 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. It 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 Veed was actually back in 2019, it was called Vue slash dev server.

It was really just a simple HTTP server that looks at the incoming request. If it's a view file, it will just compile the view file on the fly and send it back to the HTTP request. I had that prototype done very early on, Play it around with the idea. I liked it because, you know, 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 Compilejs 2. That was also the time when more browsers started to support native ESM imports. So previously, if we were to write something like import food 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 started, more 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.

So in 2020, the first prototype in 2019 actually got sort of a, I dropped it aside because I couldn't figure out how to do hot module replacement. with it. So I kept thinking on about it. I was also working on Vue 3 at the time. So that idea kind of stating sort of a prototype status for a very long time until in April 2020, it somehow clicked. I was like, hey, maybe we can do hot module replacement over native ESM just by doing this and that. So I started hacking around the idea. I pulled out the old prototype, started adding, trying to add the HM, uh, hot module replacement. placement logic on top of it. And it kind of worked.

So that got me really excited. And that was like the real start of VET as a real idea. There were other contenders at the time, right? There were other people working on this problem, I think. Yeah. I remember Snowpack. Yep. At some point, there was one called WMR.

I'm not sure the time frame of that one. 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 Roll-Ups API. That's also the source of inspiration for Vee to support Roll-Up 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. Vee started as this sort of if we can load modules with native ESM and do hot module replacement and then we realize okay, if we load every file

this way, it will be actually be slow because if you have a MPM 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 shift 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 say,

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 the dev server to that. And we started out as a dev server, but then tried it to later on add this 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 we're kind of doing the same thing in parallel and at a certain point vete kind of busted out

from the notion at least the one that i had and i think others shared that it was for view like if you're not using view vets usable but really it's built for view and that may have never been true, but the reputation was that or that just the association was there. Yeah. So the very first version of VE 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 up all the way up to 1.0 RC. At that time, the internals was still very,

specifically designed review. For example, the whole compilation logic of handling view single file components was directly inside VIT itself for version 1. It was kind of an afterthought that we added this additional way of transpiling, say, type script. And in version 1, we also did that through middlewares. So you need to like add your own server middleware that intercepts like a custom file format, then transpiled it into JavaScript.

And I was then looking, before we shift to one point, I was looking at this whole API design. I realized, okay, like, that was the point when I also started looking into WMR a bit more. And I realized, look, WMR is actually having this something called a plugin container that abstracts away the plugging hosting interface for a roll-up. So you can actually run a roll-up plugin

without roll-up itself, not in the browser, but in WMR, right? So WMR is able to run process roller plugings, both during the development server and in the production build. So we realize, okay, if we do that to Indeed, right, we can support not just view components, we can support TypeScript, we can support TSX, JSX, you know, we can support even Sveled, right?

So that got me started thinking about refactoring the way, way we handle these custom file formats and that eventually lead to a complete rewrite so we never actually shipped 1.0 uh i just i was like we were already in 1.0 rc like 25 or something i was like yeah i was like we got like just completely rethink this so i started a whole rewrite that eventually became uh v2 yeah and that rewrite took like another like three to four months i believe so you never shipped one but then you ship two Yeah, we just went directly to VITT2. And how long did you say that the difference was in timing between the two, the RC and the VE2?

Can't remember the exact date we started working on RC, but we first talk about the idea in like April 2020. That was like the first zero point X version of VIT. And VE2 was shipped in February 2021. Okay. So I remember this part from the documentary. So I was able to see a rough cut of the doc and Fred Schott, who's the snowpack author and I'm sure a friendly competitor at the time. You know, you have the spirit of open source competition, but everyone's kind of rooting for everyone. At least that's the way I play the game.

He's telling the story of this December time period where, you know, he's spending time with his family and all of a sudden Evan starts committing like crazy. I don't know if that's dramatized for the doc. and of course they do a great job with these documentaries they show like your they have this close up view of your contribution graph and all of a sudden like you know little green dots start to show up in December and then into January and he's like Evan cracked the nut or something like this you know like you figure something out that got you excited to like really start going on it is that approximately true yeah actually looking at back at the days I think the uh the idea of like dropping RC and just go directly to 2.0 was like it started exactly in December

2020. Okay. At the start of December. Yeah. So, people were still waiting for 1.0. Yeah, people were waiting extensively. They're like, man, this is the longest release candidate ever. Yeah. Never landed. Yeah, never, never ended. And then here comes 2.0. So at that point, did you get the groundswell of adoption and support once two hit, was that when Vee really started to, because I mean, the adoption story since then has been astronomical, hasn't it? Yeah, I think 2.0 really was the, the real starting point of, you know, real momentum in terms of adoption. Because people saw, okay, like, people knew about VIT one, right, before 2.0. Some people were already using it, excited about it. But 2.0 was

really the version that made people realize, okay, like, this is more than just for view. It can actually be a proper tool for other frameworks as well. I think that also started, we started seeing other frameworks actually adopting VIT and building on top of it. So that's, that really kicked things off. That's a beautiful thing, right? Because there's so much framework, there's fractals of frameworks in the JavaScript community. And each one for a long time had their own build tools, you know, their own Webpack thing, or like Vite did.

You guys are like, well, we're going to build one for a view. And then eventually, it's nice to see some coagulation and some really rallying around a tool so that everybody can benefit and helps with that paradox of choice to a certain extent. It's like, yeah, well, one's just using beat now. So let's just all do that. And one less decision to make, right? Yeah. I mean, that definitely took some time.

I think Svelte was the early. like sort of non-view framework to embrace Viet. Because I think Rich Harris was working on Svelkit at that time. The Svalkit was initially built on top of Snowpack. So when we were working on VET, I think at one point the Sval team eventually decided to switch from Snowpack to VIT. And then the Snowpack team themselves started working on Astrol. And later on, they also decided, okay, we want to focus.

more on Astrol. 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 VIT. So Astro eventually switched over from Snowpack to VET as well. So these are probably the two of the earliest sort of frameworks that decides to just build on top of VET instead of reinventing the wheels. So what was your own trajectory like with regard to Vue.js? and VET. I don't know your history around. Did you leave the Vue project?

Are you still? We're still working on it. You still working on the Vue project? Yeah. I spent a lot less time directly on Vue myself. We do have other team members still working on features and maintaining it. But, you know, the reason we created Veed was because I wanted to use it with Vue. So obviously we switched all the default tooling of view over to Veed.

Yeah. So, you know, the Vue plugin. was actually what I, exactly what I used to validate the design of our plugging interface. And later on, we also have Nuxt, which was the main meta framework in the view ecosystem. So Nuxt 3 was in development when VIT 2 was introduced. Originally, it was again built on top of Webpack. So when they found out that VIT is coming out, I think what they did is they, I think a smart thing they did with Nux3 in the beginning is they made the core logic of NUCS3, the framework, bundler agnostic.

So it can actually work with different builders. So it can work with Webpack. It can also work with VET. So when they saw VET was out, they immediately started refactoring things so it can work with VET. And eventually, the default version of NUX3 was also shipped with VIT as the default build tool. Well, friends, it is time to let go of the old way of exploring your data. It's holding you back. But what exactly is the old way?

Well, I'm here with Mark DePuy, co-founder and CEO of Fabi, a collaborative analytics platform designed to help big explores like yourself. So, Mark, tell me about this old way. So the old way, Adam, if you're a product manager or a founder and you're trying to get insights from your data, you're wrestling with your Postgres instance or Snowflake or your spreadsheets. Or if you are, and you don't maybe even have the support of a data analyst or data scientist to help you with that word. Or if you are, for example, a data scientist or engineer or analyst,

you're wrestling with a bunch of different tools, local Jupyure notebooks, Google Co-Lab, or even your legacy BI to try to build these dashboards that, you know, someone may or may not go and look at. And in this new way that we're building at Babi, we are creating this all-in-one environment where product managers and founders can very quickly go and explore data regardless of where it is, right?

So it can be in a spreadsheet, it can be an air table, it can be in Postgres, Snowflake. Really easy to do everything from an ad hoc analysis to much more advanced analysis if, again, you're more experienced. So with Python built in, you know, Python built in right there,

NRII assistant, you can move very quickly through advanced analysis. And a really cool part is that you can go from ad hoc analysis and data science to publishing these as interactive data apps and dashboards were better yet at delivering insights as automated workflows to meet your stakeholders where they are in, say, Slack or email or spreadsheet. So if this is something that you're experiencing, if you're a founder or product manager trying to get more from your data or for your data team today, you're just underwater and feel like you're wrestling with your legacy, you know, BI tools and notebooks, Come check out the new way and come try out Fabi. There you go. Well, friends, if you're trying to get more insights from your data, stop resting with it, start exploring it the new way with Fabi. Learn more and get started for free at Fabi.a.i.

That's fabi.a-i.a-i. Again, fabi.a.i. One of the things that I'm very impressed by you, Evan, is your ability to foster communities around your project. And you've had so many, I mean, even Viet has so many amazing contributors, Anthony Fu, Matthias Capoletto, you remember his last name, Paytack. Like, those are just two examples of a lot of people. Yeah. Is that something you do intentionally?

Did that just kind of happen? Like, how do you get these amazing devs to come alongside and then like, you know, view is maintained and continue to be worked on largely by people that aren't yourself? That's an accomplishment. How do you do that? 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've 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, right? In a lot of ways, I think for the view project, it's very organic.

We don't really do any sort of, we don't do any sort of like trying to ask for contributions or try to like 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, like you are now part of this, right? Your contributions will now impact a lot of people. Obviously, there's the financial part of it too.

View 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 are they are sponsored through our Open Collective or through directly through GitHub sponsors. So we basically redistribute the sponsorships coming into Vue to people who actually work on Vue. That helps, but again, Vue is a very loosely organized team. So people would come and go. We have quite a few people on the team who've been with us for like close to a decade. Right. So Eduardo, who maintains the router and Peno, our official statement management library, he's been with us like forever, one of the earliest to join and he's still working on things. And we also have people who've maybe contributed very actively for a year or two. And then they just disappear, which is totally fine because that's how open source works in a way.

right yeah yeah so that's you know it's a combination of people who who joined and just stick around or people who you know joined left but so they still left something really valuable to the project so if you it's very i would say it's it's very unintentional like we're really lucky to have these people kind of just happened yeah kind of just happened fivit i would say is a little bit different because um i think once it shipped to version two i was aware that now I have to basically split my attention between view and VET. So my original, my original plan was, I'm going to go back to focus on Vue because we still haven't shipped Vue 3 at that point. I basically took this huge detour.

People were waiting for Vue 3, but I ended up building VIT as kind of a, maybe as a, as a way of procrastination. Was anybody mad about that? I don't know. I think it turned out to be like a net positive, right? You wait a bit longer for VIII, but you end up also having VET. But the idea was, okay, I need to go back and focus on VE3 now. So I need someone to sort of help me take care of VET in a way. So I made a explicit post.

I said, okay, like we're setting up a team for VET. If you're interested, you should join. And that was, I believe, when at that time, I think Matias was already very, very actively involved. He started, I think his first few PRs were mostly documentation. He was just helping us on, like, adding additional details in the documentation, started digging into the internals a bit. And he was very, very active with the community.

He was on the Discord server. He was basically everywhere, answered all the questions. So I was like, well, this guy seems very enthusiastic about Viet. I should probably encourage him to to kind of help us with the monitor maintenance of it and he was really happy to join too so yeah

so Matias became the very you know I think he's literally the first team member and also very very played a very critical role in the initial sort of growing the community and making these additional team members feel they are being welcomed and appreciate

it. Yeah. I've met Mattias. He is very good at that. Lots of enthusiasm, lots of care and kindness that just kind of oozes out of the guy. When you say, when you go into offer him something like that, like what, what is the Vite side? What's the offer? Like, what does he get? Do you get your name on the, you know, on the core team? Do you get this, that, or the other thing? Like, is there some sort of formalization of what that looks like? Or is it just like, hey, why don't you do more of what you're doing? I think for the, for the initial, when we, set up the team, it was like purely voluntary. We're basically saying, okay, you get to be called yourself a team member, and that's it. Yeah, because you seem, yeah, but, but yeah, it was very

much like you're already just, you're already doing this. So we just want to want you to keep doing this for, for the recognition of being a team member. Yeah. We have no plans around like how people turn on in the long run. But I think a very lucky, also a very lucky, also a very lucky event happened because StackBlitz, which is now the company behind Bolt, they actually haven't come up with the idea of Bolt

back then. That was like in 2022. They were mostly still working on their web containers technology. Stackblitz, the dev environment, right? So it's an in-browser development environment and they were looking for a dev setup that just starts

on faster than Webpack. And they found VET. So they were really excited, and they started looking for people who are working on VET. So they actually hired Matthias to work on VIT full time. So that was what allowed Matias to be able to spend a lot more time on VAT. So that's like, yeah, one and three and half years ago. Quick side story on StackBlitz. We had them on JS Party a couple of times because doing cool stuff in the browser and the second time I think or maybe the third time that one of them

came on it was to talk about tutorial kit Tomek Salkowski came on and after that show he's like hey we have this cool thing that we're just about to launch called Bolt do you want to try it out and you want to see what it is and this was before I mean they had no idea

because I mean Bolt just was like a rocket you know ship just stratosphere launch but they didn't add no I mean he's just like this is a little side project we're doing uh check it out and i'm like this thing's pretty cool he's like yeah we're ship it next week we'll let you know how it goes and like now they're they've renamed you know like it's former leased that splits i mean it's still out there i think but like yeah talk about a pivot

that's uh totally yeah an amazing actually yeah they actually debuted a boat at vietconf they also showed me like a week before it was like well this looks cool but i'm not sure how far this is going to go because I think like initially the I was at that time I was still a bit skeptical about the general capabilities of LLMs in general yeah but yeah that's funny when you showed it to me I thought the same thing I'm like this is neat like it seemed like a kind of a cool toy was my thought you know like this seems like a good example of something that the stacklets team could do yeah I never expected it to be like a product they would just you know take over their entire company so congrats to them of course

and I'm sure they were pleasantly surprised that it went so well. Yeah. So what about this documentary? This is the second time you've been documentatize, right? Didn't they do a VJS documentary? They did. It's actually from the same team. Yeah, exact same team.

Round two. What does that process like as like a everyday hacker, you know? All of a sudden it's like put on some nice clothes, going to get interviewed in front of, you know, hot lights and stuff. Is this something that you enjoy? you'd put up with because it's good for the projects. Like, how do you approach these things? Yeah, I think, again, like the two times,

it's the same team, but it feels quite different. For the Vue one, the team was largely sponsored by Honeypot. And when they came to us, when they came to me about the view idea, I was like, sure, sounds great. Because Vue was, you know, I think the Vue documentary was done I can't remember exactly which year it was but I was still living in suburban New Jersey and they actually managed to fly all the way to New Jersey

come to my house to film it but the vibe was still quite casual they felt me like making coffee and everything and then I think we met again when I was speaking at Laricon in New York 2019 they went to the Laricon venue and filmed a bunch of stuff there.

Taylor Otwell was actually in that documentary, too. Nice. But they were very professional back then. I mean, the director, Josiah, he's amazing. So did a lot of, the thing is, they are able to not only make fancy edits, but also they actually understand the story behind these things. They ask the right questions, and they're able to probably tell the story behind the technologies. I think that's the impressive part.

So this time when they approached about another documentary, actually this time, this is after HoneyPod actually folded. So they now have to work on these documentaries by securing their own funding. So they now have a new company. They do need to basically secure sponsorships or sponsors to, to make these documentaries. So they approached me and basically just try to ask me, like, do you have any ideas? Can you, like, introduce us to some companies or projects that would be looking to make

documentaries about their technologies? And I was like, hey, we can make one about VAT. And they were like, wait, this sounds like a great idea. And we should totally do this. Yeah. So you and or void zero, you bankrolled it? basically, or how does it work? Yeah, so Voizzer 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. Yeah. So, yeah, so we have quite a few interesting companies back in the documentary, too. Yeah, that's really cool. I didn't know that side of it. I knew that they had renamed. I wasn't sure about the rename Honeypot to Colt repo. And that's a really cool model because they do a great job of telling you stories and making them interesting. That's always the thing you're like, it's the story of an open source project. Like, what's, it's a bunch of nerds writing, you know, code. How could that be interesting? But actually,

it is interesting and they do a good job of making it that way. And so I think these things need to exist and continue to be made. And so if hopefully this works out for them and for you all to be worth it as an effort. I think they are working on quite a few additional ones in parallel. So I think they did one with with Rails, I believe. Yep, I think that one's out there. And then we just helped promote the Python documentary as well. Yeah, the Python one, Angular one.

Yeah. Yeah. They're doing a lot of great stuff. And I think it's definitely needed for the deaf community. Yeah. It's so cool to be featured as a person who writes software to, like, have your story told, I think, is especially because it's never the story of one person. Like, maybe it starts with Evan U. But then, like, the story actually weaves in and threads through all these people's lives, you know?

Totally. Yeah. It's really neat. It is, this is, I believe, I believe this is the great part, right? In a way, like, every time I see these documentaries starting with a big shot in me, I feel a bit of uneasy. I feel like I don't want these documentaries to be about just one person, right? Right. It's in a way, like tech open sources about people.

So these documentaries should be about people. Well, friends, you don't have to be an AI expert to build something great with it. The reality is AI is here, and for a lot of teams, that brings uncertainty. And our friends at Mirror recently surveyed over 8,000 knowledge workers, and while 76% believe AI can improve their role, most, more than half, still aren't sure when to use it. That is the exact gap that Mero is filling. And I've been using Mero from mapping out episode ideas to building out an entire new thesis. It's become one of the things I use to build out a creative engine. And now, with Mero AI built in, it's even faster.

We've turned brainstorms into structured plans, screenshots into wireframes, and sticky notes, chaos, into clarity, all on the same canvas. Now, you don't have to master prompts or add one more AI tool to you. your stack, the work you're already doing is the prompt. You can help your teams get great done with Miro. Check out Miro.com and find out how. That is Mero.com. M-I-R-O-O-com. So I've been curious about Void Zero since you made the announcement. This is a new direction for you, I suppose. Because prior to view, weren't you working at a big tech company? Was it Facebook or where were you working? I was working at Google when I created Vue.

Right. And then you went Indy and open source. Yeah, I left Google in 2014, but I left Google to work at a startup of Meteor, which was also a startup working on open source JavaScript framework. Meteorjs? Meteorjs, yeah. I didn't know you worked there. Okay.

Yeah. I spent less than two years. So I left Meteor in 2016. So I officially became, you know, fully independent in 2016. That's when I started working on Vue full time, which means I've been working independently for like nine years now. Almost a decade. That's a long. Yeah.

That's a long time. And you're kind of a poster child for like, this can work. Like the open source independent thing with sponsorships can work. Now doesn't mean it's going to work for everybody. And in fact, for most people, it doesn't work in that particular model. But for you, it was working. And so it's kind of, you're kind of inspiring to a lot of us to say, okay, well, if Evan can do it and he can get his commercial support enough to stay independent and still provide for his family, et cetera, maybe the rest of us can too. Yeah, I think that I always consider myself lucky to make that work.

Because to be honest, like when I started doing it 2016, I had. no idea if it was going to work yeah i was like let's just yolo uh anyway i was like i want to just work on this thing full time and let's see how long it lasts right worst case scenario i'm just going to go back and look for another job but you know uh it was just so fulfilling to be able to work on something that you just work on that one thing you know yeah yeah it's really cool That being said, I think we could probably count maybe on two hands, maybe not just one hand, but two hands, people that have made that work like you have.

It's not, it is the exception. It's not the rule. It is definitely an outlier kind of thing. In fact, a lot of people, a lot of open source maintainers have came to me over the years asking for advice, how can we make this work? And in a way, my response was always like, look, it's hard to replicate exactly what I did. there's no like real formula that you can just follow yeah uh it depends on a lot on the kind of project you have you know that even if your project is like wildly popular like what kind of

what kind of layer it sits on also kind of determines a lot because like for framework like view uh you get massive exposure and constant interaction with your users yeah um people also kind But it's easier for people to feel more closely associated to a framework that they use every day. Compared to something that sits lower level, the more lower level it is, the more difficult for you to get this sort of connection with your users. An example I've always used is Babel because I was friend with the maintainer of Babel for a while. Henry Drew, he was the lead maintainer of Babel for a while. And they've always struggled with funding because even though almost everyone used them, used Babel, right?

Because it's just one of the dependencies, the kind of, once you set it up, it just sits there. Right. You don't think about it anymore. It was extremely difficult for them to do the same kind of model viewers doing because they just don't get enough eyeballs. So, yeah, over the years, we've seen a few other examples successfully sort of making this work. But yeah, I've also seen so many cases where they're trying to do what we do, but it's very challenging. Yeah. Interestingly, I think Webpack was one that was making it work as well, maybe because, again, they're right there in your face.

It's a build tool that you use every day. And for a long time, well, they had a good evangelism as well and large corporations using them. And so it became kind of cool to support Webpack because it was an example of like supporting open source back in the early days. of that movement. What do you think about a lot of these efforts to somehow calculate out dependencies and maybe distribute out, you know, redistribute from the top down, like from the Vue. js down to or from the V to the babbles of the world. Yeah.

Do it that way because there's so many fundamental aspects of software that are completely invisible to the end user, but they aren't usually invisible to the one who pulled them in originally. And so maybe we can do it that way. I know there's been lots of efforts to do that. I wonder your thoughts on it. Yeah, there is a project called Thank you, Dev. Thank you. Dev, I believe.

Viet and Vee and Vee are actually on there too, but we receive such a small fraction compared to what we receive from, let's say, GitHub sponsors. And given, like, the amount of views usage in the wild, you know, I can kind of imagine how little, you know, maintainers, smaller packages actually get. I think this model is fundamental, like, I think the intention is obviously good. The idea of, like, consumers open source should try to, you know, support the dependencies you're using, right? Like, 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, right? 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 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, I guess like for larger products, like Linux or Kubernetes, they could operate it in 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 know, 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 their family. But now you're somehow, you know, obligated to support all your free open source users, right? So I don't, I think that's, that's the unfortunate sort of state of things for a lot of open source projects is they are creating value for these commercial entities from businesses that's actually, you know, sort of using their open source projects. I wouldn't say it's, it's close to free writing in a way, right? But it's also because, like, 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 very difficult to make the companies that are getting the most out of the thing you create to sort of contribute back properly. I think that's a systematic challenge

in the way. a lot of independent open source projects work nowadays, right? So obviously, some of them eventually start companies, right, to sort of turn it into a real business, right? But it's just not a thing that everybody wants to do, and it's also maybe not feasible for a lot of the projects. Yeah, I think the corporate open source support movement was had some steam. up until the market correction when money became tight. And then it was like, well, now we're doing layoffs and now we're, you know, we're tightening the bill.

We're not going to, you know, give money away that we don't have to. And so it's kind of, it's lost team. But was your then idea with void zero? Because probably Vite could just continue like VEU does, right? Like you probably just do the support. Like I'm not saying VET is void zero, but like you, yourself and your team, have made it in terms of support, I'm assuming, continue it. Yeah, I think for VIT, it actually has a similar challenge because it's very high visibility

project, but it's not as, um, it's a little, still a little bit different from view in the sense that it's not a framework in itself. So true, but it has Evan U and it has, it's a command that you type into your terminal, right? Like you're using it actively. It's not hidden from you. And so do you think, like, I guess where was you're thinking with void zero and V? Was it like we're not going to do the same model that we did last time? Or did you want a new challenge or a new, were you bored?

I don't wonder where you're coming. Yeah, there's, there are multiple, it's a combination of multiple factors. So one thing is my experience view with the sustainability side of view. is that the successive view is an outlier and has a lot of luck involved, right? The timing, you know, the fact that view was able to become now the second largest framework has a lot to do with doing the right thing at the right time. And for VIT, we noticed that we weren't getting some sponsorship for VIT as well, right? But I no longer want to, like, I guess for a view, the model was that I was still doing most of the work, right?

It's not like, I'm not trying to take all the credit, but over the years, I was still the main person that was driving View forward, making the main decisions, shipping the main features, and all that. So I was also making most of the financial decisions for the project. But for Viet, I essentially wanted to, okay, how about? let's make this thing a bit more, you know, decentralized so that more people can actually work on a full time. So it's not me having to be fully responsible for the financial side of it. That was the initial hope. But then we realized, okay, like this sponsorship model really, really has its limits. Like, over the years, we're able to call View sustainable, right? But if you think about the amount of users we have, the view has like 2 million weekly active

users based on how many people are using our DevTools extension. Right. If we were a business and we're only getting the amount of sponsorships we get today, which is like less than a million a year, that's like, right? If it's a business, it's not a very successful business. Right. Yeah. So successful open source projects, not successful business.

Yeah, in terms of conversion rate. Right. So it's all relative. But imagine if you're a business with like two. million users and you're only making this much. That's not a lot. So for Viet, what I realize is like, actually in terms of like sponsorship conversion, VIT is doing worse than VE because it sits a layer lower.

It's not a direct framework people interact with. So people have less sort of this idea I need to support the tool I'm using because a lot of people are still using VIT through a framework. For example, they're using Svelkits. They're using React with Vite. They're using VEET. They're using VEET, right? So they're still thinking primarily about the framework instead of this tool.

Plus, perhaps the view people, perhaps also the people who are using VET with VE, they may already be supporting VEU and they think, well, I'm already supporting these people. Yeah, right. So that's possibly a part of it as well. Yeah. So for me, I was thinking, okay, I want to make VIT independently, sustainable, aside from you, I never want to like sort of just mingle, mix these two projects, right? Because when we decided to make VIT framework agnostic, I was like, okay, VIT is going to be its own thing, right?

It needs to find its own way, all path to sustainability. And on the other hand, I was also witnessing this trend where VIT is becoming this shared infrastructure between a lot of frameworks, right? So multiple different frameworks are building on top of VIT. So I saw this opportunity to say, okay, because we think about, when we talk about JavaScript ecosystem, it's always like churn, fragmentation, things come and go, right? But it's actually was, it's quite rare for multiple frameworks to be betting on the same thing at the same time. And a lot of these people are smart people that I also really, really respect, like Rich Harris, Fred, you know. So I was like, look, like, people are betting on VIT.

VIT is like serving a much bigger responsibility. So I do foresee it also needs more substantial resources to support its long-tang viability. Right. So and then we start thinking about like what can we do to make VE better. And that's a lot of work when I think about it. And if we keep going the way Vue is doing, what I really worry about is. is what if we can't make Veed sustainable enough? And it just eventually, you know,

people will have to switch away from it when it is no longer well maintained. And that's another big churn for the ecosystem because so many things already depend on it now. And I just don't want that to happen. So I was thinking, can we find a way to, A, leverage Veed to,

serve as this like sort of gateway to more unification in the ecosystem so we can maybe build more fundamental stack from the bottom up to sort of make Veed

leverage VE to unify more things in the ecosystem. At the same time if we can make all the work on these parts sustainable through a business I think that's better than seeing

So many people just working independently on a bunch of stuff, supporting tools, and then they burn out, they give up a project, they walk away, and then the next group of people come in and come up with a new alternative. And this cycle just keeps going on for the JS ecosystem, right? Because I've seen so many of such instances happen in the past. Sure. And just don't feel like it's, in a way, what I'm saying. seeing is people keep doing redoing the work and then

they try to somehow they try to figure out sustainability and many of them fail and then they give up, they move on to other things and now we are stuck with an ecosystem of every problem has like five solutions, four of them

abandoned and now you have to try to find new maintainers or a new developer will come up with a new project. I think in the early days of the job's ecosystem, having so many people just stepping up and creating solutions to problems, it's the strength of the ecosystem, right? That's what made the JS ecosystem great. But over time, a lot of the problems have, in a way, the ecosystem has matured. We are arriving at more

conventions and best practices on some of these problems that we can more or less consider solved problems. So we want to kind of, you know, find a way to, you know, find a way to provide a very solid solution to these soft problems and we want to make it well sustained through a good business model. Maybe not a good business model, but at least the business model needs to be good enough so that people can stop worrying about like, hey, well, these people just one day burn out because they can't find enough funding and just walk away. And I think the key to cracking that problem is to make the right people pay for open source, right? And that won't happen through donations. That is kind of the conclusion I sort of arrived at

after all these years of working on independent open source. Yeah. Well, that's a big thing to say coming from you because you're probably one of the best donation receivers out there. And if If you say that, then it's got to be true. Okay, so Void Zero then. Like, how does it work? What's the business model? You talk about these fundamental pieces underneath the, or like, where do those lines drawn? I have so many.

It's a cloudy thing to me right now. Please help me understand it. Yeah. So, at FOE Zero, we're building a unified tool chain for JavaScript, right? So the scope is quite large. So we would cover, so obviously there's VIT, which is at the center of it. 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 Lincter, which is based on OXC. And inside Vite, we were previously relying on ES build and roll-up. 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 Space Bomb Record Roadown

that kind of combines the strength of ESPelt and roll-up 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 VIT itself and while being more powerful. And in order to support Rodon 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 VIT,

and then extend into test, linked so that you can have a cardo-like experience. If you've worked with Rust, right, when you start learning the language, the tool chain you use is cardinal, and it covers most of the things you need out of the box. For JavaScript, we never have that kind of experience. And in a way, we're so used to,

so when people get into web dev, right? The first thing you need to do is to decide which framework you want to use, And then which build tool, which linker, which test runner, there are a bunch of conventions and best practices, but still, it's a lot, right? 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 sort of more coherent and unified experience to that. So one unified tool chain to do all these things. And 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 discuss more when we announce V-plus as a product, which is the name, the name of the tool chain is called V-plus. 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 only try to get donations from individuals. 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, you know,

because we haven't really seen some, seeing 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 wider use of these infrastructure level pieces in the jobs of ecosystem. And so to start this, did you raise money? Yes, we did. Yeah. And the reason for that was because you needed time to explore this? or yeah. 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 can, 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 Vee, there was no concrete goals of, like, what the end form of view 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. Right. So it's not, view doesn't have sort of, of a fixed scope or a road, like 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, like the things we want to do, it's a lot, right? 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 of 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 to us. Gotcha. And so when you receive the money, did you go out and then start hiring members of the VIT community basically? Yeah. So we do we hired quite a few team members from VTES, from VIT, but we also had a few folks from Bidense. They were working at the Web Infra team on Bidense, so actually a few of the earliest members of the company worked on the RSPAC project at Bidense. So they have a lot of experience and expertise in the Rust for JS tooling, which helped

us kick off the initial efforts in this area. so the folks working on row down actually working on our S pack gotcha funny story I used to call it our spec 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 R SPAC they lowercase the S doesn't make any sense but R S pack makes a way more sense than R SPAC for sure VET plus is it VET plus other features is it VIT but you pay for it is it bundled like is it VIT is multiple things? and we put them together and package them, and that's what you use?

Like, what is VET plus? I know if you don't haven't actually announced the details, but like give me a shape of the object. Sure, yeah. So V2 is a dropping super set of VT. Drop in super set. Okay. If you're using VET today,

you can basically alias V2 to V2, and everything will continue to work the same way. But in addition to VET dev and VT build, you can now also do VET linked, beat test, beat bench, feed format. I see. Yeah. So it comes integrated with a lot more capability.

So it's a tool chain instead of just a built tool. And where and when is V2? Is V2 out there? Is it going to be out there at VECConf? So we're going to, yeah, we're going to talk about more details. We're probably going to give a first demo of what V2 plus looks like in action at VTConf. Okay. Right now, it's still in active development.

So we probably want to save the sort of big reveal at the conference. Sure, absolutely. So after the conference, if I'm Jared the open source hacker and I want V2, I'll be able to use V2Pus without any money with money involved. I'm just a, I'm just Jared the dev. Jared the Dev, if you're just an individual hacker, you can definitely use V2 without any restrictions. Okay. Now I'm Jared the well-funded Fortune 500 company. I cannot use V-plus without money, correct?

So you can still try it. You can still like 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, Rodown, OXC, VT test, they remain open source, remain exactly what they are today. Vplus is a combination of these things, plus a few more Vplus-only features. So we are actually working on a integrated task runner slash caching system for Moto Repos, which tightly integrates with all these underlying tools. So that allows us to smartly engage. 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 VIT build through V2, right? We know exactly what the inputs are and outputs are. So we just cache it automatically. So if you edit a file, but it doesn't actually affect the task you're running, you would just get a cached output automatically. Okay.

Okay. And that will be a V-plus thing. So does that require a void zero server somewhere in there? It doesn't. It's, right now it's local. Okay. Do you imagine a world in which void zero servers are involved? 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 service setup. But we'll probably make it possible, like, we'll definitely make it feasible to use your own storage back end. Gotcha. So as Jared, the 14500 software team, and I want to use V-plus, like, do you have it figured out in terms of my understanding of that whole deal?

Like, where do you interface to me when I know I have to actually come give Evan and his team money? Like, how does that, have you got that figured out yet? So I don't want to get into too much detail. But, yeah, yeah. But we'll have a more formally documented. How does this license work? You know, the FAQ and everything. We don't have that up on the website by the time we announce it.

But VET and its subcomponents, they all remain open source licensed? Yes. And so this new V2PUS will have its own proprietary license that you will tell more details about at VITCOM. Yeah, yeah. So we'll probably call it source available still, right? So you'll be able to look at the source code, open issues on GitHub, and everything. But we're trying to come up with a license that would make as many people

able to use it freely as possible, but still allow us to capture value from the right group of users that we believe who owe the most to supporting such infrastructure tooling for a entire ecosystem. And if this project succeeds, you believe or you hope that it will be reproducible by other people, right? Like, whereas the previous one, Evan succeeded with you and with that sponsorship support. But it wasn't really a pattern that people could necessarily follow unless they were. also outliers yeah but your hope with void zero it seems and with v this time around is what if we can build something in such a way that you could take that pattern and perhaps in your neck of the

woods or your little open source area of the world reproduce it and create a sustainable project yeah if we can sort of be the first example of that we can also normalize the acceptance of such a model in the corporate world where, you know, there will probably be some challenges for companies to sort of realize, okay, this thing is actually using a different license, right? And if we can make this model sort of acceptable in the corporate world, where next time they see it, they go, oh, they're doing the same thing that Vee Plus is doing, right? Makes it easier for other people to replicate this.

So Veed is open source and VET Plus is source available. Yeah. Cool. Well, I hope it works. I'm excited to hear more as you announce the details at VietConf. I appreciate all the efforts you put in over the years and I guess the trailblazing that you've done with Vue. And now with VT, hopefully Void Zero is yet another trail blazed and one that people can follow after. And I wish you all the success in the world.

Thank you. Anything I didn't ask you that you'd like to get on the record or say to the open source world before I let you go? Probably not. I mean, I probably said more than I was planning to. But yeah, we're planning to announce a lot of this at VConv anyway. So, yeah. Well, there will be a lot more details on the technical front, how Vplus feels, how it works and everything. at the conference so make sure to tune in well i will have to wait but nobody else will have to

by the time this is out to our listener and to our viewer check out viet conf check out the viet documentary because it's out there it's to be watched i've seen a rough cut and it's very good you're going to enjoy it so definitely uh tune in and see what evan and his team are up to all right evan thank you so much this has been awesome talk to you soon thank you so what do you think about the future of web tooling has evan and the team placed vete in a position to lead us to that future are you cool with void zero and the whole vete plus idea or maybe not so much let us know in the comments yes every single changelog interview gets its own thread in our totally cool totally free community zulip chat sign up today at changelog dot com slash

community. Thanks once again to our partners at fly to I.O and to our sponsors of this episode, depot.dev, fabi.a.i.i and mirro.com. Thanks also to the one, the only, the mysterious, breakmaster cylinder. All right, that's all for now, but we'll be back in your feed talking to Jose Valim on change talking friends on Friday. So, I'm going to be able to be. Ain't know Oh Oh

Ain't Ain't