Why is Vite Everywhere? | Evan You

welcome back to the show we're about to learn the secret [Music] sauce Evan how you doing great yeah welcome to Oakland yeah first time here yeah yeah uh I'm glad you made it across the bridge and uh also glad that we caught you during your your a couple conferences events that you just got shoehorned into and stuff like that 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 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 vit Swag yeah um do you want to tell us what V is what you're working on sure uh so V is a JavaScript build tool um I remember when we put that slogan on L waya showed up on Hacker News all the comments were like what is a build tool even right so uh 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 so there's a process of transforming things putting bundling things together uh during development we also need to handle hot updates um 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 um transforms your source code into something you can ship to the users so first commit for V uh I guess first public commit V I don't know if he was public the entire time um what year was that when what are we talking uh I think it was 2020 April 2020 um wasn't even called V back then uh it started out as a very small prototype called uh view Dev server okay uh originally I was just looking for a way to quickly prototype view projects um cuz we were we had an official view CLI back then it was pretty heavy um 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 it for myself and also uh at a time when browsers started to support es modules natively so I was just playing around with ideas to see if I can get uh 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 um and there were no other solutions to do this at the time not that I'm aware of um actually so when I started building it I didn't think that too much about like what other things were out there I was just um 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 loading because that was the main thing people use these build tools for uh I wanted to be able to edit my view components and see the the state uh see the page update instantly without reloading that was the main thing so um I think initially I only got to the step where I was able to load View files over HT uh esm requests um then I put it aside for a while cuz I was actually working on V3 at the same time yeah uh kind of use it as a uh sort of like diversion or like just a creative outlet for it was a pretty like you know gring process working on V3 um yeah I mean that's understatement too because I remember V3 uh so I I'm a react person like that's my choice of frontend Frameworks but like I've always tinkered with every single one of them out there because I I I mentioned off off camera but like and folks know I worked at netfi so like my job was to know all of them um doing Dev R eventually there um but I me I mentioned this because V3 was a big release like there was a lot of back and forth and RC was like pretty prolific yeah it took a really long time mostly because I think we we cramped too much into the major release uh in a way in hindsight but um but you don't get to do this kind of big breaking releases very often for a project like view because we just have too many users um so so the the idea was pretty much like we're breaking things anyway why don't we you know uh introduce some new ideas um 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 so we had the RFC process where we basically every braking change and major API decision we were trying to 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 polishing the ideas iterating it over time like the composition API in view3 actually took like almost a year from conception to to actually landing something um just because it was um so controversial in the beginning but uh but nowadays A lot of people love it um 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 uh eventually being able to replace a lot of the existing usage out there um yeah but that was a long process it was um so during that very long process of working on V3 which almost almost took like if you count into the in count in the prototyping phase it's like four years W total but like officially working on like like starting from the alpha face to release was like almost two years and during that I worked on vit um so vit was kind of like my escape from all the pretty stressful stressful uh discussions on in rfc's and I was just trying to build some something completely almost unrelated it was still originally designed to support view but the scope was just so out there it's uh I I had completely freedom on just deciding what to do yeah I I want to go down that path to V but before I I want to just double click on The View stuff real quick because like the amount of back and forth in rscs like I know your open Collective is um I guess would you say it's like well funded at this point yeah yeah so like the you got open Collective so who who owns the decision-making when it comes to view um like it's are you still the figurehead of what view is yes yes so I am the bdfl uh that's actually like public stated in the governance documents in view um so I make the final calls uh and if I want to I can just say this is the way we're going to go with uh but if you look at our governance document it's laid out in a way says Okay evan is the Project Lead Evan is pdfl he has the final call but he has responsibility in you know listening to the feedback from community members and team members uh 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 um 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 if there are enough people who are unhappy and dedicated enough to think they can build a better version of you they're welcome to do that in fact has that happened yet no no so that means I'm doing an okay job so far right like say we've seen that in the past with like IO uh ijs or uh crab crab language or something like that I think you know uh the power dynamics of Open Source is you know I can make decisions about this project but because it's open source it's permissively licensed right anybody can actually just Fork it if they think they can do it better um yeah so how do you so you have govern stock in the bdfl uh which actually didn't I didn't know that but yeah um what's the acronym the for bdfl benevolent dictator for Life yeah got it yeah which is like we got that from the the python guy um but so I was asking uh I was going down to 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 this decision making definitely not we intentionally structured view in a way that sponsors will not be able to steer the technical Direction at all so um essentially in pure technical decision making uh our only priority is to consider user and Community feedback make sure users are happy that's really the only priority yeah 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 um the technical direction to benefit a specific sponsor that's something we like intentionally want to avoid yeah and 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 um personally I don't know if we've seen a lot of like large adoption outside of like AI so like Lang chain had a lot of adoption there's a couple other things that that shi since then um but it's like one thing that I was tasked on back in 2019 at GitHub was like top 100 projects on GitHub so how do you dictate that and like we figured out the metrics uh really came down like issue authors like who outside of the view core team or making issues how is that um but at the time view was like 90,000 Stars so like automatically it was already top 10 or top three 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 um as like a cool thing to like solve problems quickly yeah um I would say high level decision making at this point is uh we are definitely a lot moving a lot slower compared to say when we just got started in a way it's also partly intentional because we um during the V2 to V3 transition we made a lot of decisions and those little decisions kind of add together and compound into relatively High migration costs for users and I feel like the The View Community was kind of tired of the turn during this transition period and want to we we intentionally want to give them a longer period of stability uh so a lot of the we're intentionally avoiding this kind of like big like paradigm shift or like this is the new way of doing things kind of situation uh focusing on small incremental internal like improvements that really doesn't affect the end user experience that much um yeah so we are currently in that stage like post view3 let the ecosystem heal and we're focusing on just like quality of life improvements here and there uh like a lot of things we did like we reroll the passer we reroll the reactivity engine which uh don't really change the way things work but it just make it faster leaner more efficient yeah um so we're basically using the time to do this kind of things which is good because we can uh just focus more on the purely technical improvements less about just decision making and like getting buying from stakeholders and stuff like that um 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 uh especially major new features we typically would go through this sort of RFC prototype release as an experimental feature let it simmer for a while and then when we feel there's enough real feedback we stabilize it like the latest example is probably the Define model macro in 3.4 um that took like that was experimental for maybe six months um and and interestingly because of you know how big the scope the framework has already become almost every new feature kind of have all these cross cutting concerns with all the previously existing features so uh adding a new feature has definitely also becoming more difficult um and time consuming so basically we're just trying to be extra careful with this kind of stuff yeah and that's I I mean that's kind of what you get in like maturity in what what the framework is today like we see that with like ribon rails uh they've actually shipped a lot of really cutting edge stuff in the last couple years but U for a long time it felt like oh rails 4 or maybe five 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 um actually I think a lot of the Frameworks that I I've used in the past have got to that level at this point um but I want to take a step back to V too as well so like you started with viev server yeah uh but now it's called v y um so what was that decision process of like this is different MH yeah so um after I um got the initial prototype working uh a few months later I came back to the Prototype again I was like this time I'm going to I'm going to try to crack the hot module replacement thing um I think I was again I was working on V3 and one day I was just trying to trying to get away from the existing problems and uh then I started thinking about hot module replacement and suddenly something clicked I was like oh maybe this is how I can make that prototype actually do hot module replacement so I uh picked it up again hacked until like 4:00 a.m. and I got it working so I was super excited uh 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 yeah um so super excited and decided to push this idea further so starting from that Pro time I actually like spent I think at least like six to seven months straight just working on v i kind of paus view development during that period that was just uh just intense you know work on 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.0 RC I was pretty happy with it um but during that process I started to research on the existing Solutions so there were a few other ones actually also doing similar things so there was uh at webdev server uh it's from the web components Community uh then there is snow pack and then was uh wmr which is from the the preact team Jason Miller was the the author and um more or less I think um V was the first one to actually get proper hot module replacement working over native esm uh but that it was obvious that the idea of loading you know doing B uh no bundle development over native VSM was becoming a thing um so I realized like I was was building it only for View and it was was working well for view but I realized okay like this doesn't really only apply to view it's you know other people are building as generic multip you know general purpose Dev servers um so I realized okay like this idea and the hot module replacement in viev server also wasn't view specific initially it was but I managed to make it basically framework agnostic so I was like okay like this should just be framework agnostic um view should just be a plug-in to this new thing but in order to cleanly extract the plug-in architecture I had to do a rewrite pretty much yeah like the in the 1.0 Branch View logic was basically hardcoded into the whole thing I had to like split it out and come up with a proper plugging system uh which I eventually decided I'm not going to release 1.0 I just like started a rewrite um so the rewrite uh took inspiration from wmr so wmr had had this interesting idea of essentially uh creating something called a rollup plug-in container that is not rollup but is able to run rollup plugins so that's something we still using V now uh so that that idea came from the why not rollup is it rollup too much to bring in to the I guess because rollup is a no JS build tool so when you are um when you're running a Dev server uh there's no way to invoke rollup plugins without actually doing a bundle with rollup but because we're loading things over native ASM there's no bundling to be done right but we want to be able to use the same plug-in format and you know reuse the rollup pluging ecosystem and also because we're using rollup for production builds so we want this like same plugin 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 rollup pretty much so that idea came directly from wmr so shout out to Jason Miller yeah um and um so the rewrite was pretty successful and uh which allowed us to have a view plugging a react plugging and we can also support react hot module replacement um so from there I think we started to got decent traction and another interesting thing that really decided the the M later was um because I wanted to be able to build C Serv side rendered apps with v right and um so we realized when you build service I rendered apps there's actually an interesting requirement where you need to load you need to run your application in the browser you also need to run your application on the nodejs 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 kind of want to have this sort of um hot module placement on the server side uh because previously we've done like manual webpack setups for view with service side rendering and the thing we did is like you basically have to rebuild the whole SSR bundle you're building two bundles and you're doing full bundle rebuilds on the server side on every change and that was inefficient um so we were looking at ways to do that and at that time Rich Harris was working on spell kit and they were initially using sow pack and uh basically we were running into the same problem at the same time so rich came up with an idea that um that we still kind of using V today we are coming up with new apis but like it's still the current way of doing things is um you would have a custom transform that takes user modules and essentially transform into something you can become virtual modules that you store in memory and you maintain a virtual module tree and you like replace the modules that's that's updated uh and you are able to run the whole thing in OJs um we call it the the SSR load module API so um we saw that PR and felt like it's a good good idea so uh we essentially replicated the API in v um so yeah so the SSR little module whole idea came from Rich haris which he implemented first for spell kits in snow pack um but at the later St agage um this API got got baked into V and we had you know examples how to do very lean setups for react and view SSR inite and with those examples people realize okay this is not too far from actually a meta framework um so that kind of served as the um the starting example for people to build their own meta framework on top of v and that became a thing so more and more people started to use V to build their own SSR meta Frameworks and and uh later on I think the U when the snow pack team decided they want to Pivot into building a framework Astro yeah um they decided they don't want to maintain their own build tool anymore and uh they moved over from snow pack to V essentially so as a result valkit also moved from snow pack to vit and um and now we see more and more other Frameworks like uh quick uh solid um 10 stack um so yeah pretty much if you see a a new uh meta framework that's uh that involves transforming some files into JavaScript and they need to do service ey rendering there's a good chance it's using V nowadays yeah which is like kind of mind-blowing I think remix was like the most recent like yeah adding to uh the the vit um yeah folks who using V and they're they're they're build tooling Dev servers which was amazing to see cuz like they there like still other options when it comes to like these Solutions and like even snow pack being one of them well snow Pack's not around anymore but uh it's like Fred's actually was on this podcast and we talked about things like snow pack and like making decisions to build Astro and like what they were seeing at the time and why they made those decisions but full circle them using V after like really kind of kicking the tires and like building that originally um like how does it field of 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 V so like they're they're very different like yeah projects now that V and view so like how does that like the the the team that works on V today um same thing with like sponsorship and and making decisions like are you also the bdfl for vit as well um I think I'm definitely less of a bdfl in V compared to view uh my like so I still review almost every single line of code that goes into view nowadays but on the V side I'm much more hands off uh so the the V team is much more in a way like uh the the madeup I think on The View side um the ecosystem is pretty big nowadays so we have not just view core then we have the view router our state management Library Pia we have our documentation Dev tools uh language tools IDE support right uh many of these pieces outside of UK cor are also kind of delegated to team members um 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 obviously we try to coordinate big changes together or um but on viewe um I'm still mainly the one who's deciding the direction I review the PO requests um so usually we have team members who can merge relatively trival or small changes but if it's something significant I definitely still review it um but on the V side U we've seen in the past two years you know team members just uh individually being able to resolve relatively significant changes push you know big decisions and um make very significant improvements to Performance uh pushed minor releases is uh sometimes even without me directly involved so and I think that's a good thing 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 um and I think that's necessary because you know my bandwidth is kind of stretched in all directions so I do want to see V continue to succeed and to to see that happen we need a team that is able to just move uh you know without me having to be on everything um so that's also kind of intentional like I was uh the view team grew very very organically most time people are longtime contributors who like just stepped into the row very naturally uh the V side is a 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 you're doing great you should join the team you should do this uh I want to give you more responsibil I want to give you more you know autonomous autonomy to to do the things you want to do to to make the changes you want to CH uh see happening so we have this uh on our YouTube we have this uh YouTube shorts uh called looks good to me and these are like usually storytelling of interesting contributions within like the community that like were inflection points uh so I actually want to like ask you the question of like what were the first signals that you saw like hey you should join the V team like what were those contributions yeah so um it's interesting yeah there are definitely very obvious signals when I when I see people making high quality Pro requests a few times in a row uh 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 um it's just like the maybe the way they think the kind of clicks with you um so for example we have a current Court team member on view side where um he's super young but like the PO requests 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 M 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 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 um that's important right uh and I I think it's um if you're a maintainer you will like different maintainers have different style of working on their projects right like we would have different code preferences we have different design philosophies on how the project should work uh so usually a good contributor understands your your preference your philosophy very in instinctively intuitively uh I think that alignment is very key right some people can be really technically brilliant but maybe they just disagree on almost everything with you and they wouldn't become good contributors or team members it's yeah right so it's like technical skill is not really the only Factor here yeah yeah I I I did a tweet about how we we brought on some interns last year and the way we we had folks build the same project very simple and there's a tutorial you follow the tutorial or you can go off the tutorial whatever but what we really reviewed was the pr Communications style cuz like we want to be a we actually brought on two folks in India yeah um but communication is very Paramount cuz 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 going to work in the evening with me whatever but communication is very very key and you you mentioned this thing about this like like I mentioned like in passing like they have the sauce or they have like that sort of they get the the ethos of the project and maintainer um we actually had this metric that we're shipping in a couple weeks called uh confidence M um so like we've we've gone through a bunch of data and identify like if folks can make that repeat contribution like they get a tick into the confidence bucket right and um like those are the signals of like quality and confidence you can actually start identifying these Trends yeah uh and what's interesting you could also see this contributions historically where they had like the confidence in other places and I'd mentioned Anthony as as one of these examples of yeah who was early days in the the V uh core team contributing but his his confidence level which you like confidence verbally saying it out loud we could say like make this differently 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 done here and like yeah I think yeah I think one important uh sign of a good contributor is uh someone who's willing to understand the project M uh 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 needs and then tunee 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 I know this is someone else's project I'm going to first look how look at how they do it yeah then I'm going to 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 in a way that is you know aligns well with what the project is already doing yeah um not all contributors are aware of that or are willing to do that right because it also takes effort so what what do you do because View's got a lot V has got a lot of interest and attention so like what do you do when folks just don't really get it but they are technical like they can write code 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 yeah so I like we do try to write down as much as we can to like guide people basically there's a PO request uh 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 uh if you're adding some feature you need to like clearly describe what problem you're solving in the first place um because like over time like I've been reviewing so many poor requests a lot of them very typical ones are people just come in 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 this solves my issue I'm going to just drop it here and uh in a way it's it's definitely better than not making any contribution at all right but at the same time it's kind of difficult for us to decide what to do with this kind of PRS because um we can't just merge it as is because we don't feel like we understand well enough yeah uh but at the same time communicating with someone like that is can be sometimes difficult because they feel like I've already done you a fa faor I've worked on something I don't want to spend more time on this explaining it um yeah it's it's it's a catch 22 cuz like everyone benefits if they explain it up front and if they have like they can site an example like oh I saw this in my project or here's like reproducible steps or here's a link to a stack Blitz um but I I think so I I have a lot of smaller projects that I like nothing at the level like a viewer V but I'll get contributions like that and I I I feel like I'm I Mentor at a boot camp like I love like walking alongside people and like learning together jumping on a call like that's I've got the bandwidth for that I don't think everyone else has the bandwidth um so like I'll jump on a call or jump in a PR and 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 yeah like uh if say I think in the early days of view like I definitely had much more bandwidth and patience to just like pry out like what let 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 uh because we have issues that's like that too yeah like people report bugs then we have to uh kind of go back and forth digging out the information asynchronously yeah um and doing that with you know we get anywhere between like five to 10 issues plus PRS every single day uh you know doing that repeatedly can burn you out really fast um 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 pro pro request templates trying to guide people through the thought process that's needed in landing a change in something like view which is um it's it's used by too many people so every change that goes in kind of has a lot of unseen consequences is like some seemingly harmless changes we've landed end up being big regressions that we have to like do Hot patches on so over time we kind of we just like become naturally very very cautious about every change that we we eventually ship so um and that takes time to explain to people like so um firsttime contributors on 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 yeah yeah it's almost like there's uh and I tot had the idea uh when I was at GitHub like structured on boarding 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 how do you like on this on the CLI or the command line walk through contributing to projects but also learning the EOS and there's a couple other projects which uh if folks are watching this like link them in the comments cuz I'm actually really intrigued if there like anybody solved this um for like clone the repo start a thing and before you contribute go do like this little like right small not even test it's like side side quest of like oh yeah I can learn why we made decisions here and like the V view ecosystem but um we only have a few minutes but I wanted to actually um like set the stage for like where is V today um and I guess I'll ask the question where I maybe I I don't know if this obvious but like should V be a company at this point because it's got so many hands and so many different pies uh and depended on I think there's a possibility for that um especially when we think about the long term like when vit was um I think one of the things people have still have reservations about V is that we do rely on like different under underlying tools like you spend a rollup which we don't really control there are some things we want to do for example we want better code split in in yes build we want faster builds and rollup but it's very difficult for that to happen like unless we kind of take over the development which isn't really practical yeah on the other hand so um we're thinking about like the fundamental improvements to V if we want to because we see it slowly becoming sort of the shared infrastructure layer yeah for high level Frameworks um we also see a lot lot of single page applications just being directly built with v right and um so V'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 um that does require much heavier investment like say you know rewriting something like a bundler is non tral work um so which will require you know significant resources put into it to to find the right people to work on those problems so um so I'm trying to you know put together you know the putting the dots 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 a that's actually kind of the bigger problem I want to tackle is on The View side it it's more like an independent lifestyle business thing uh where we are doing pretty well based on the sponsorships that we get we have a lot of small businesses in the view ecosystem uh like uh educational Partners we have like um end of life support Partners where they are kicking back Revenue to the project because they are built on you know their business is is Rel directly related to us so VI is kind of a pretty nice little ecosystem of its own that's already sustainable and I think that's nice but at the same time it's not something that uh can big enough to support the kind of thing we want to build for the entire web ecosystem as a whole yeah uh so on that front I think V has strong potential in becoming something in becoming something even bigger and that may require us to put into know put into it more some more significant financial incentives to get the right people to work on it so that's something we're exploring at the moment um cool yeah exciting I mean I I I'm bullish on V uh Ive definitely hitch my wagget on that and it's definitely my go-to for building like my own micro Frameworks to pick and choose like how how I want to develop moving forward um so exciting to to see the progression and like what comes out of this well stay tuned yeah and and stay Saucy everyone [Music]

Channel: OpenSauced

Views: 32,358

Keywords: opensource, inclusion, startup, remote, flexible, diversity, devrel, developer relations, developer advocate, code, tech, fullstack, DevOps, ops, dataops, frontend, backend, hack, hackathon, cloud, linux, open source, bdougie, opensauced, finding open source projects, getting noticed on github, github, git

Id: 4_uYqae42uc

Length: 38min 31sec (2311 seconds)

Published: Thu May 30 2024