VITE: The Documentary

- There you are. Okay, we're good? - How you feeling? Cool. - I need to take a selfie with you guys. - These documentaries are great. - I've gotta work out what I can say without getting fired 'cause - For me that question of where this started, huh goes back even a little bit further. I mean, to be fair, no one was really taking JavaScript too seriously until probably the mid two thousands. JavaScript has kind of always been seen as a little bit flawed. - It was a very different world back then for JavaScript developers. We were starting to come to terms with the fact that we were shipping way too much JavaScript to the client. - Reality was we wanted to minify our code at first. We wanted to be able to take different packages and stick them together, right? And there was a lot of early rough tooling and we would be building chains out of tools like Grunt or Gulp where we'd try and stitch together our Javascript - JavaScript developers, mostly writing UI code, stringing together like a build pipeline. It was just like a spaghetti mess. - More and more you build and you just kind of dump it on the browser and you don't think of the browser as this place of innovation. - This is just a natural evolution of purely the size and complexity of our apps growing into single page apps. Honestly, it was a mess and it was around that period that Webpack showed up. - There was a bunler called Webpack. - Webpack was this idea of let's just pipe everything through JavaScript. What if HTML images and CSS JavaScript runs everything. JavaScript is the build tool and everything assumes bundling. - Even though today like bundling size is important, like you had it way more back then. So bundling was like a very big deal - At that time. it's like every meta-framework was built on top of Webpack. - Webpack was really the only player at that time. - It was the best tool of this era. - Every year like application got more complex, - Things got bigger and bigger and - Webpack has very slow startup. If you have a very beefy app, it's fast enough in the early days when you're starting to build something out. But as things start to grow, - The projects are getting so large that processing all of this data in JavaScript is not the fastest, right? - Every time you hit save, you had to wait and there's all this bundling work that you didn't actually need. It was a performance improvement that turned into this like requirement for JavaScript. Every time you had save bundle bundle bundle - There were build times of five minutes or more and Dev server restarts long enough to go to a coffee machine and have a chat. You go get a coffee, come back and you know you're still waiting for it to start up. - I don't think I'm being rude by saying that people did not love Webpack. People have never loved Webpack. It's a complicated machine. People are starting to feel that you needed a PhD to configure your tooling set up - Webpack is still quite a mess. It's good technology, but it's quite a mess. It's the biggest choose your own adventure of all time. - People were starting to realize that they needed another layer to bring all the pieces together. The natural next step was to try and figure out, you know, is there a different path forward here? - I think at that point people were ready for something else. - I created VueJS back in 2014. The official Vue CLI was built on top of Webpack. Webpack was attractive because it provided hot module replacement. I think the biggest issue is during development, the hot module replacement performance deteriorates. As your project gets bigger, as users start throwing more and more demanding workload at it, people start to run into build performance and scaling issues. That is probably what I was also most frustrated with in my own projects because I noticed that it was slow to scaffold a project. It was slow to start the project. It was also slow to hot update. I was really thinking why should view developers accept this level of developer experience? To be honest, my whole motivation of looking into Build Tools is all about improving the developer experience of Vue users. So the first idea I had was thinking, is it possible to have a local dev server that doesn't really bundle things with Native ES modules? It means now browsers understand modules natively. So why do we even bundle anymore? Why don't we just send the modules directly to the browser? I wanted that to work for Vue components. The prototype was called Vue Dev Server. This has potential but I just don't know how to solve it just yet. So I kept thinking about it. I think in April, 2020 it just suddenly clicked like, wait, if I do this that maybe hot module replacement could just work over native ESM and usually when an idea like that hits you, you just gotta try it out on the spot. So I decided to go back to the office and start hacking it. It almost worked, so I kept working on it until midnight. I finally got the prototype working. It was like almost like 2am to 3am It was blazing fast. Obviously the first prototype was not complete, but it showed that it was possible. I realized, okay, like now even if I have a huge Vue project, I can hit save and I know things will update in a hundred milliseconds instead of like five seconds and that's like 50 x improvement. When I first got that prototype working, it was just, we didn't have anything like this before and I was super excited. I came up with the name Vite right after the prototype and I published the first version of it maybe in a day or two after I, I made that tweet - At the time that Evan created Vite, he sent a tweet and of course I saw it. I checked the repo and it okay, it's very cool, but because it's a proof of concept, it's barely functional. - When I put it out, it was obviously still in prototype status. I - Vaguely remember the first time Vite came up, - I think it came out about the same time as the first version of Snowpack. It was very much centered on people building Vue apps, which is not me. - I have to admit the the first stage of Vite was something that I kind of brushed off. - Why are we building yet another bundler? - This is a little rough, a little lower powered, it's early days. I sort of wrote it off as a as a curiosity. - During the early stages of Vite there was also Snowpack. - Snowpack and Vite really started to take off around the same time. - Interestingly, we are essentially coming from two different directions. - I mean at a highest level, Evan was coming in to solve problems that Vue developers were having. He was trying to make a better tool for Vue developers and I was coming in, it was Snowpack trying to essentially kill Webpack, trying to get rid of bundling. - We essentially ended up in the same place. So we had like a lot of overlapping features that basically made us competitors - In 2020. I found myself with a lot time and a lot of frustration about Webpack, so I set out to find tools that were better and faster and helped me build applications in a nicer way and the Svelte syntax really clicked with me. The rollup setup of Svelte had the same disadvantages of slow turnaround time for development. So I got interested in how I could improve that. I experimented with Vite. The first version of Vite was not framework agnostic. It was built for Vue. Me and Rixo we spent a few nights hacking on it and we had to hack around some limitations in Vite to get the information we needed to be able to compile Svelte components and have hot module reloading working. That worked surprisingly well for me. Well enough that the Svelte community started to take a liking. I think I got like 300 stars on GitHub in a couple of weeks - I was working on Vite iterating on the design and trying to essentially make it something that's actually production usable - At that time Vite was like zero point something. Maybe it's the time for me to give a try. - I was starting to get really interested in like, oh, let's see how I can also contribute to, to Vite Anthony Fu was on the other side. That was my first encounter with him, I was starting to get hooked up again into open source - Up to the 1.0 stage Vite was largely Vue specific. The next step was really to think about how can I make this more generic and how can I maybe have a plugin system. There were also a few other competing solutions that's popping up. One of them is called WMR and I noticed that it actually supported Rollup plugins. It occurred to me that it's possible to simulate an environment where Rollup plugins can run even when you are running a dev server with unbundled native ES modules and if we do that, it means we can create a Vue plugin that runs the same way during development and production and it also means we can support other frameworks by supporting their Rollup plugins. We decided to use the same Rollup plugin interface for both development and production and also at the same time make Vite framework agnostic. - One of the things that Evan was doing was trying to make it framework agnostic. This was a very important arc in the story of between Vite one and Vite two. - I'd say the other big innovation was adopting that Rollup API. - The result was that you had all of the fancy plugins, all the transformations, all of the bundle splitting and optimizations and route handling that you would expect. All of that being handled was game changing. - When I made that decision, we were already in 1.0 RC, but I felt this change of direction is just so worth it, so I decided to just scratch the 1.0 release plan and started a complete rewrite, which eventually became Vite 2.0. - Evan, myself, Jason Miller from the Preact team all were realizing that there was this new kind of tool that wasn't just an installer but a full dev experience and we all started to put it together in different ways. It kind of set off this race to try to get there where we were trying to build features that Vite had Vite was trying to build Snowpack into Vite, we do a change log, they do a change log. There's only enough room for one of us in this town. For all the competition of it. We both had the sense that there was so much to explore, it was just a totally new model and nothing existed besides our couple of tools to, to kind of build that - Snowpack and Vite were like the two main contenders in the area. Snowpack was at that point like even bigger than than Vite - I was actually a deep Snowpack user from 2019 to 2020. - There was this moment around Christmas holidays like 2020, 2021 All of a sudden Evan starts working on like Vite 2.0. - That was around the end of 2020. - There's this moment where we were like, I don't know, like maybe Evan's not gonna be working on Vite anymore. He is got Vue he's got other stuff. Maybe we've won already like maybe Evan's given up and then all of a sudden I just see the commits start to ramp up. It's a holidays I'm, I'm trying to enjoy some time with my family. I'm looking at git I'm like, oh, Evan just shipped a new feature. - Evan was like laser focused on delivering Vite 2.0 - People talk about work life balance and part of me if I like look at Evan from the outside, I'm like, does he just work? Does he just like hack on stuff all the time? I worked really hard - And then it keeps going into January. He keeps committing, he keeps committing. There was this moment where what he was working on was just so clear like oh he is, he's cracked it. Like there was this real moment of like he is shipping a kind of full complete vision for the first time. He took all the pieces together and aligned them in a way that really cohesively told the story of what is this tool and why would you use it and that was Vite 2.0, - The Vite two release and that decision completely changed the story of this new generation of Build Tools Vite two had this like magic feeling. - We decided to try it. It was magically working very fast, it was just working. - One of the biggest reasons people like Vite is because we simplified a problem that was traditionally very complicated for beginners to tackle. That is setting up your dev server with hot reload, setting up the production build pipeline and making sure everything is working together nicely. Vite just made that work out of the box. Very similar to how services like Supabase make it super easy. Just spin up a database yourself. - Everything you'd normally want to have was already configured. You can just put Vite in and start coding without doing any configurations. - You install Vite, you put the Vite config, which is like three lines of code or something and it just worked. The next day I come and say like, - We are switching now, there's no conversation. Let's just, let's just do it. Vite is like not a fun weekend project anymore. It is serious business. That's when I started paying much more attention - What Evan was doing with Vite two, the new design and the architecture he choose was really, really clicking with people. - I think the early adoption largely came from the React crowd ironically - Vue and React. We are always fighting, we're fighting all the days that's part of fun. I would say - They were looking for a modern alternative to Create React App and Vite was precisely that. - I was within the first five people using it with React for sure. It was within 10 minutes of him tweeting it, I had installed it and tested it locally and gave feedback like, Hey, this works really cool. - It was lighter, it worked out of the box, fewer configurations and much faster in all aspects. - At that time we had a web-based IDE that's still around called StackBlitz. Our StackBlitz environment would boot instantly and it would take like sometimes minutes for the first, you know, Webpack dev server to actually boot up and there's, there's not a ton that we can do there and you know I'd heard of Vite, I knew Evan had made it and so I went to the docs and I just read through the introduction of what is Vite, why does it exist? We were like, this is it. You know, like it was hit me like that immediately. What Evan was doing with the way in which Vite was designed, it just, it encouraged the entire ecosystem to collaborate together and it was already happening. Okay, they've cracked it from our view, it was like it made a ton of sense to financially back the Vite team to ensure that they had all the resources to support et cetera, to continue investing in making sure that they could try and hang onto the dragon's tail of what was probably gonna be just explosive growth, which is exactly what happened. - I work on the Svelte team, we maintain this component framework and back in 2019 we had been maintaining an application framework to go with it called, called Sapper and we were starting to come to terms with the fact that it didn't really fulfill our vision for what an application framework should look like. The front end development landscape has changed quite substantially since we started building Sapper back in 2017 and we have an opportunity now to really think deeply about what a modern development workflow looks like. We were thinking about tackling the problem from another angle demo time. We have a couple of scripts here Svelte dev and Svelte build. That command is coming from this thing Svelte kit name might change but we like it for now. At the time these two new ideas Snowpack and Vite had kind of just come out. One thing you will notice we have a Snowpack config. That's because this project uses Snowpack and that's what I'm gonna show you. - Rich Harris talked about Sveltekit for the first time and Sweltekit was using Snowpack. - Rich was a huge believer in this technology and where we were going. He put his weight behind it. He'd even done a public announcement, we're going with Snowpack. I was like, this is our Webpack moment. It's inevitable. - Having a framework like Sveltekit really gave a lot of validity to that option. - Hi, I'm Dominik and I'm going to show you a sweet tool to develop Svelte applications with hot module reloading so fast you hardly notice them happening At that very same Svelte summit I made a video - SVite is a Vite plugin and a CLI to help you set it up really quickly and I'm going to show you how in a second, - Dominik Gopel showed a thing called SVite. - It's really simple. You simply type SVite - We're sort of saying Snowpack is the future and he was very convinced that that Vite was the future. - I'd like to thank all of you who've been working on Svelte Vite. Thank you very much. - Literally half an hour after my talk the Svelte maintainers made a competing framework basically that was kind of a bummer - Behind the scenes, you know we're working with the Snowpack team, we were facing this problem that as a new tool that invented its own way of doing things, a lot of stuff was gonna need to be reinvented - And then we didn't really hear it from them for a while the the Sveltekit team but I think internally they started hitting bugs. They, they'd run into these problems where it's new technology and right around that same time Vite 2.0 - Vite two came out and all of a sudden we were like, oh, oh I think this is better actually. The brilliant thing that Vite did when it came out was it said we're just gonna use Rollup for our production builds and so because of that, if you're using Vite, you instantly have access to this entire universe of Rollup plugins. That was how they were able to overcome this big hurdle that every new project faces, which is okay this thing exists but how do I use it without boiling the ocean first and so we very apologetically said to the Snowpack team, actually I think we have to break up with you. - It was definitely a humbling experience. It was this understanding that like, okay, hold on. We're not the only people in this game. - Dominik turned out to be right and we later went to him and said, we really love what you're doing here. - The Sveltekit team approached me and said, Hey, we've been experimenting with Vite and Sveltekit, - Can you come and be part of the team and help us build this thing? - What was SVite before became the official Vite plugin Svelte which is still maintained by me today. - That's how Dominik became a core member of the Svelte team and when Sveltekit was eventually released as a stable framework, it was a Vite plugin. That was a controversial decision at the time but it was a hundred percent the right one. - After that Sveltekit announcement came out, there was a world where we could have, put our heads down and built a great version of Snowpack. Maybe the fight would've gone on a little bit longer but if you can't beat 'em, why not join 'em? Instead of two projects trying to work on the same thing, how can we use this as a stepping stone and that was where Astro came from. - The Astro team they decided to join forces with the Vite community from one day to the other. we had a lot of contributors with the perfect skillset - At the start of 2021 after we just released Vite two, we hardly had any downloads but it quickly started growing as people started to hype about the speed of Vite - Sveltekit made the move over so now it's suddenly the Svelte communitiy. Solid Start. We moved all our base templates over to Vite. That was huge. Vue was already there. - I quickly realized I don't want me to become the bottleneck for the future development of Vite. I sent out a GitHub discussion thread - A threat to say we want to grow this project to be bigger. We want to form a team. - Anthony Fu, Underfin and me were the first team members now we had a team that was like maintaining daily the project and like things started to to move a lot of that work through the two point x era was about like bug fixes, polishing. It wasn't a very exhilarating experience to see all the usage grow - By the end of 2021 we quickly rose up to around half a million downloads a week. - There was like a lot of movement and a lot of adoption and it seemed like the story was working well but there was one big problem in the case of testing it was really, really hurting Vite adoption. - A lot of the pain from early adopters of Vite when they're moving from say Create React App to Vite is they had a lot of trouble getting Jest to work nicely with Vite - Vite is so new that existing testing frameworks actually not really compatible with it. - How do you test Vite applications that rely on Vite specific stuff? Turns out a lot of people encountered this problem. There was an issue in Vite repo - In one of the Vite team meetings we were discussing again about this. - I was half jokingly talking to the team. I was like look, we should have a unitest runner that's like Vite native. It should just like understand Vite configuration and use the exact same plugins. - I wrote the name "Vitest" in the meeting notes - You know Vite, Test and then that's a perfect combination Vitest. I was just asking like, who come out with this name? This name looks very cool. - He went to NPM and like took the package - And I was sending a message to the team chat to say I just secure this name in case we need it in the future. That's a very good name and I really like it. Wouldn't it be a waste if I don't use it? - Anthony said like, I think I will try. - Anthony is a madman. - He disappear for four hours. - The next day I think Anthony was like I have a prototype. - I was saying okay, I got a proof of concept working. I send this to the chat. - We said like okay, we will help. - We, we took a few months, worked very intensively and we created a private repo. - We are started to invite like some key people. - I joined, I think it was like one week maybe a few days actually when it was released and I said Sorry I'm new here Matias was like everyone's new here. This is not, this is, this is very prototypey. It does work but there's a lot to do. - We opened the project after two, three months I think - They essentially created a unitest runner from scratch that understands Vite configurations and will just work if you put it inside a Vite project. - The team continued to be able to scale up at the same time we were starting to get worried about like the sustainability of all these things. - With the growing download numbers and growing amount of users, the maintenance burden also grew. We did need to find a way to scale the bandwidth of the team. - I was chatting with Matias in Discord and I mean just really liked Matias - Eric Simons He said like, let's talk because Vite for us is starting to be in the critical path. - We want to be meaningfully involved in the Vite ecosystem and the success here is mutually symbiotic. I was like, what? You know, where are you working right now? Like what are you doing? You know, would you want, would you wanna do this full time? - He say like what do you think if you start working with us? That February I joined StackBlitz to work full-time on Vite - Team members started to land positions that allow them to spend paid hours on Vite - We have, Matias hired by StackBlitz We have Bjorn who is on Svelte and Astro - Anthony was already working full-time at NuxtLabs. - My work on Vue, my work on Vite is all part of my job. A lot of companies supporting us by putting their employees into this framework, - It kind of naturally solved itself. We now have this team set up where our team members are properly compensated for the work they are contributing to Vite , In general, I'm really happy that the current Vite team setup is able to sustain itself. In 2022 It got even crazier. I think we grew about like 5x in 2022 so we reached like 2.5 million by the end of 2022. We're seeing even more meta frameworks adopting Vite like Nuxt3 three was released qwik - Laravel, Sveltekit, Storybook, SolidStart, Marco run - Shopify was starting to build out a framework called Hydrogen and the hydrogen team was all in on Vite - One after the other framework started adopting Vite - It went from it's often like Vue Land to it is literally the default solution for everything overnight like it was. It was just like that - React, you know still very much had that blessed Create React App and it was clearly showing its age. By that time period - A lot of the things that existed in Create React App were woefully out of date. One of my first videos on my channel was bashing Create React App Stick around if you wanna figure out why Create React App is bad, Vite was the right spiritual successor to what existed in Create React App so I made a PR swapping it because I was so heartbroken by more and more people being sent down this incorrect path. - Theo Browne or t3.gg, you might know him as stirred up actually a quite a big controversy. - It went very viral. Dan wrote a classic Dan Abramov essay in the comments. - It was an interesting discussion to have because Vite had so successfully changed the baseline in such a short time that like it was kind of the obvious choice. - One of the first discussions that I had with Eric after I joined the StackBlitz like he, he has approached me and say like what do you think if we do a Vite conference? - Let's just do a conference putting the spotlight on Vite because there's something really special happening here. - We're starting to organize like the first edition of what will be ViteConf. - Matias told me that they're gonna do a ViteConf. I was like great. - He just went to each maintainer and was like, Hey we're gonna like do a conference, would you be down to give a talk? - Everybody was saying yeah, yeah, yeah like let's do it. I don't think I've ever seen a a more, you know, comprehensive stacked list of folks. - When he showed me the speaker list, I was actually pretty amazed 'cause it had the tooling framework, authors of Sveltekit, SolidStart, Storybook, pretty much every tool that leveraged Vite in some way sent someone to speak at the conference. It's very rare for you to see people coming from different competing frameworks coming to talk together at the same conference on a common theme. I think that's, that's an achievement right and that's something I've never been able to do with Vue is around that moment. I start to think anything that Vite does now has noticeable impact on the development experience of a large chunk of the web developer community and I started to feel a bigger responsibility in making sure the web ecosystem stays productive. I didn't realize at a later stage we would take on something even bigger - And it was at the end a very important milestone to showcase how wide the ecosystem was. The project was scaling up well, usage was ramping up and the way that we were doing releases before pressing that button was really scary because we, we didn't know like if we could break many other tools in the ecosystem - Initially we'll talk to the maintainer of each meta-framework to say this is a change we're going to do and could you check if this change would affect your framework. - It was hard work of like coordination that wasn't going to scale up. We started to discuss what were our options and Dominik G, he appeared here in the the story of Vite - I started building a tool to test changes between Vite and Vite plugin Svelte to ensure that updates to Vite didn't break Vite plugin Svelte. The Vite team they said, Hey Dominik, can you run this future Vite built through your tool to tell us we didn't f*** up? Sorry, let's repeat that. Can you run this tool through your script to tell us we don't introduce a new bug? This kind of showed that there was a use case for this tool, like this tool was used to validate Vite releases before they hit users. - We know that our big players are like Sveltekit, Vue and also Nuxt a few meta-frameworks we know - We are not only going to test our own CI, we are going to test the CI of all the main downstream projects. Now we have like an automatic setup, we won't release until all the downstream project CIs were green. It completely changed. It was like day and night how we released. - You can guarantee every change has a minimal impact - After a few iterations we came up with what is called Vite ecosystem CI today. this tool is basically what I came to the Vite team to maintain - When we release now it was like very smooth and like very unstressful event because like we knew that it will pass for everybody even if it took us more time doesn't matter but when we release like almost everybody upgrade with almost all frameworks now using Vite and Vite looking at that point already we were at half the NPM downloads of Webpack. That means that in a year Vite will surpass Webpack. The React ecosystem was the only one where we didn't have that strong foot there. - I think right when I joined Remix I had heard of Vite but it wasn't the obvious option at the time - In Remix one of the issues that people were raising with us was performance, which was surprising to us given we were built on top of ES Build known for being fast. It was fast is fast, - More things started piling on. We started having really slow runtimes because we're rebuilding the entire app every time you change something but the compiler was really my core responsibility so I was really feeling the pain of it. - Vite definitely was picking up speed at that time people in the Remix community had been asking for Vite support quite a lot and it was getting louder every day. It felt like it was obvious to us that we are just hitting the same problems that Vite trying to solve - And so we once again like we're starting to ask the question of should we use Vite so I brought it up again and it was right around the time that Mark joined the team. Mark and I decided to just plow ahead and just make a prototype 'cause we felt really strongly about it and so we made like a GitHub repo just on my GitHub account, not even on Remix's. We just started pumping commits into there and just trying to get things to work. - When the Remix team joined, the ecosystem channel, every other framework author you had like people from Sveltekit, Astro and they were all helping them. - It actually worked pretty quickly like way faster than we thought and so we came out with a much simpler compiler that's much more powerful and much more pluggable. - There is like a tweet from Mark saying like we are just collaborating and there is no sense of competition. That is a moment like we, we all like felt very proud of what together we have been building - This trend, kept growing all the way into 2023 and we start seeing more serious adoptions like Angular tools like Storybook, adding first class Vite support testing tools like Playwright, using Vite for their component testing features. Cypress. We're quickly seeing not just meta-frameworks but also these supporting tools in the front end ecosystem realizing that Vite is this new force to be reckoned with. If you're using any modern Javascript framework that's not NextJS you're probably using Vite. - When we started supporting Vite, it was definitely before it was mainstream. It was, it was before everybody's using it for React and all these other things. Everybody lives in their own little like silo of the ecosystem. You talk to anybody, they're basically like, yeah, Vite is like the default. Any new project, any new technology was kind of supporting Vite. Every new framework, which there are many of was Vite, like there was no more like framework specific thing. It was just like one of those things like it had just happened. We were all kind of maybe coming to the same realization that Vite was the default everywhere effectively - Evan and and the entire team wanted it to be this open source tool that was simple to use, that was fast, that was secure and it just so happened that those choices made it really great for the frontier AI labs to have their models be trained on and be extremely good at. In October we launched Bold think like chatGPT but you know for building apps and websites and that just exploded all of the, the projects being created on Bolt effectively, they're all Vite projects. Vite's downloads, They were already exponential. They've gone even more. It's like an unstoppable force. - Today we have more than 14 million weekly downloads on NPM. I realize that if Vite is becoming this shared infrastructure, there is this opportunity to also improve everything that's underneath it. The Javascript ecosystem deserves a unified tool chain. Why can't we start a company, build a team and build a unified tool chain from the bottom up? That idea just never went away. JavaScript and TypeScript is now literally the largest language used for application development in the world. The JavaScript ecosystem has historically always been very fragmented and also JavaScript developers, especially library authors and framework authors are very strongly opinionated people. That's why they created their own frameworks after all Somehow Vite has essentially made all these people agree, this is the foundation we should build on top of this is the never before seeing consensus that I was talking about. We want to use this momentum to push for something that's more fundamental for the JavaScript ecosystem. We are looking at our own dependencies and realize we still rely on ES build and Rollup these third party dependencies and we don't really have control over them. I think that was when we realized, okay, we probably need to seriously think about building an underlying support layer to cater to the specific needs of Vite itself. We are very clear from day one that our goal is to build this unified tool chain for JavaScript to make JavaScript developers more productive than ever. We want to make it easier for people to not only create but also maintain these apps for the long run. - The universe tends to reward people that do things for the right reasons. - A lot of what makes the tool popular and widely used, it's not just a battle of who built the best thing. So much of it is cultural. - Evan is someone who I've always really looked up to as an open source maintainer. - This is a story of collaboration like of so many different communities getting together to to build this shared base. - People describe it as the United Nations of, of JavaScript. - The destiny of this era is, is set. I'm super happy for them and I think they should take over the world. Sounds good to me.