Noel: Hello and welcome to PodRocket. I'm Noel. And with me today is Haoqun Jiang. Haoqun is a core team member of both the Vue, Vite Teams. He's here to talk to us about his latest conference talk from VueConf, Vue's road to Vite. Welcome to the podcast. Haoqun: Thank you for having me. Noel: Of course, of course. Before we get into the talk and what you're working on, can you tell us a little bit about your background and what it's like to work on open-source tools like Vue and Vite. Haoqun: Sure. I joined the Vue.js team around 2018. That was four years ago and that was around the time Vue CLI 3 came out. So I have since worked on the Vue.js tooling space since then. And now I have also joined the Vite team and work on the Vue integration of Vite and other stuff. So my main focus is about the frontend tooling. And the frontend tooling space is quite a large ecosystem and it requires a lot of knowledge about all the things happened in the community.s So I have to be full-time in the team. And I was for quite a long time the only full-time team member except for Evan You himself. And that's a very amazing journey, actually. Noel: Yeah, I'm sure it was. When you first kind of got involved with the Vue ecosystem, what were you focusing on initially? Haoqun: I focused on the Vue call for a short time and then my interest, I was interested in the compilation and bundling and a lot of that stuff I mainly focused on Vue CLI, then standard tooling for Vue.js. Noel: Nice. And again, I want to get into the main part of the talk here soon, but I'm, I'm also just curious, how has the ecosystem around Vue and Vite evolved since you've been working on it? How has it felt to see, I noticed the popularity grow so quickly. Haoqun: When I started to work on working on Vue, it was still called a library that is main Vue library with some of the core packages like router and state management and other things. And since then the community, the ecosystem grow quite a bit and it is now called a framework. It has a lot of upstream packages and downstream packages. And same was the case for Vite when I joined the Vite team, it is just a fancy new tool in the frontend community and now it has got dedicated a conference. Noel: Yeah, yeah, it's been really cool to just see it evolve and I guess as a developer it's nice to have, always nice to have more options out there that are viable, that people are excited about using. I think that helps keep everything moving forward, so it's been appreciated. So let's get into the actual talk a little bit. Can you give us an overview of why you titled it "Views Road to Vite?" Why has it been a road to Vite? Haoqun: It was mainly because the Vue CLI, the project I have spent years in it, so it has already become very large and since this came out, we evaluated the available options and decided that it provided a better experience for Vue users. So we decided to switch over to Vite, but to migrate all other available features, which used to be in Vue CLI to Vite it takes quite some effort. So it's a long road for us to fully invest into Vite. Noel: Was that a hard decision to make to start pushing Vite as the default way to set up and scaffold new projects? Haoqun: Yeah, it's quite difficult decision, because first I would like to maintain Vue CLI alongside the Vite integration, but later I find it very hard because we don't have, as an open source project, we don't have that many resources for us to get into that and we have to put Vue CLI into maintenance model this spring and most of my time are now spent in Vite. Noel: I'm sure that always is a tricky decision, especially when the community is as large as it is and there's so many projects out there and so many fledgling developers trying to figure stuff out. But again, I think it makes a lot of sense. I guess to help clarify for listeners, how do devs set up projects with Vite now? Typically, if they're scaffolding a new Vue project? Haoqun: There are two ways to set up a Vue project in Vite. First, if you are from the Vue community, we recommend you to use the NPM create vue command and show a prompt to choose all the options. And it's quite like what we used to create a project with Vue CLI. And if you are from the Vite community and want to try out a new framework like Vue, you can just use the NPM Create Vite project and we'll fix the Create Vue project into the Create Vite project already. So it's basically the same project but two different commands. Noel: Is there any confusion that you ever get from developers that stumble into old Vue CLI tutorials and stuff online and the don't know what they're trying to get into or they don't know what questions to ask? Is that a problem that you guys run into? Haoqun: Not much actually. Noel: That's good. That's good. Yeah, I feel like that was... There was a time when you'd see a lot of posts on Stack Overflow and stuff and people are confused about Vue versions and Vite versus the old way of spinning projects up with Webpack. But it does seem to be tapering off. Can you tell us a little bit more about that move away from Webpack? How has that felt? Have there been any growing pains that you guys have experienced? Haoqun: Actually, when I start the move away from Webpack, it feels quite difficult and I don't know what to do in the first. But now that we have already in a stable state, so I can see in a hindsight it's quite natural because for people using Vue from before I joined the Vue team, five years ago, six years ago, there the good old Vue CLI projects, just a simple command that grabs a template from GitHub repositories and created a Webpack based the configuration for you and you just start up the Webpack dev server. And then later the Webpack configuration became so complex that it is not ideal for you to change them, edit them directly. So we created the Vue CLI 3 and 4 and end support 2 to encapsulate all these options. And now with Create Vue and create Vite, again, the bundle's configuration is directly exposed to you. You again have vite.config.js and it's no longer that bloated. So it's quite like the old Vue CLI but in a more elegant way. Noel: Yeah, nice, nice. From my experience, I would agree. Is there a reason you think that the configuration via Webpack grew more complicated? If we view the Webpack config as an API. Do you think that there were bad abstractions in that API that made it difficult or was it just inherently because of the way that Webpack needed to be configured, it led to a lot of complexity that didn't need to be there with Vite? Haoqun: I have say it's both. To a certain extent, it's that Webpack has so many options and so many features that some of them Vite will never catch up with. So it's inherently complicated. And also there are some bad design choices made along the way because Webpack is a 10-year-old project. There have to be some bad choices. I mentioned in my talk that Webpack has both the plugin API and the loader API and that was quite bad choice because people even experienced the developers often gets confused that. Noel: Yeah, it can be a lot to take in I think. And again, especially if you're not dealing with it every day and it's like, "Oh, I've got to go and look at this configuration once every three weeks." It's just kind of like, "Ah, it can be overwhelming." Is there anything you guys are doing to avoid those pitfalls that, again, you said Webpack has a lot of features, it's super, super configurable. For a reason right? People wanted a lot of things and that's why it got into this state. Do you think that it's possible the same traps will be fallen into or is there anything you guys are keeping an eye on to ensure that this we don't get into the same situation? Haoqun: Yeah, I think the Vite team has done a great job in this area. The Vite team has a biweekly meeting that we discuss all the PRs in the GitHub repository and most of the PRs are feature requests, feature PRs, not only requests but other features already implemented by the contributors. And we decided that all the new features should be agreed upon by the whole team. And we have a GitHub issue label on GitHub named the YAO, means Yet Another Option. So we will look at this label, other issues under this label carefully that if it's another option we need to think about, is this really necessary? Noel: Yeah, that makes a lot of sense. Just as you guys are triaging that it can be hard to filter those because I think a lot of devs have some form of this problem where they want even their internal APIs, the code they're writing to be super configurable and usable in lots of ways. But inevitably as you expose those, if you expose more and more, it becomes more of that knowledge becomes necessary to be had by the end user and it is a tricky line to walk. So that effort and energy is appreciated as you guys try to keep that simple. I've kind of felt that Vite's been getting... Had a slow adoption. Slowly people are using it for proof of concept and stuff right now. But it feels like over the past, I don't know, six months, it's really ramped up. People are looking to it for their large production workloads and it's in the mainstream. Is there a reason you think that that's been catching on lately? Do you agree that we've been seeing a big explosion lately and do you think that there's a reason that that's happening? Haoqun: Yeah, I think Vite really took off after Vite 2.0 released. Because Vite 2.0 changed its plugin API to align with Rollup and since then all the Rollup plugins are available to be used by Vite users. And then faster enough bundling tool and large enough plugin ecosystem made it possible to be a tool using serious projects. And since then the adoption of Vite really taken off. Noel: I have a note here about Vite's small yet self-sufficient core. Can you tell me a little bit more about what that is and how that relates to the plugin ecosystem? Haoqun: Yeah, it's actually based on our past experience with Webpack and Browserify and other stuff that many tools feels very difficult to get your hands dirty at first because they don't provide enough tools and configurations for users. So in Vite, all the necessities for you to spin up your project up are baked in. That is the bundler, that dev server and the preview server and all the other stuff like static assets handling and the CSS integrations, they are all on by default. It makes quite a big difference between on by default or you can add up later because many new users won't be able to find other things that they needed to use in a fresh new project. Noel: Yeah, yeah, I agree. And I also think it's often hard to enable those things later. Once you've begun, you may not know that it's even an option for your existing tooling, so you add it some other way then you discover you could have done it with the core that's there, but it's like you already spent all this energy setting it up some other way for something like yeah, CSS or I don't know really, really anything in that bucket. Like the static asset handling... We're into that same problem. See I think that having those on by default and then people that know that they have some strong preference, another way they can go disable it and figure it out themselves. Are there any use cases that you guys have found work particularly well with Vite or anybody, any unexpected ones where you've seen a lot of success in the community that you weren't expecting to see? Haoqun: Yeah. I think the most successful use case is SSR, because new frameworks like Astro and SvelteKit chose Vite as their default tooling because of the good SSR's part in Vite that was quite hard in the past because totally different problem space than the old pure front center thing. And another one is the Lex plugin because in the past we have to configure our Babel and Polyfills and other stuff very carefully to support the old projects. And in Vite, it is only a plugin and the plugin is maintained by our core team. So you can just edit and your project automatically support all the browsers. Noel: Yeah, that makes a lot of sense. Taking a bit of a step back, we touched on this briefly but I want to talk a little bit more about the feature migration from the View CLI to the that interface that you guys had to migrate and are probably working on a little bit still. Can you tell us a little bit about the difference in the way now that users interact with those two things or if there is any, and how you guys approached that when you have especially someone new, for example, a new dev coming on, they're looking at the CLI tooling. Was there any common pitfalls that you found people falling into with the Vue CLI that you're been able to avoid now or were you largely modeling that same user experience when using those scaffolding tools? Haoqun: I think we've taken the opportunity to rethink a lot of best practices or I should say good practices because this might not be the best. We used to have an ESLint plugin in Vue CLI and have TypeScript plugin and that is quite complex because ESLint and TypeScript are both very huge ecosystem and now we've decoupled it from the main tooling so you can now use ESLint directly and you should use TypeScript directly when interacting with Vite and that took a huge burden off our shoulder. Noel: Yeah, I guess can you tell me a little bit more about how that works? Because I feel like I've always just defaulted to using TypeScript. How is it different now than how it used to be? Because I feel like before in the old Vue CLI, there was a question, would you like to use type scripts and you'd just select which one if you wanted to or not. Is that not how it works anymore with Vite or is it similar but different under the hood? Haoqun: It's similar but it's different because in Vue CLI, when you add TypeScript support, it adds TypeScript compilation support and the type checking support at the same time. And the type checking pipeline is built into the webpack compilation pipeline. And that was quite complex integration. So now Vite has it support TypeScript source files by default and the type checking is totally different problem space. So it's decoupled from the Vite and you should use tsc for playing TypeScript projects and vue -tsc for Vue projects. Noel: Gotcha, gotcha. I'm just curious, it's an aside, but you guys have... Does Vite or did the CLI, did it collect telemetry on how users were using it? Were there calls home to figure out what percentage of users were enabling certain flags or anything like that? Or do you guys just have to anecdotally see what people are committing out on GitHub or talking about in the dev channels? Haoqun: We don't have a telemetry or something, but we can see from the NPM plugin download stats so we can see how many peoples are downloading the TypeScript plugin. Noel: Yeah, I guess that makes sense. If enabling certain things always goes and pulls stuff down from NPM, that's probably a pretty easy way to do it. So you end up with telemetry that's not explicit, but by virtue of having downloads occurring, you can see what people are using. Are there any config options that don't kick off or lead to specific polls that it's hard for you guys to know if people are using it heavily or not or do you feel like you have a pretty good handle? Haoqun: Most of the time we have to go to Twitter to startup poll. Noel: Yeah. Nice. I think that's okay. Yeah, just ask people what they're using. Where do you start those polls usually, what platform do you use to get that feedback? Haoqun: Sometimes it's on Twitter and sometimes it's on GitHub. Depending on the nature of the available options. If it's too complex, we need a GitHub thread to explain that and it's the same as simple as, "What command should I use?" We go to Twitter. Noel: Yeah, totally. Totally. That makes a lot of sense. Do you guys use those same feedback channels to figure out what you want to work on next or what you want to maybe add to Vite? Or are you mainly using pull requests to figure out what people care about as new features? Haoqun: Pull requests are the mostly important metrics because we don't have that many resources. So we need to make sure there are people willing to work on that feature. Then decide ways to devote more time to it. And then we have our own project board to discuss what should go into the next minor or major version. That's more broader features such as upgrade major dependencies such as Rollup 4, Rollup 3. Noel: Are there any other major exciting packages or improvements that are coming soon that you are particularly excited about? Haoqun: We are going to adopt the SWC plugin for React into our GitHub organization. So users now have two choices to spin up React project. So one to use Babel for faster refers and one to uses SWC. The SWC plugin is faster but heavier. It's downloads about 60 megabytes of dependencies. But it may refresh your pitch a little bit faster. So if you are sensitive to the hot module, replacing the time, you can use these. Noel: Yeah, yeah, I'm sure there's a lot of devs that 60 more meg to give them even a fraction of a speed increase on the rebuilds is probably worth it for them, so. Nice. That's awesome to hear. I guess, yeah, more broadly, is there anything else you want to point listeners to or encourage people to check out before we wrap here? Haoqun: Yeah, recently Nuxt 3 has got released and it's bundler agnostic. It supports both Webpack and Vite, but the Vite experience is obviously much faster and along the way it has created a many useful tools for other Vite ecosystem together. So I encourage listeners to try out Nuxt 3 and find out all the good features in it, and I'm quite excited about this. Noel: Nice. Awesome. Awesome. Well, yeah thank you so much for joining me today, Haoqun. It's been a pleasure talking. Haoqun: Yeah, thank you for having me. It's a pleasure to talk to you. Noel: Of course.