Noel Minchow: Hello. Welcome to PodRocket. This is Noel. I am here with Patak who is a Vite core team member. How's it going? Patak: Thank you for the invite. Happy to be here. Noel Minchow: Of course, we're excited to talk about build tooling and stuff. Vite, I feel like, has been really on the rise. People are excited to talk about it and stuff. So we are super, super stoked to have you here. Noel Minchow: Yeah. I guess just to get rolling tell us a little bit about who you are, how you found yourself working on Vite and in this ecosystem. Yeah. Just give us the intro. Patak: Nice. Yeah, I'm Matias Capeletto but people know me as Patak around in social media, or Discord, or GitHub. And it was around two years ago that in the previous company I was working on, we released a open source project that is called GridLayoutit.com, that is a grid generator. And for doing this project we started to use Vue 3, a lot of experimental stuff in Vue 3 that was not even released, things that they were discussing in RFCs for example. So to test it out we are starting to use it and also Vite and other projects in the ecosystem. And because of using these features that were on the edge, we were hitting bugs and there were a lot of opportunities to actually collaborate, no? Patak: So this was kind of like I wanted to get back to open source. So I started to get more involved in Vue projects like, for example, VueUse. We use it some composables in this app. And I already starting to work with Andrew Fu to upstream some of them. So they will be [inaudible 00:02:11] in VueUse. And then from there to other projects like VitePress and one thing took to another and I end up in Vite in the right moment. It was at this point when Evan You, that is a creator of Vue and actually also of Vite, and he's team lead in both projects now. And he was doing now a famous sprint for creating Vite 2. There was three months that he coded like crazy, like making features almost every day. Patak: And in this point I started to help with some issues, with some PRs. And was just at the time when we created the Discord. So when Evan needed to refocus his attention to Vue he created a team for Vite. And I was one of the initial team members there together with Anthony Fu, with Andrew Finn, and later other joints. And I started to get more and more involved. And now for, I think, it has been around two, three months, I joined StackBlitz. It's a company. I don't know if you heard about doing an online IDE. They are the people behind web containers that allow you to run node on the browser. So we were using them at Vite for our documentation and online starter. If you go, for example, to vite.new, you're going to get an online Vite instance to play with. So I joined them to work full time on Vite now. Vite is part of their critical paths so they are very interested in Vite progressing well. Noel Minchow: Nice, awesome. Awesome. Well yeah, thank you for the background. I'm curious about that initial handoff phase when Evan was super involved, and it was kind of his codebase, he'd been a monster. You said, "Getting all this code done." How did you get started and delve in? How did you immerse yourself in this codebase that was rapidly changing? Patak: Yeah. It happened naturally and slowly at the beginning. So at the beginning I was helping with issue reaction that I think is a really good way to get involved in open source project. So if you like a project goes to their issues tab in GitHub. And normally there are like 200, 300 issues. Right now we have 550, so if you like to help in Vite you're more than welcome. And a lot of these issues are actually problems that people didn't understand how to configure something properly. Or even some of them are not issues anymore. they have been solved. So cleaning up the issues is really good for the maintainer, is really helpful. And while you do that, you are getting to know more the project. You are starting to maybe see some things that you can start doing PRs. Patak: And so I starting to do that. And also, I'm really interested in the community side and the ecosystem side. So when Discord was created, I, together with other people in the community, starting to push for a healthy community to try to, I don't know, trying not to get a question that were an answer. Trying to help people around. And, I don't know, trying to make a good place for collaboration. So that also is a very good way to learn more because you get to delve in the documentation and learn about config problems. So from there it is natural that you start to go later to PR reviews and to try to help there and do your own PRs. And naturally you end up knowing more and more of the codebase. You get to do some deep dives, to do a few days just to understand a complete part. But I think it's doing PRs reviews, for example, it's a very good way to know a codebase, so it was like that, slowly and with the help of a lot of other contributors, Anthony Fu and other people that joined also the effort. And obviously Evan, it's not that he went away, he's quite involved in the project. Patak: And for example, one thing that we do is that we have every two weeks a team meeting where all the team members get together and we discuss about new features. And for example, Evan was quite good at actually giving us responsibilities and letting us form a team. For example, for fixes we can merge the PRs ourself. we have a rule of if two contributors will accept the PR then we can move forward. But for features, the idea is that we are only accepting new config options or new features in these team meetings where we can discuss between all of us. And Evan is also present there to guide, so that more or less. We slowly going more and more into the codebase. Noel Minchow: Nice. Yeah. I think you answered my next couple of questions there. And I was curious if it was intimidating trying to get some code out and putting those first few PRs up in front of Evan. And I guess how that went, when again, it had been this codebase you'd worked on for so long. But it sounds it was a pretty positive experience for you? Patak: Yeah. Yeah. I think, again, it helps a lot that with a project as big as Vite, and that now with... Actually when this happened it was not used as much as it is today. It really grow massively, almost 10x in users. So more and more is getting more challenging to, let's say, put changes out. But at the same time we have more collaborators. We have the ecosystem working with us. We have maintainers of other projects that are doing the PRs and also working on reviews. And we have a whole infrastructure that we can talk later about how we test things that wasn't there before. Patak: So I think that helps a lot, this idea for example, that normally we don't merge anything without two people looking at it. So it's really interesting. I have been learning so much from other contributors and collaborators during this time. Noel Minchow: Nice. Awesome. Yeah. Yeah. A point you brought up before too about triaging a project in and of itself is a lot of work, but also a good way to know a project. And I think that's probably something, especially on these projects, that have a lot of public visibility and an inherent uptick in users really quickly. I'd imagine there's a lot of open source contributors out there who have a project. And they're like, "Man, I'm spending a lot of cycles just triaging issues." So I guess it's just to say that I think that's very good advice to jump in. And even if you aren't super familiar with a project, go in and just start trying to clean up the long backlog of issues that people are making. Patak: Yeah. And I can put an example there. You don't have to be this guy that I will tell you about. He's now a Vite core team member. His name is Blu 00:10:26. And around one month and a half ago he actually saw a tweet about Adam that is the maintainer of Tailwind. So they were saying, we got to so 100 issues. And at that point in Vite there was 770 issues open. So he said, "I will try to do the same for Vite. And maybe not to so 100." But he has started that process. And I think he spend, I don't know, three hours per day in one month? But he got us now together with others that showing it also this is contentious now. You start doing this and other people will follow. So now the project is around 550. So it's amazing, 220 issues closed in this past month. So it's a lot better now. Noel Minchow: Yeah. Yeah. And because it can be a lot of work. Just that initial investigation work on issues, a lot of time, is a lot. It can be super intensive. Yeah, for sure. Cool. So yeah, you said that the project has grown like crazy. You said 10x growth in the past, year, few months? What does that look like? Patak: I think one year now. I was watching the graph. It's interesting to see the stats. And yeah, it is really interesting because it grow together with a huge ecosystem of projects that starting to adopt Vite. How it seems right now is in the future, probably most of the users of Vite will not use Vite directly. But they will consume it through some other projects. For example, SvelteKit is based on Vite. Nuxt now has released the RC, the first release candidate for V3. And the default is Vite, so if you go to other projects like Solid, for example. They are working on Solid [inaudible 00:12:41], that is an equivalent to SvelteKit. And it's also based on Vite. Marco is using Vite, Qwik is using Vite, and so on. Patak: So I think most people will use it in this way. And this is how the project was growing, also. SvelteKit at the beginning was based on a Snowpack, that we were one year ago, let's say, there were several tools that were like Vite. They were actually collaborating, even together, the maintainers know each other and they were exchanging ideas. And at that point was not clear which one was going to end up being adopted. But for example, like SvelteKit, was using Snowpack. And at one point it changed to vite. And so when that kind of thing happen, it's not like, I don't know, some extra user join. It's the whole Svelte community now is using this. And Vue, obviously, Evan You created Vite so it was normal that the Vue ecosystem was going to embrace Vite. Also a lot of Vue core team members are part of the effort. Noel Minchow: Yeah. Yeah. I want to talk about Vue and Vite's relationship maybe a little bit later on here. But yeah, first I'm curious, as you guys have seen this growth, I mean it makes sense that it's the tools that are really driving these numbers up. Do you think it's the case that most devs are not even really thinking about, or weren't really thinking about, their webpack config before that? It was just another part of the tool they pulled off the shelf. And it wasn't a huge consideration of theirs personally? Patak: I feel like most developers have fought a fight against these web configs. But because it's really takes a lot of work to configure each ecosystem, each framework. Actually, what happened is that they end up saying, "Look, we have to do something for our users. We cannot let every project do this themselves." So first you have, for example, Create React app. But at one point that was, let's say, it was difficult to maintain because it was a lot of work. And actually the React team pushed that to others. So for example, NextJS. If you see what NextJS is doing behind the scenes. There is a lot of webpack configuration. So most users will use Next. And that will give Webpack in a nice packaged way with good conventions. And you will have to maybe use some Webpack configuration, but, let's say, not for everything. Patak: And the same will go to Vue CLI, for example, that was like Vue, way to do the same. And maybe I think Sapper was from the Svelte site, that they were using Webpack there. So I think, again, a lot of Vue's efforts end up consuming Webpack in that way, let's say. And it's the same idea. Vite actually takes you a lot farther away because it's more high level. Evan You likes to say, "It was very good that Webpack was there to explore all the conventions because at the beginning it was not clear how people will use certain things, how we will start consume CSS and other tooling." Patak: But Vite, luckily, appeared at a time when a lot of these patterns were more, let's say, clear or establish. So with Vite it was able to say, "Okay, we are going to give you these patterns that we mostly agree on by default and out of the box is going to work." Again, Vite is part of a variety of tools that, for example, Parcel, I think you will also know that it was also pushing for this out of the box experience in a lot of ways. Noel Minchow: Yeah. Yeah. So that leads me to my next question next, or to my next question pretty cleanly in that, yeah, it makes sense to me. Having a build tool that's more opinionated is easier to configure. But does that also lead to a lot of these performance increases that are motivating these frameworks and these devs to switch to Vite? Patak: Yeah. Yeah. Maybe we can talk a little bit about what is Vite in case someone... Noel Minchow: Yeah. Yeah. Yeah. Bring us out a little bit. Make sure everyone's got to... yeah. Patak: We have now the benefit that maybe one year ago it was a lot more important. I think that now there is maybe a lot of the people that will listen to this podcast already hear about Vite or maybe even try it out. But so, Vite has two parts. If you consider the build parts, it's equivalent to Webpack in that sense. But internally it uses Rollup. So you can think of it as a opinionated Rollup setup. Normally if you will use client Rollup, it doesn't perform tons of optimizations apart from three shaking and other things that Rollup does very well. Rollup, what it has is a very nice plugin system, plugin API, so you can extend it. So normally what you will do in a Rollup project is that you will have to add a lot of plugins to do whatever you want. Patak: Do you want to import a JSON file, a jump file, and have it as an object, for example, and directly. Or import some CSS, or I don't know, perform some optimizations around that. You will have to add the plugins to do all that. You can consider Vite will actually create that pipeline for you and include a lot of useful plugins. For example, how to import workers and use it, or WASM, or to perform build optimizations. So it give you a really nice pre-configure setup that will create optimize app for production like you will have with Next.js or this kind of application. Patak: Normally by default it's more geared towards SPAs. But you can also configure it to work as MPAs. And this is in the Vue part. And normally there will not be a a big speed up. It will be comparable to Webpack. But if you take then the other side that is the dev server, the idea there is that during development right now all the modern browsers support ES modules, so they can hand understand the module graphic structure without needing to bundle everything. Bundling is an expensive project. You have to traverse all your module graph, and make a bundle, and send it to a browser. So in Vite, you can imagine the dev server starts right away without doing nothing. And that is a very good way to start fast. You don't have to do anything. You just have to start a server. Patak: And then the browser will request initial HTML. And from there Vite will grab that HTML, will give it to the browser with maybe the past of the imports, process it so the browser can keep requesting. The browser will traverse that HTML as normal. And when, for example, it would request some telescript file, that the browser doesn't understand obviously, Vite will, instead of Sass responding with the file... Imagine if you have a stratified system. It will actually transpile that file in an isolated node and, for example, [inaudible 00:21:43] the types using esbuild. The same, if you have jsx for React, or if the browser asks for a Vue file it will use the Vue compiler to compile it, and write something that the browser can understand and return it. Patak: So the browser will do all the work of requesting the files and keeping the module graph. And then on the Vite side, Vite will also keep this module graph by itself and record all the relationships. So later when there is a change it knows what files need to be, let's say, change it. So it can do really fast code module replacement and directly working at the module level. It's not having a custom structure of modules. Implementation is directly at the module level that it could work. And one important thing is that during development there is an emulation of this plugin system that Rollup has. So the same plugins that you use during build can be used during development. At least the one that makes sense. For example, a build optimization that only makes sense for production, it will not be done during dev. Patak: And some things, like Let's say maybe you don't minify because you want better source map, so something you don't need to do it. But it's the same system so later, for example, adding support for Vue, for example, you don't have to do two complete different plugins. You can work on a single one that will work in both sites. And what is interesting is Vite, it starts in dev mode. When you run Vite directly, this is like dev mode. It's not Rollup. For example, when you run Rollup it will build your application for production and you have to call up Rollup watch to enter development. In Vite the default is you are developing. And then when you're ready you can build your application. Noel Minchow: Yeah. Nice. Nice. Very cool. Yeah. So we talked a little bit about the Rollup modules that you might not be running dev mode. As a developer, do you have to configure which ones of those you typically would and wouldn't enable in dev? Or is that handled? Are there defaults that you'd usually have pulled in to inform that? Patak: You don't have to configure it? There is a way to say this plugin only if running in build or in dev. But normally the plugin authors, or if it is a full plugin the maintainers of Vite itself, will already take care. And the plugin knows if it is being called during build or doing dev and can do different things inside like the transform function, the [inaudible 00:24:54]. Noel Minchow: Oh cool. Patak: The plugins itself will know what to do. So this idea that it can be shared, it is normally you can share most of the code. And if it's something like loading [inaudible 00:25:09], for example, it will be totally share because it is the same thing that you have to do there. But if in some cases there are some branches that you have to say, "Okay, if I am in dev I will do this," mainly because of, for example, in dev we really care about in extremely fast because we want that fast feedback loop. That is one of the most important things in Vite, that you can play with, I don't know, imagine selecting a color and if you have auto save on in Vitest code you can select a color with a slider. And you can see the change in real time like if you will be using a dev tool. Patak: So for achieving that, maybe you have to take some shortcuts. And then when you go to production you don't care that much about time as generating the best bundle that you can. So this can be as performant as you can, because later they are going to be consumed by a lot of people. Noel Minchow: Yeah. Yeah. Performance optimization versus feedback optimization. Patak: Yeah. Yeah. And sometimes they are adults, so it's better that you can optimize separately for them. Noel Minchow: Nice. So is that layer, I guess to go back to my question, is that layer where you have Rollup components that are or are not running in dev mode. And you said, "There's configuration that can be baked in by the authors." Is that a Rollup feature or is that a Vite feature? Patak: You mean, plugins that are out the box supported by Vite? Noel Minchow: Yeah. No, I mean more that the differences in behavior between dev and production mode, like run this in dev versus only run it in production. Patak: That is a Vite feature because Rollup, it's only about bundling. It's a bundler, you know? Noel Minchow: Right, got you. Patak: So we only use Rollup during when you call Vite build, when you are building for production. Noel Minchow: Gotcha. Patak: But if you're running Vite regular, or Vite dev, that will not include any Rollup code at all. Noel Minchow: Gotcha. Gotcha. Patak: Yeah. So that distinction is already something that is parts of the config of Vite. Normally, one interesting thing there is that before Vite there were several projects that... You will have, project like Rollup that were the bundling for production. And you will have like the web-dev-server, for example. And Snowpack also, focus it a bit more on the dev side so you will have these dev servers. But then when you had to configure it for production, it was hard to make it work in the same way. So one of the keys of Vite's success was actually something that appear in the React ecosystem, this project called WMR, develop it there, created this idea of the universal plugin system that I told before, about you share same plugin pipeline, [inaudible 00:28:26] build. So this idea that you have the dev server but at the same time the build part is taking care of in with a lot of care also in Vite. It's not Vite give you the dev server and then when you have to go to build you need to configure a lot of things. Vite cares about both things. Noel Minchow: Gotcha. Nice. Nice. Very cool. What are the other tools that devs are reaching for that are other devs moving away from Webpack? That you guys view as competitors or peers that are in the same space? Patak: Yeah. So WMR, as I told before, this is from the React ecosystem and it's similar in a scope. I think, outside of React it didn't have a lot of usage. But there were a lot of very good ideas. And they are still working on it. Snowpack also, as I said, there were a lot of cross pollination there. A lot of very good discussion about how to do reloads. And Snowpack developers, the team, had a lot of experience also in how to handle dependencies, for example. And now that project in particular, the team that was doing it ended up creating Astro that maybe you heard about. So it's really interesting, using island architecture, and framework agnostic. If you want to do a blog, for example, or a website that has a lot of static content is a really good tool to reach. Patak: And they actually did that initially with Snowpack. But with time, they realized that there was a lot of, let's say, it will take a lot of effort to maintain Snowpack and Vite. And at that point Vite has taken off. So they decided to migrate from Snowpack to Vite. So Astro is using Vite now. And actually now Snowpack is no longer being maintained. And they are recommending their user to use Vite. And it's interesting because it's not everything that they learned there now, they are also, as part of developing Astro, they are hitting issues with Vite. And they are helping Vite. They are making PRs. So we are quite lucky that the Astro team is also helping push Vite forward. Patak: And then web-dev-server was another interesting project, also focusing a little bit more on the dev side. Parcel is also they release it, I think Parcel 2.5, last week maybe. Parcel is a really, really interesting project. There is a lot of innovation there. For example they have a new CSS person, Rust, that maybe Vite could use it at one point. It has this idea of, "We are not married with the internal tooling so if something else will came out later, maybe we can swap it, keeping the same API above." Patak: So Parcel is also really interesting. And a lot of interesting ideas from Vite came also from Parcel. So I think that was the map maybe one year ago. And now, mainly Snowpack and Vite were growing together. But with this move from the Astro team, now Vite took off. Well, Parcel also keeps growing. There is a lot of place, I think, to grow and keep innovating. Noel Minchow: Nice. Nice. That was kind of an interesting point you made there about you guys not being specifically tied to any of your internal tooling too closely. Do you view Vite as an API layer almost to orchestrate and control these lower level tools to make the dev and build process faster? Or is that not really how you think about it? Patak: I think it's a good way to view it. I feel like when you start using Vite you are a buying into a way to structure your app into the conventions, and into the way to configure it. Probably it's going to very difficult to change the plugin ecosystem because all the frameworks are done through plugins, for example. So there is a now a huge plugin ecosystem. And we are quite happy with the Rollup plugin API, so I don't think it's needed to be changed. But there is a lot of tools that, for example, esbuild is working extremely well for us. We use it to transpire during dev like Shay sx, or to ascribe the types, for example, for typescript. And then during build we are now by default using it to unify also both CSS. Patak: And so it's working extremely well for us, but maybe at one point the ecosystem will keep moving and end up, I don't know, adopting SWC that is done in Rust, or there's another project that's called Bond that is in [inaudible 00:34:30]. And I don't know what will happen in one year or two years. And if the ecosystem changes we could change esbuild by other tool without much problem. If you're not doing something really custom, because you can configure your esbuild also in Vite, if you you want. But normally you don't have to reach there. Patak: One interesting tool, for example, that we need to use right now is Babel. If you are in the Vue ecosystem or you are in the Svelte ecosystem, normally you don't use Babel when you use Vite. But if you are in the React ecosystem, The React ecosystem uses Babel plugins to do fast refresh, and to also work with css-in-js some of the transformations that they do. And we also use it in plugin legacy, that is, normally when you build you are going to target 92%, more or less, of the browser that are the modern cut, let's say. But then for the rest if you have to, I don't know, support Internet Explorer or more other browsers you need to include a plugin that is called plugin legacy. And there we are using Babel also during build. During dev you are always developing with a modern browser so you don't need to care about this. Patak: And in these two cases Babel is quite as slow and it will be really good if we could replace it with something that is faster. And SWC, as we talked before, is a replacement in Rust for Babel. And there is now a big push, for example, Vercel is pushing hard. The maintainer of SWC is working in Vercel. And they are working to implement all the plugins they need in Rust so they can speed up Webpack, actually, for themselves. But if they end up doing that and the ecosystem is mature enough, and stable enough, then we cool replace Babel by SWC in plugin legacy, for example, as a... I think that could be one of the first moves that Vite could take to speed up that particular ecosystem. Noel Minchow: And is the tricky part of that problem, is that JavaScript is there's a lot of work being done in JavaScript in that pipeline, if you're using Babel still? That is just that code needs to not be in JavaScript? Is that the main hurdle still? Patak: Yes. And also, for example, I think there could be some threat management also. If you're using Go it's really good about how to manage threat. JavaScript is single thread it there. But yeah, and also, how things are structure in Babel it's not particularly fast, let's say, system. But yeah, Rust runs a lot better. The problem is that if you go there, Babel was amazing for exploration. We have all these amazing css-in-js ideas and pattern because Babel allowed us to explore. And the same for using Babel to use syntax that was not ready in the browsers, so it was really good. Now, maybe we are at the point where we have enough. Maybe, I don't know, we don't need to reach that much for the future. JavaScripts has gotten a lot of features now in modern browsers that it's more than enough to be content there. Patak: But that's the problem. If we all move to Rust-based systems, then if you want to collaborate you need to do it in Rust. And then you get a way smaller pool, let's say, of people that can do that and can explore and create [inaudible 00:38:56]. So I think that we are still going to see these kind of [inaudible 00:39:04] patterns that are quite established, and we know that we want to do that. Then we can move that to Rust to go. And then for other things we can keep in TypeScript and JavaScript that if you code carefully it's really, really fast. The [inaudible 00:39:25] do a wonderful job. Noel Minchow: Yeah. Nice. That's awesome. Yeah. I feel like that's a good perspective too. It does lead me to the question of why do you think now we're at this point where we it's safe to start moving away from these more exploratory tools that are easier, like Babel. "Oh. We can do anything here." And now we can establish a pattern. And we're confident that we're not going to have to change these primitives anymore. Why do you think that we've reached this point now? Patak: It's a very good question because... Well, I don't know. I want to think that there is still a lot of exploration to know and lot of good ideas to still explore. But there are certain patterns that say that we explore, and we know now that we want to import CSS in a certain way. We want to... Certain syntax, it's established. And I don't know. And in the same way that you have all these maybe Babel exploration, and you can to whatever you want. But at the end of the day, at one point, all that exploration leads to the standard saying, "Okay, this is the way. And this is what the browsers implement." Patak: And maybe it's not, let's say, your favorite. But with time you end up saying, "Okay, I will use it. And I will stop using my custom thing," let's say, because the browsers do it and it's faster because it's easier to collaborate, because we all use the same so if you go to another project it will be the same syntax. So I think there is a nice dance there where it's good to explore, but at some point we have to get together and say, "Okay, let's keep exploring these other parts. But this, we've explored it enough. And let's use this, all of us." Noel Minchow: Right. Yes. So would you say that it's fair to say to them that the browsers were really what incepted this solidification of standards in that, again, a lot of the success and the gains that we're saying here, it's like, "Well, the browser can just do this now." Vite's success in and of itself was you guys saying, "The browser can do this now." Is that fair to say? Patak: Yeah. Yeah. I think, for example, Vite without ES modules, it's not possible. Noel Minchow: Right. Yeah. Patak: So the idea that once the browsers reach it a certain level when ES model were there available, that enabled this next, let's say, stage of exploration that again was a lot of exploration. And if you see VT1, that was the first year of Vite. Then when it was VT2 it was a complete overwrite. So there was a lot of exploration, even inside this new wave of tools. And still, we have things that are going to change. And even, for example, one thing that we are now doing in Vite is that we use suffixes. If you want to import a worker, you will say question mark worker at the end, or question mark. URL, if you want to get the URL instead of the resource, or question mark overall for example. And it's not ideal because the patients sometimes, you fix it for other things. And they will collide. And it's not the best. Patak: And also it's not a standard. There are other tools, for example, WMR was instead of using, for example, it will say raw colon and then worker colon and this. So it is not decided what it's going to be. When I import these things I want you to interpret as something else. Noel Minchow: Right. This is what I mean. Right. If I'm doing this. Yeah. Yeah. Yeah. Patak: Yeah. I want to import this but as raw, as text for example. Or I want to import this as an URL. Or I want to import it as a worker. And it's different how you have to compile it and what you need to do. And so there are certain proposals, for example like import assertions, it's one proposal. But that one, it doesn't let you change how you import something. It's just assert that what you are importing is really that. For example, if you import a .json you assert that the type is .json. But you cannot say import [inaudible 00:44:27] and assert something else. That is a clear assert on the standard side that you cannot do. But then there is another proposal that you are going to be able to say import something as, and then add, for example, something else they need this for Watson. But it's a stage one proposal right now, for example, and it could change completely. Patak: And so still in Vite we should align with the standards. But at the same time the standard is not yet there. So Vite, which has to fill the gaps and try to do it in a way that later we are going to be able to move to the standard way once it is done. And at one point maybe we need to introduce, in some way, or some breaking changes. And hopefully it's something that will automated with a code node or something. So user will not have to suffer from the change. Noel Minchow: Right. Right. So some flag or something to... Yeah, to instruct. Awesome. Cool. Yeah. Let's spend a little bit of a time talking about other projects here. I know I wanted to talk about the Vue ecosystem at large and how it interacts with Vite. Maybe a good first question is can you talk about VitePress a little bit? Why it's cool? Patak: Yeah. So there was this project that, and there is still, and it is called VuePress. And it was what a static generator can look with using Vue. So all the documentation from the Vue ecosystem was using VuePress before. And they started to work in VuePress 2 at one point. And that effort actually went really far. They cleaned up a lot of things. And they even [inaudible 00:46:27] the build tools, so you could use Vite even with VuePress v. 2. But at the same point that this effort of VuePress two was ongoing, Evan was started to work on a new tool that's called VitePress. And kind of like dogfood in Vite itself and also using it for the documentation of Vite. And the idea was now that we have Vite and we have this new plugin system, what should we change? If we have to start over, if we don't have VuePress there and we have to move the user, what is the best, let's say, SSG using Vue that we can have. Patak: And so, he started working on VitePress. And actually, it's interesting because if you use the Vite plugin ecosystem, say API, it is a lot simpler because you can directly use Vite plugins instead of having a own way to do plugins, like in VuePress, or there was, I think, I don't know how it's called of add-ons, or plugins, or something that. There was this concept in VuePress. And it was starting to get a little bit complex. And in VitePress you have the theme that you use. And that is a normal view, let's say, page application. And a lot of features are like SaaS, added normally like you will do in any Vue app. It's not like something it's custom to VitePress. So it's a structure that it's a lot simpler. And then Evan is starting also to play with SSR. And he did several innovations there in VitePress that it's like, for example, trying to all statics parts, trying to optimize it so the iteration will be a little faster. So at the end, VitePress has done kind of a proof of concept and seeing how it could be. Nowadays, it is kind of like VuePress 3, let's say. There is an open issue right now where they are discussing if they are going to call it VuePress 3 or if they are going to keep the VitePress name. Patak: But What is clear is that the successor of VuePress is VitePress at this point. And VitePress has taken over almost all the documentation in the Vite ecosystem is using Vite press. So today morning I was compiling for something all the projects that were using VitePress. And it's like, I don't know, 40 projects in the Vite ecosystem using [crosstalk 00:49:38] documentation. Yeah. Yeah. It was amazing. I did this a few months ago. It was amazing. It was half. So it's very comfortable to do documentation, or blogs. The Vue blog is using it for example also. Noel Minchow: Cool. Nice. Nice. Any other open source projects, or projects you're working on, that you want to spend a couple minutes plugging or talking about? Patak: Yeah. We could talk a little bit about Vitest, maybe. So one of the main pain points that we had during last year was that Jest and Vite were not a good match. It was quite difficult to integrate them. One particular thing we were missing was a singer transformer that we needed to integrate it. And it's funny because I think today Jesst's 28 finally has been released and it includes the singer transformer that we needed. And so the story right now with Jest's and Vitest is a lot better than before. But still, if you see the amount of things that Jest has to take care of and what you need to configure and the amount of things like Vite already take off. There is a lot of overlap there. Patak: So in a world where you already have Vite it doesn't feel right to get a whole other chain, let's say, a tool chain. And you download another, I don't know how much, from NPM to get it working. So also Jest was developed a long time ago and the ESM story is not as good. But now they're also adding a lot more support. But it's not to say SEM first. So when we were trying, it was in one of these team meetings that we were trying to say, "What do we do," because this is really a pain point. It was one of our main worries. And Evan and some other people are starting to say, "Okay, maybe we need to do a test runner or ourselves because there is nothing that we could recommend." Patak: And the name Vitest kind of appear there in the meeting. And Anthony Fu, that is a Vue core team member, I think, if people around Vue will know him. So he say, "Oh, I really like that name." Went to NPM and he was free. So he took it over. He went away after the meeting for a few hours. And he returned with a proof of concept. And this was also part of he was working in other tools before that, Vite Node also part of the max effort they needed there. Patak: So, there was a lot of pieces, let's say, that fall into place there around last December. And after he did that, then I said, "Okay, invite me." If you are going to write a shell replacement, I will help, let's say. So we are starting also working together. The first months it was sponsor work for a while. And other people joined the community. It was quite an interesting way to start because it was a small group. But everyone was really interested and helping. But we could do changes very quickly because everybody was knowing that it's not end users. So these initial months there were a lot of rapid development. And then it was open source. And now it took over. I think around last time I checked it was 15% of the download per month of Vite where Vitest. So Vitest includes Vite so more way that you can count. But it has been growing even more rapidly than Vite did, so it really took over. Patak: And you can use it like a Chef replacement so it's easy for unit testing, to replace even in a node libraries. But if you are using Vite or writing for an app it makes it more sense because of what I said before. If you want to check it's Vitest.dev, their webpage. And so now also it is a project on their own. There is a full team working there. Lately I'm more on the Vite side again, because there is a lot of things to do. I think in this week, or next week, we're going to start preparing for Vite 3. So again that, there is a lot of relationship between the two communities and it's quite good to see how much it took off also. Noel Minchow: Nice. Awesome. Awesome. Well yeah, it sounds like you got a bunch of a bunch of stuff going on. Somebody moving pieces, that's super cool. Nice. And anything else you want to plug quick before we wrap up here? Patak: I would say try. Try Vite, try Vitest. You can go to vite.new or vitest.new and try it out. I think as Evan said you have to try it and feel it to see the difference. Noel Minchow: Nice. Awesome. We'll get some links in the show notes, so listeners can check it out. Awesome. Well, thanks so much for coming on and chatting Patak. It's been a pleasure. Patak: Same here. Thanks for invite. Kate: Thanks for listening to PodRocket. You can find us at PodRocket pod on Twitter. And don't forget to subscribe, rate and review on Apple Podcast. Thanks.