Subscribe
Share
Share
Embed
Come join us as we discuss everything open source with guests that are pillars in the industry. Welcome to The Secret Sauce.
Welcome back to the show. We're about to learn the secret sauce. Evan, how are you doing? Great. Yeah.
Bdougie:Welcome to Oakland. Yeah. First time here. Yeah. Yeah.
Bdougie:I'm glad you made it across the bridge, and, also glad that we caught you during your your a couple conferences and events that you
Evan You:Yep.
Bdougie:Just got shoehorned into and stuff like that.
Evan You:So pretty amazing. Yeah. I'm I'm just, like, meeting all interesting people between these events and stuff. So, yeah, always fun to, you know, get to talk to different people.
Bdougie:Yeah. Yeah. So I'd love to catch up and find out what you're working on now. So I see you got the the Vite swag. Yeah.
Bdougie:Do you wanna tell us what Vite is, what you're working on?
Evan You:Sure. So Vite is a JavaScript build tool. I remember when we put that slogan on when it showed up on Hacker News, all the comments were like, what is a build tool, Ethan? Right? So, but in its essence, nowadays, when we write web applications, we don't no longer directly very few people actually directly ship the code they write directly to production.
Evan You:So there's a process of transforming things, putting bundling things together, doing development. We also need to handle hot updates. Different frameworks will add a bunch of compilation steps on top of it. So a build tool is essentially the thing that ties all these steps together and, transforms your source code into something you can ship to the users.
Bdougie:So first commit for Veep, I guess, first public commit fee. I don't know if it was public the entire time. What year was that? When what are we talking?
Evan You:I think it was 2020, April 2020.
Bdougie:Okay.
Evan You:Wasn't even called Veech back then. It started out as a very small prototype called, Vue Dev Server. Okay. Originally, I was just looking for a way to quickly prototype Vue projects, because we were we had an official Vue CLI back then. It was pretty heavy.
Evan You:So every time we spin up a new project, we had to install tons of dependencies, and it takes quite a while to spin up the project. So I wanted something to just, like, start up instantly and do as little work as possible. That was really, like, build trying to buy build up for myself and also, at the time when browsers started to support ES modules natively. So I was just playing around with ideas to see if I can get, build a dev server that takes a native ESM request and transform a view file on the fly and send back JavaScript. That was the main thing I was trying to do.
Evan You:And there were
Bdougie:no other solutions to do this at the time?
Evan You:Not that I'm aware of. Actually, so when I start building it, I didn't think that too much about, like, what other things were out there. I was just, first, I got the idea of, like, transforming things from HTTP request working. And then the next step was trying to figure out hot module reloading because that was the main thing people use these build tools for. I wanted to be able to edit my view components and see the the state, see the page update instantly without reloading.
Evan You:That was the main thing. So, I think, initially, I only got to the step where I was able to load Vue files over h t, e s m requests. Then I put it aside for a while because I was actually working on Vue 3 at the same time. Yeah. Kinda use it as a sort of, like, diversion or, like, just a creative outlet for it was a pretty, like, you know, grueling process working on Vue 3.
Bdougie:Yeah. I mean, it that's an understatement too because I remember Vue 3. So I, I'm a React person. Like, that's my choice of front end frameworks, but, like, I've always tinkered with every single one of them out there. Because I I I mentioned off off camera, but I can folks know I worked at Netlify.
Bdougie:So, like, my job was to know all of them, doing DevRel eventually there. But I I mentioned this because Vue 3 was a big release.
Evan You:Like, there
Bdougie:was a lot of back and forth, and Yeah. RC was, like, pretty prolific. Yeah. It took a
Evan You:really long time mostly because I think we we cramped too much into the major release, in a way, in in hindsight. But but you don't get to do this kind of big breaking releases very often for a project like Vue because we just have too many users. So so the the idea was pretty much like we're breaking things anyway. Why don't we, you know, introduce some new ideas? And turns out that means you also have to go through a pretty complicated process because, like, we wanted to be open with the design decisions.
Evan You:So we had the RFC process where we basically every breaking change and major API decision, we were trying to have an open discussion and have people involved in voicing their opinions. I think that's that's necessary, and that's helpful in many ways, but it also when you have something that's controversial, it can just eat up so much your, you know, time and energy trying to convince people and polish in the ideas, iterating it over time. Like, the composition API in Vue 3 actually took, like, almost a year from conception to actually landing something, just because it was, so controversial in the beginning. But Yeah. But nowadays, a lot of people love it.
Evan You:But it also took time for us to polish the development experience of that API over time to make it sort of, you know, better and better and, eventually being able to replace a lot of the existing usage out there. Yeah. But that was a long process. It was, so during that very long process of working on v three, which almost took like, if you count into the ink account in the prototyping phase, it's, like, 4 years Wow. Total.
Evan You:But, like, officially working on, like, like, starting from the alpha phase to release was, like, almost 2 years. And doing that, I worked on Veet. So Veet was kinda like my escape from all the pretty stressful stressful, discussions on in RFCs. And I was just trying to build something completely almost unrelated. It was still originally designed to support Vue, but the scope was just so out there.
Evan You:It's, I I had completely freedom on just deciding what to do.
Bdougie:Yeah. I I wanna go down that path to Veeam, but before I I wanna just double click on the view stuff Mhmm. Real quick because, like, the amount of back and forth in ROCs like, I know your open collective is, I guess, would you say it's, like, well funded at this point? Yeah. Yeah.
Bdougie:So, like, the you got a open collective. So who who owns the decision making when it comes to view? Like, it's are you still the figurehead of
Evan You:what you is? Yes. So I am the BDFL. Yeah. That's actually, like, public stated in the governance document, same view.
Evan You:So I make the final calls. And if I want to, I can just say this is the way we're gonna go with. But if you look at our governance document, it's laid out in a way says, okay. Evan is the project lead. Evan is the PDFL.
Evan You:He has the final call, but he has responsibility in, you know, listening to the feedback from community members and team members, with you know, I basically have the responsibility to make my best effort to take into account all the feedback from people who are stakeholders in the ecosystem. And I think the way open source works is if I make bad decisions, if people are really not happy with it, they can fork you. Right? Yeah. If there are enough people who are unhappy and dedicated enough to think they can build a better version of Vue, they're welcome to do that.
Evan You:In fact Has it happened yet? No. No. So that means I'm doing an okay job Yeah. So far.
Evan You:Right? Like, say, we've seen that in the past with, like, IO, IO JS or, Crab Crab language or something like that. I think, you know, the power dynamics of open source is, you know, I can make decisions about this project, but because it's open source, it's permissive licensed. Right? Anybody can actually just fork it if they think they can do it better.
Evan You:Yeah.
Bdougie:So how do you so you have governed stock in your the BDFL, which actually I didn't I didn't know that. But yeah.
Evan You:What's the acronym the for BDFL? Benevolent Dictator For Life.
Bdougie:Yeah. Got it. Yeah. Which is like we got that from the the Python guy. Yeah.
Bdougie:But so I was asking, I was going down the the the questioning of okay. So you get Open Collective. Do you feel like there's, like, companies or other big donations that try to dictate decision making?
Evan You:Definitely not. We intentionally structured Vue in a way that sponsors will not be able to steer the technical direction at all. So, essentially, in pure technical decision making, our only priority is to consider user and community feedback, make sure users are happy. That's really the only priority.
Bdougie:Yeah.
Evan You:So we intentionally want to avoid the situation where, like, we are too reliant on a single big sponsor that we are, like, distorting the, the technical direction to benefit a specific sponsor. That's something we, like, intentionally want to avoid. Yeah. And I
Bdougie:I feel like there's, like, there's a lot of, like, other languages and frameworks that have come out, like, since the time of you. And, personally, I don't know if we've seen a lot of, like, large adoption outside of, like, AI. So, like, Linkchain had a lot of adoption. There's a couple other things that that shipped since then. But it's like, one thing that I was tasked on back in 2019 at GitHub was, like, top 100 projects on GitHub.
Bdougie:So how how do you dictate that? And, like, we figured out the metrics, really came down, like, issue authors. Like, who outside of the Vue core team are making issues? How big was that. But at the time, Vue was, like, 90,000 stars.
Bdougie:So, like, automatically, it was already top 10 Mhmm. Or top 3 at that time. And there's a lot of attention. So, like, how do you manage how do you personally manage all that attention into a project that you started 10 years ago Mhmm. As, like, a cool thing that's, like, solve problems quickly?
Evan You:Yeah. I would say high level decision making at this point is, we are definitely a lot moving a lot slower Yeah. Compared to, say, when we just got started. In a way, it's also partly intentional because we, during the v two two, v three transition, we made a lot of decisions. And those little decisions kind of add together and compound into relatively high migration costs for users.
Evan You:And I feel like the the Vue community was kind of tired of the churn during this transition period and want to we we intentionally want to give them a longer period of stability. So a lot of the we're intentionally avoiding this kinda, like, big, like, paradigm shift or, like, this is the new way of doing things kind of situation, focusing on small incremental internal in like, improvements that really doesn't affect the end user experience that much. Yeah. So we are currently in that stage, like, post view 3, letting the ecosystem heal, and we're focusing on just, like, quality of life improvements here and there. Like, a lot of things we did, like, we rewrote the parser.
Evan You:We rewrote the reactivity engine, which, don't really change in the way things work, but it just make it faster, leaner, more efficient. Yeah. So we're basically using the time to do this kind of things, which is good because we can, just focus more on the purely technical improvements, less about just decision making and, like, getting buying from stakeholders and stuff like that. And and we do have, you know, an RFC repository where we let people post their ideas on how they think you should, you know, add new features, but we're really, really cautious about adding new features. Usually, especially major new features, we typically would go through this sort of IFC prototype released as an experimental feature, let us simmer for a while, and then when we feel there's enough real world feedback, we stabilize it.
Evan You:Like, the latest example is probably the define model macro in 3.4. That took like, that was experimental for maybe 6 months. And and, interestingly, because of, you know, how big the scope the framework has already become, almost every new feature kinda have all these cross cutting concerns with all the previously existing features. So, adding a new feature has definitely also becoming more difficult, and time consuming. So, basically, we're just trying to be extra careful with this kind of stuff.
Bdougie:Yeah. Yeah. And that's I I mean, that's kinda what you get in, like, maturity and what what the framework is today. Like, we see that with, like, Ruby on Rails. They've actually shipped a lot of really cutting edge stuff in the last couple years.
Bdougie:But, for a long time, it felt like, oh, Rails 4 or maybe 5 might have been, like, the most consistent. Yeah. You didn't you didn't have to, like, any sort of weird migration steps to do. And I think with Angular, there's been some consistency as well. Actually, I think a lot of the frameworks that I I've used in the past have got to that level at this point.
Bdougie:But I wanna take a step back to Vite too as well. So, like, you started with Vue dev server. Yep. But now it's called Vite. Yep.
Bdougie:So what was that decision process of, like, this is different?
Evan You:Mhmm. Yeah. So, after I, got the initial prototype working, a few months later, I came back to the prototype again. I was like, this time, I'm gonna I'm I'm gonna try to crack the hot module replacement thing. I think I was again, I was working on v three.
Evan You:And one day, I was just trying to trying to get away from the existing problems. And, then I started thinking about hot module replacement, and suddenly something clicked. I was like, oh, maybe this is how I could make that prototype actually do hot module replacement. So I, picked it up again, hacked until, like, 4 AM, and I got it working. So I was super excited.
Evan You:So that was April 2020. So I posted a tweet saying, okay. Like, I think I got, like, hot module replacement with the transforms and everything working over native ESM. And I think, like and it's it's super fast because there's no build step per se.
Bdougie:Yeah.
Evan You:So super excited and decided to push this idea further. So starting from that prototype, I actually, like, spend, I think, at least, like, 6 to 7 months straight just working on Vite. I kinda paused Vue development during that period. That was just, making sure all the things I wanted in a proper dev server was there. And we got to a point when it was 1.orc.
Evan You:I was pretty happy with it. But during that process, I started to research other existing solutions. So there were a few other ones actually also doing similar things. So there was, app web slash dev server. It's from the web components community.
Evan You:Then there is Snowpack, and there was, WMR, which is from the the Preact team. Jason Miller is the the author. And, more or less, I think, was the first one to actually get proper hot module replacement working over native ESM, but the it was obvious that the idea of loading, you know, doing bun no bundle development over native VSM was becoming a thing. So I realized, like, I was building it only for Vue, and it was was working well for Vue. But I realized, okay.
Evan You:Like, this doesn't really only apply to Vue. It's you know, other people are building this as generic, multiple you know, general purpose dev servers. So I realized, okay. Like, this idea and the hot module replacement in Vue dev server also wasn't Vue specific. Initially, it was, but I managed to make it basically framework agnostic.
Evan You:So I was like, okay. Like, this should just be framework agnostic. Vue should just be a plug in to this new thing. But in order to cleanly extract the plugging architecture, I had to do
Bdougie:a rewrite rewrite pretty much. Yeah.
Evan You:Like, the in the 1 point o branch, Vue logic was basically hard coded into the whole thing. I had to, like, spit it out and come up with a proper plugging system, which I eventually decided I'm not going to release 1 point o. I just, like, started a rewrite. Okay. So the rewrite, took inspiration from WMR.
Evan You:So, WMR have have this interesting idea of essentially, creating something called a roll up plug in container that is not roll up, but is able to run roll up plug ins. So that's something we still use in Vite now. So that that idea came from
Bdougie:the Why not Rollup? Is it we're we're up too much to to bring
Evan You:in to the I guess Because roll up is a Node. Js build tool. So when you are, when you're running a dev server, there's no way to invoke roll up plug ins without actually doing a bundle with roll up. But because we're loading things over native VSM, there's no bundling to be done. Right?
Evan You:But we want to be able to use the same plugging format and, you know, reuse the roll up plugging ecosystem and also because we're using roll up for production builds. So we want this, like, same plugging format that can be applied during dev server and production builds at the same time, which means we need to find a way to emulate a plug in runtime for Ola pretty much. So that idea came directly from WMR. So, shout out to Jason Miller. Yeah.
Evan You:And, so the rewrite was pretty successful and, which allowed us to have a Vue plugging, a React plugging, and we can also support React hot module replacement. So from there, I think we started to got decent traction. And another interesting thing that really decided the the developments later was, because I wanted to be able to build server side server side rendered apps with Vite. Right? And, so we realized when you build server side rendered apps, there's actually an interesting requirement where you need to load you need to run your application in the browser.
Evan You:You also need to run your application on the Node. Js side at the same time. So you need some sort of way to run that code. You need to transform it first and run it in Node JS. And you also kinda want to have this sort of hot module placement on the server side, because previously, we've done, like, manual webpack setups for Vue with server side rendering, and the thing we did is, like, you basically have to rebuild the whole SSR bundle.
Evan You:You're building 2 bundles, and you're doing full bundle rebuilds on the server side on every change, and that was inefficient. So we were looking at ways to do that. And at that time, Rich Harris was working on Sveltekit, and they were initially using StowPack. And, basically, we were running into the same problem at the same time. So Rich came up with an idea that, that we still kinda using Veed today.
Evan You:We are coming up with new APIs, but, like, it's still the current way of doing things is, you would have a custom transform that takes user modules and essentially transform into something you can become virtual modules that you'll store in memory. And you maintain a virtual module tree, and you, like, replace the modules that's, that's updated. And you are able to run the whole thing in Node. Js. We call it the the SSR load module API.
Evan You:So, we saw that PR and felt like it's a good good idea. So, we essentially replicated the API in Vite. So yeah. So the SSR load module, the whole idea came from Rich Harris, which he implemented first for Svelte kits in Snowpack. But at a later stage, this API got got baked into Vite.
Evan You:And we have, you know, examples of how to do very lean setups for React and Vue SSR in Vite. And with those examples, people realize, okay. This is not too far from actually a meta framework. So that's kinda served as the, the starting example for people to build their own meta framework on top of Vite, and that became a thing. So more and more people started to use Vite to build their own SSR meta frameworks.
Evan You:And, later on, I think the, when the Snowpack team decided they want to pivot into building a framework, Astro. Yep. They decided they don't want to maintain their own build tool anymore, and, they moved over from Snowpack to Vite, essentially. So as a result, SpellKit also moved from Snowpack to Vite, and, and now we see more and more other frameworks like, QUIC, SOLID, 10stack. So, yeah, pretty much if you see a a new, meta framework that's, that involves transforming some files into JavaScript and they need to do server side rendering, there's a good chance it's using Vite nowadays.
Bdougie:Yeah. Which is, like, kinda mind blowing. And I think Remix was, like, the most recent, like Yeah. Adding to, the the Vite. Yeah.
Bdougie:Folks are using Vite, and they're they're they're build tooling and dev servers, which is amazing to see because, like, there there are, like, still other options when it comes to, like, these solutions and, like, even snowpack being one of them. Well, snowpack's not around anymore, but Mhmm. It's like Fred actually was on this podcast, and we talked about things like snowpack and, like, making decisions to build Astro and, like, what they were seeing at the time and Mhmm. Why they made those decisions. But full circle, them using Vee.
Bdougie:After, like, really kinda kicking the tires and, like, building that originally. Yeah. Like, how does it feel to now you you have Vue, which is the thing that people use and they choose for building, like, production grade websites and web apps. But now you have this thing that everyone else now is building in Vite. So, like, they're they're very different, like Yeah.
Bdougie:Projects now that Vite and Vue. So, like, how does that like, the the the team that works on Vite today Mhmm. Same thing with, like, sponsorship and and making decisions. Like, are you also the BDFL for Veeet as well?
Evan You:I think I'm definitely less of a BDFL in Vite compared to Vue. My con like, so I still review almost every single line of code that goes into Vue nowadays. But on the Vue side, I'm much more hands off. Interesting. So the the Vue team is much more in a way, like, the the made up, I think, on the Vue side, the ecosystem is pretty big nowadays.
Evan You:So we have not just Vue core, then we have the Vue router, our same management library, We have our documentation, dev tools, language tools, IDE support. Right? Many of these pieces outside of UCORE are also kind of delegated to team members. They have a lot of autonomy on deciding what API they want to do. They do the daily maintenance, and they have the, you know, full, basically, flexibility to decide when to do a new release on things like that.
Evan You:Obviously, we try to coordinate big changes together or, but on Vue core, I'm still mainly the one who's deciding the direction. I review the pull requests. So, usually, we have team members who can merge relatively or small changes, but if it's something significant, I definitely still review it. But on the side, we've seen in the past 2 years, you know, team members just, individually being able to resolve relatively significant changes, push, you know, big decisions, and, make very significant improvements to performance, push minor releases, sometimes even without me directly involved. So and I think that's a good thing.
Evan You:I'm actually happy that I'm able to, you know, create a team that is able to push the project forward without me being the bottleneck. And I think that's necessary because, you know, my bandwidth is kind of stretched in all directions. So I do want to see continue to succeed. And to to see that happen, we need a team that is able to just move, you know, without me having to be on everything. So that's also kinda intentional.
Evan You:Like, I was, the Vue team grew very, very organically. Most time, people are long time contributors who, like, just stepped into the rows very naturally. The Vite side is more like I decided to set up a team early. I see people who are making great contributions, and I try to, like, basically talk to them and say, hey. They're doing great.
Evan You:You should join the team. You should do this. I want to give you more responsibility. I want to give you more, you know, autonomous autonomy to to do the things you wanna do, to to make the changes you want to to, see happening. So so we
Bdougie:have this, on our YouTube, we have this, YouTube shorts, called looks good to me. And these are, like, usually storytelling of interesting contributions within, like, the community that, like, were inflection points. So I actually wanna, like, ask you the question of, like, what were the first signals that you saw? Like, hey. You should join the v team.
Bdougie:Like, what were those contributions?
Evan You:Yeah. So, it's interesting. Yeah. There are definitely very obvious signals. When I Yeah.
Evan You:When I see people making high quality pull requests a few times in a row, some of it, it's is a little bit hard to explain. On the view side as well, like, sometimes I see a pull request, and I instantly see that this person gets it. Yeah. It's just like the maybe the way they think They got the sauce. Kind of clicks with you.
Evan You:So for example, we have a current core team member on Vue's side where, he's super young, but, like, the pull request that he make, the quality of the code, the way he organizes stuff, and the way he makes the certain decisions, makes me feel like, okay. This is probably how I would do it if I were to do it myself. And may that kind of just naturally builds trust. And if he keeps doing you know, if the person repeats this pattern a few times, then the the trust just kind of compounds. I'm like, okay.
Evan You:This guy knows what he's doing, and I can trust him to make the right decisions even if I'm not directly paying attention to it. And that's, that's important. Right? And I I think it's, if you're a maintainer, you will like, different maintainers have different style of working on their projects. Right?
Evan You:Like, we would have different code preferences. We have different design philosophies on how the project should work. So, usually, a good contributor understands your your preference, your philosophy very instinctively intuitively. I think that alignment is very key. Right?
Evan You:Some people can be really technically brilliant, but maybe they just disagree on almost everything with you. Yeah. And they wouldn't become good contributors or team members. It's Yeah. You right?
Evan You:So it's like technical skill is not really the only factor here.
Bdougie:Yeah. Yeah. I I did a tweet about how we we brought up some interns last year and the way we we had folks build the same project. Very simple. It is a tutorial.
Bdougie:You follow the tutorial, or you can go off the tutorial, whatever. But what we've really reviewed was the PR communications. Yeah. Because, like, we wanna be async, and we actually brought on 2 folks in India. Yeah.
Bdougie:But communication is very paramount because, like, I'm waking up and, like, I'm starting, like, on the keyboard 7:38, but they're, like, winding down by then, or they're gonna work in the evening with me, whatever. But communication is very, very key. And Yeah. You you mentioned this thing about this, like, like, I had mentioned, like, in in passing, like, they have the sauce or they have, like, that sort of they get the the ethos of the project, the retainer. We actually had this metric that we're shipping in a couple weeks called, confidence.
Evan You:Mhmm.
Bdougie:So, like, we've we've gone through a bunch of data and identify, like, if folks could make that repeat contribution
Evan You:Mhmm.
Bdougie:Like, they get a tick into the confidence bucket. Right. And, like, those are the signals of, like, quality and confidence. You could actually start identifying these trends. Yeah.
Bdougie:And what's interesting, you could also see these contributions historically where they had, like, the confidence in other places. Mhmm. And I'd mentioned Anthony as as one of these examples. Yeah. Who was early days in the in the, core team contributing, But his his confidence level, which he like, confidence verbally saying it out loud, we could say like, make this differently.
Bdougie:But, like, oh, yeah. He's confident. He's got he's an extrovert. But it's really more, like, the ability to, like, jump in and, like, understand, like, how things are
Evan You:Yeah.
Bdougie:Done here and, like Yeah.
Evan You:I think, yeah, I think one important, sign of a good contributor is, someone who is willing to understand the project main, original author or maintainers, you know, like, how they think. If you're willing to put yourself in their shoes to understand what the project really needs and then tune your contribution in a way that fits the project. Like, Anthony is really naturally good at doing that. Yeah. Like, when he jumps into a project, he has the empathy to say, okay.
Evan You:I know this is someone else's project. I'm going to first look how the look at how they do it. Yeah. Then I'm gonna make my contribution fit along really well. Like, at the same time, it's something, like I feel like that's, like, important to add to the project, but, like, in a in a way that is you know, aligns well with what the project is already doing.
Evan You:Yeah. Not all contributors are aware of that or are willing to do that. Yeah. Because it also takes effort.
Bdougie:So So what what do you do? Because Vue's got a lot Veepe has got a lot of interest and attention. So, like, what do you do when folks just don't really get it, but they Mhmm. Are technical? Like, they can write code.
Bdougie:Yeah. But they have basically the wrong ideas or the wrong approach. Like, how do you do you guys use this in the contributing guidelines and you just, like,
Evan You:work it out? So, like, we do try to write down as much as we can to, like, guide people. Basically, there's a pull request, template that try to nudge people into the right direction. Like, maybe you like, if you this is a big feature, you should discuss it with us first. You know?
Evan You:If you're adding some feature, you need to, like, clearly describe what problem you're solving in the first place. Because, like, over time, like, I've been reviewing so many pull requests. A lot of them, very typical ones are people just coming and drop a big PR without much explanation. It probably solves their problem, but they don't even bother to explain what their problem is. They just feel like, okay.
Evan You:This solves my issue. I'm gonna just drop it here. And in a way, it's it's definitely better than not making any contribution at all. Right?
Bdougie:Yeah.
Evan You:But at the same time, it's kinda difficult for us to decide what to do with this kind of PRs because, we can't just merge it as is because we don't feel like we understand well enough. Yeah.
Bdougie:But at
Evan You:the same time, communicating with someone like that is can be sometimes difficult because they feel like I've already done you a favor. I've worked on something. I don't wanna spend more time on this explaining it.
Bdougie:Yeah. It's it's it's a catch 22 because, like, everyone benefits if they explain it upfront. And if they have, like, they could cite an example, like, oh, I saw this in my project, or here is, like, reproducible steps, or here's a link to a stacklets. But I I think so I I have a lot of smaller projects that I've, like, nothing at the level like a v or a v, but I'll get contributions like that. And Yeah.
Bdougie:I I I feel like I'm I I, mentored at boot camp. Like, I love, like, walking alongside people and, like Yeah. Learning together or jumping on a call. Like, that's I've got the bandwidth for that. I don't think everyone else has a bandwidth.
Bdougie:Yeah. So, like, I'll jump on a call or jump in a PR, like, try to pull and what's the problem from them. But I also respect that. Like, there's a certain turn where you just cannot do that anymore.
Evan You:Yeah. Like, if say, I think in the early days of you, like, I definitely had much more bandwidth and patience to just, like, pry out, like, what led them to do changes like this and try to understand their intentions better. But at a certain point, it's just impractical, like, for us to dig into every single one of, because we have issues that's like that too. Yeah. Like, people report bugs, then we have to, kind of go back and forth, taking out the information asynchronously.
Evan You:Yeah. And doing that with you know, we get anywhere between, like, 5 to 10 issues plus PRs every single day. You know, doing that repeatedly can burn you out really fast. So I think, like, we've over time, we've tried to do a lot of things like explaining to people why reproductions are absolutely necessary and put pull request templates, trying to guide people through the thought process that's needed in landing a change in something like Vue, which is, it's it's used by too many people. So every change that goes in kinda has a lot of unseen consequences.
Evan You:Like, some seemingly harmless changes we've landed end up being big regressions that we had to, like, do hot patches on. So over time, we kinda we just, like, become naturally very, very cautious about every change that we we eventually ship. So, and that takes time to explain to people. Like, so, first time contributors aren't aware of all the context, and we try to provide that context in writing as much as possible, but it's still proven to be difficult because you you will always get new contributors all the time.
Bdougie:Yeah. Yeah. It's almost like there's a and I toyed at the idea, when I was at GitHub around, like, structured onboarding when it come to open source. So, like, pick and choose whatever things steps that people have to go through. And I think, like, there's a company called Swim that originally that was the original product was like Mhmm.
Bdougie:How do you, like, on this on the CLI or the command line, walk through contributing the projects, but also learning the ethos. And there's a couple other projects, which, if folks are watching this, like, link them in the comments. Mhmm. Because I'm actually really intrigued if there are, like, anybody solved this.
Evan You:Mhmm.
Bdougie:So, like, clone the repo, start a thing, and before you contribute, go do, like, this little, like
Evan You:Right.
Bdougie:Small not even test. It's like side side quest of, like, oh, yeah. I could learn why we made decisions here and, like, the Vee and Vue ecosystem. But, we only have a few minutes, but I wanted to actually, like, set the stage for, like, where is Vee today? Mhmm.
Bdougie:And I guess I'll ask the question where I maybe I I don't know if it's obvious, but, like, should Veet be a company at this point? Because it's got so many hands in so many different pies, and depended on.
Evan You:I think there's a possibility for that. Yeah. Especially the way we think about the long term, like, when Veet was, I think one of the things people have still have reservations about Veet is that we do rely on, like, different under underlying tools, like, yes, spin and roll up, which we don't really control. There are some things we want to do. For example, we want better code splitting in esbuild.
Evan You:We want faster builds in roll up, but it's very difficult for that to happen, like, unless we kind of take over the environment, which isn't really practical Yeah. On the other hand. So we're thinking about, like, the fundamental improvements to Vite if we want to because we see it slowly becoming sort of the shared infrastructure layer Yeah. For high level frameworks. We also see a lot of single page applications just being directly built with Vite.
Evan You:Right? And, so Vite's role is slowly kind of becoming more and more important for the web ecosystem as a whole. And we're thinking about, like, what is the if we were to, you know, keep serving this role well, like, many years into the future, there are still some pretty fundamental problems we need to solve, and that does require much heavier investment. Like, say, you know, rewriting something like a bundler is nontrivial work. So which will require, you know, significant resources put into it to to find the right people to work on those problems.
Evan You:So so I'm trying to, you know, put together, you know, the putting the dust, getting the strings together to have people to work on those problems. And that may require, you know, a proper business plan to make this sustainable for the long term. And that's, that's actually kind of the bigger problem I wanna tackle is on the Vue side, it's more like an independent lifestyle business thing, where we are doing pretty well based on the Vue ecosystem, like, educational partners. We have, like, end of life support partners where they are kicking back revenue to the project because they are built on you know, their businesses is is relate directly related to us. So Vue is kind of a pretty nice little ecosystem of its own that's already sustainable, and I think that's nice.
Evan You:But at the same time, it's not something that, can big enough to support the kind of thing we wanna build for the entire web ecosystem as a whole. Yeah. So on that front, I think Vite has strong potential in becoming something in becoming something even bigger, and that may require us to put into, you know, put into it more some more significant financial incentives to get
Bdougie:the right people to work
Evan You:on it. So that's something we're exploring at the moment.
Bdougie:Cool. Yeah. Exciting. I mean, I I'm bullish on Veet. I have definitely hitched my wagon on that, and it it's definitely my go to for building, like, my own micro frameworks to pick and choose, like, how I wanna develop moving forward.
Bdougie:So exciting to to see the pro progression and, like, what comes out of this. Oh, stay tuned. Yeah. And and stay saucy, everyone. Providing insights by the slice.
Bdougie:If you're in San Francisco and interested in being a guest on the show, find us on Twitter at saucedopen, and don't forget to check out Open Sauced at opensaucedot pizza.