Kate Trahan: Hello, I'm Kate Trahan, the producer of PodRocket, and with me today is Noel Minchow, the host of PodRocket. Welcome, Noel. Noel Minchow: Hey, Kate. Kate Trahan: How's it going today? Noel Minchow: Good. I'm good. How are you? Kate Trahan: Good. And joining us as a guest today is Anthony Fu. Anthony is an engineer at NuxtLabs. He's also the creator of Vitest, Slidev, VueUse, and UnoCSS. He also is the core member of Vue, Nuxt, and Vite. So there's a lot going on. We can dive in here. Maybe, Anthony, just tell us a little bit about yourself and we can get started from there. Anthony Fu: Hello, everyone. My name is Anthony Fu, and I'm really being glad to be here. Yeah. Noel Minchow: Awesome. Just give us a quick run through on what projects you're involved in. Maybe to start with, how did you get into the Vue ecosystem and find yourself contributing to all these projects that are such staples in that ecosystem today? Anthony Fu: Yeah. I think that my foreign development experience is beginning as my college freshman year. At that time I wanted to build a website of myself. So that times I starting to use Python Plus to acquire it for the format. And then there is a hype for Vue, which is being really popular in the Chinese community. And it's also being branded as very easy to learn. At times, I think, okay, maybe I should learn this thing and maybe give it a try. I starting to use Vue to factor in my website and use Vue to build apps. So yeah, I had been using Vue for few years, and at my senior year in my college I build an app and financial apps with a few of my classmates to trying to use Vue and to have some kind of an app to be useful for the normal user. At that times Vue three is about to come out. There's an RFC called composition API, which is already called function API, which is an overhaul of the API style of how you write Vue components. At that times that would be a bit some kind of discussion. Some people don't really like it, or don't really like the changes. But for new things that's inevitably people would be in deny of it.So there's a plugins for back to Vue two, to backporting the new features back to Vue two. So people could try it by using their tools. Basically me starting to being more involved with the Vue community, in open source instead of just in user. I think it's starting from there. At the time I want to use that APIs to build some cool stuff and inspiring from the right hooks. At that time I made VueUse, which is compiling API libraries for Vue. Also later trying to being a library both compatible for Vue two and three. At that time one of the dependency does not get really maintaining. So I figure out maybe I could take some time to helping me maintaining it. So I send an issue saying, "Okay, I volunteer to maintain this project to keep this project running." So that's been the first step for me to join the Vue team. Noel Minchow: Nice. Perfect. Perfect. Yeah, I want to talk a little bit about a whole bunch of stuff today. I want cover VueUse, and Vite and Vitest, but now you find yourself at Nuxtlabs. Can you tell us how you wound up there and what you're working on with Nuxt? Anthony Fu: Okay. Basically, I'm getting more involved with the Vue team. I'm starting to see that's more thing could improve for the developer experience for Vue. At that time Vue three is out and the whole ecosystem need to be catch up with the new version and to get hands on the new features, and maybe we could have more new conventions come out or new practice with the new APIs. I starting to build more tools around Vue. And that being a bit overlap with what Nuxt is doing. The creator of Nuxt, Sebastian, reach me out and say, "Yeah, I see your work is looking great. What do you think to join Nuxt, to work on Nuxt?" We are basically working on big similar things. So if I can helping Vue the ecosystem to get better, it's also helping Nuxt to get better since Nuxt is using Vue. So that's being why I can joined Nuxt, which is really what I'm enjoying doing. Basically after joining Nuxt, I'm still doing quite similar to what I used to do, which is now I get paid, which is really great to work on things I enjoy. Noel Minchow: Nice. Yeah. I feel like that's the dream of a lot of devs, especially those interested in open source, being able to focus a bunch of time on open source in a very supported project and have financial support for that as well. Cool. I want to spend a lot of time talking about Vite and Vitest, but before let's talk about VueUse a little bit. Let's say you're a Vue user, or even let's say you're not using Vue but you have context for how react works and everything, can you contextualize what is VueUse? Why might devs reach for it? Anthony Fu: Okay. Yeah. First I guess I need to talk about the react development team. Basically, in Vue we're providing a riff to holding a value. For React it is meaning that when you change the value of the riff, or anything holding it, it will notifying the other, for example, the Vue, the rendering, the UIs, or the other data relying on this data. So if this changes, it will automatically notify its dependencies to update them. If you change value of the riff, for example if you're binding it to a UIs or for the title, I guess, and when you change it the titles in your UIs will also change it. So you don't need to care about how you update the UIs or keep a line with them. You got a single source of choose of the data. And when you change the data, the UI's being driven by data. This is the initial idea of Vue. And in Vue conversation about extracting out so you can have really fine growing control of which value you want to be in reactive or which is not. So for reactive for VueUse is to providing a collection of tools or utilities surrounding with the Vue's reactivity. For example, when you want to have a components and you want to listening to something, for example maybe you want to listen to the position of your mouse, normally without Vue you may just use Window dot, add a event listener and mouse. I think it's mouse move. And then you can guide events. Other times when you finish the test you want to have another page that you don't need the event anymore. But you have to remember that you need to unregister using remove event listener. Otherwise, it will still keep running and that'll be a bit hard to handle it. In Vue, Vue components handle a bit of that is that it will remove the dumps when the components get among it. And with VueUse we're providing a utility called use event listener, which is basically you can thinking that it'll register events and to get it reactive. And when the components get disposed it'll be removed automatically. So you don't need to care about the rest of it. And with this, we can build on top of that to maybe providing a high level. We can say use mouse. Instead of to return event and a call back each time, we just return the riff called X and Y. So you can get the value of the X, Y position of your mouse in real time without worrying about how you update values, which is basically how VueUse is doing. We are providing hundreds of such things either is a wrapper of the web APIs, or either some utilities helping you to transform your datas. Noel Minchow: Nice. Are there other functions or hooks that are super commonly used? Do you guys have any idea which functions in the library are the ones that get referenced the most? Anthony Fu: Oh, yeah. I just did that I think a few days ago. I just grabbed all the dependency. In GitHub you got a dependent list of how many rate posts is relying on this package. I write in script to scroll down all the rate posts and to do the scanning of their code and to count which function is used. We just released the 9.0 version, which is a new major version. I feel we got quite a lot of functions and I'm thinking to remove some not really commonly used APIs to make it more concise, or something. I wrote a script and I think it turns out... Yeah, I need to check, but I think for high place is one is called used storage that you can turn and riff into a persistence into your local storage. So when I change the value it will right to your local storage. And when you refresh your page it'll be overloaded, so you can sync this one. This riff will be persists across each sections and we're storing in user's device. And the other one I think is called on click outside. You can bind the riff to it. And when you click outside it's really useful for a dialogue or for mode. When you click out either it will close it or something, you want to trigger something. Noel Minchow: On click outside does seem super, super useful. I found myself in every framework I've worked on writing the equivalent of that in some form. So having a hook or a function prebuilt for it that can listen for that reference and trigger updates, that does seem super, super useful. Enjoying the podcast? Consider hitting that follow button for even more great episodes. Yeah. I'm curious too about the use local storage. I know we're beyond this point of using Redux or UX for storing state, but do you think these utility functions in these hook libraries are what's pushing us away from things like those session storage libraries, because we can just use local storage with these nice hook components and make it a lot easier to reference that state? Do you think that that is pushing that general trend? Anthony Fu: Yeah. I think in Vue's new conversation API in general, it can replace VueX at some extent. So you can just have a riff as a modules, and then you can import that modules from everywhere so that you can have a shared state. I think indeed that can cover some simple cases. You just want to have a value. I think the storage or Vue X or recently the opinion is providing the functionality. For example, for SSR capability. If you have a shared variables across multiple components, we'll render the apps multiple times, it'll be shared. So it won't be clear. The data from the previous request will be persist on the next one, which is not good. The storage libraries handles that. Also it can providing you to better organize of your code and your state. I think also for that to support, it will fire up an event to the dev tool so you can see that when you change the values. I don't think the hooks use storage would conflict with the store libraries, but instead that's a quite common conventions that people would use Pena, which is a storage based... It's composition that based their storage library. It's now the default recommendation from Vue storage. I can see that it's a common pattern is that people use Pena to control their state and combining with use local storage to do persist so you can just passing or use storage riff to the Pena. So that part of data will be persist. So you can still gather the benefits of your storage library while you can persist them very easy. Noel Minchow: Yeah. It makes sense to me that there's data that you want to have just persisted in JavaScript in memory at run time versus putting stuff in local storage permanently. I find it interesting, because again, it's so common. People say, "Oh, we don't really need VueX anymore. You have hooks and components and all these tools." It's not always quite as easy as it was in the days of just, oh, we have this global state, you can reference it everywhere. So yeah, I was curious if you thought that that was a piece in that puzzle of, well, it's easy to store stuff in local storage now with hooks. It makes it nice and clean. But yeah, I think you covered it well. Are there any other interesting developments recently in VueUse that might be interesting to devs that haven't checked it out in a while? Anthony Fu: In VueUse we are trying to make each functions as more compostible as possible or more flexible as possible. I think at the 4.0 stage, which is now 9.0, and we introduce in convention is that for each hooks or utilities we're accepting role values as an argument. Also, if you want to providing a riff, it's also due. For example, let me think, we have a function called use title, which update the title of your tech or your website with value. And if you use title with a string, it'll update the title to a string and it will return my riff and you can update the riff to change your title. But if you want, you can also providing a riff to that function. So it'll binding them to the title. So this riff for some reason you can come up with another function, maybe you can use Fetch to reach from the other resource. But anyway, if you're providing a riff to that function, it will be reused that riff to use that riff to update your title, which is being connection between your datas. Recently, we're also adding a more new conventions that you can pass and gather function. You can add a function to it, and then you can do some computed thing to it. For computed it is setting a function to get some value. So if you have a double, you can have a counter times two inside of a computed. And when the computed changes, the computed will be changed. That argument of computed is a function, and it will returns a computed riff, which is also a risk. In the past you can use a computed and then pass that computed riff to use your title. And now you can just directly passing the function to it as a computed value. So you don't need to make intermediate riffs if you don't want. We're factoring all the functions to support that convention. So it'll also working well with the recently reactive transform, where you don't need to do value at all, but you need to keep the reference of the value. So now you can pass- Noel Minchow: Being able to pass around and share references, that seems like it'd be super handy. If you have multiple values that you want synchronized in the same way, right? Oh, I always want these three things to read the same way. Oh, we can just share our riff and it'll be fine. Anthony Fu: Yeah. Right. Noel Minchow: Yeah. That sounds super handy. Cool. Awesome. Well, let's ensure we have some time to talk about Vite here. I guess, to start with, can you tell me a little bit about why Nuxt and NuxtLabs cares about Vite? Why does Vite matter to NuxtLabs? Anthony Fu: For me, I think the reason is quite obvious is that because of the performance and the developer experience things. Vite is being really fast and providing really, really good device experience with the instant HMR, the hard module replacement. It will make you the feedback of a development really close to instant, I think. When you change the value inside of your code it'll be automatic. It'll be instantly change to your app, which I think it used to. In the past, if you use Webpack or other thing, when your app get larger the reload takes quite a few times, maybe a second or two, and it'll interrupt your workflows, I think. If you want just quickly try all things and you need to wait for every time you changes to say, okay, this one doesn't work, you need to change again. So at that aspect there's, I think, obvious reason to choose Vite to providing a better developer experience. And also since Vite is developed by the creator Vue. And after I think Vite 2.0, Vue is also now switching to recommend to use Vite by default. So it's also a huge shift for the Vue community to switching to Vite. And it's obvious for a reason for user want to use Nuxt also want to use Vite and enjoy the ecosystem of it. Emily: It's Emily again, producer for PodRocket. I want to talk to you. Yeah, you, the person who's listening, but won't stop talking about your new favorite front end framework to your friends, even though they don't want to hear about it anymore. Well, I do want to hear about it, because you are really important to us as a listener. What do you think of PodRocket? What do you like best? What do you absolutely hate? What's the one thing in the entire world that you want to hear about? Edge computing? Weird little component libraries? How to become a productive developer when your WiFi's out? I don't know. And that's the point. If you get in contact with us, you can rant about how we haven't had your favorite dev advocate on, or tell us we're doing great, whatever. And if you do, we'll give you a $25 gift card. That's pretty sweet, right? So reach out to us. Links are in the description. $25 gift card. Noel Minchow: Gotcha. So does Vite help with Nuxt's server side rendering at all? Or is it really just to improve the dev experience at development time? Anthony Fu: We're providing both Webpack and Vite as a configurations if you prefer, as a bundle order you can switch to. And when you're using Vite it's entirely on Vite, so you don't need Webpack at all. It is used or both dev and for server side rendering and also for build. We did a few tricks to that Vite working on dev on a real time SSR, things that we need to build an app with server side version. And that versions, we used to use [inaudible 00:22:45]. When you change the code it will bundle the whole apps again. But that things will lose the value of hard module replacement. Even though your apps load very fast, you need to wait for the SSR bundle to bundle. So we come up with some kind of a trait to... I mean, I think it's run timing evaluates for each modules. Basically, now it's also on demand. So when you request that modules we only skill the codes that need to render this path or this route. Interestingly, this is also becomes a core of Vitest, which is running VIte but on another side, which now this project is now called Vite Notes. It's to use Vite's transformations, use Vite's pipeline to do the transformation, and then it's skilled in them for node. So you can have really the consistency of your dev and you build, and also for server side rendering. If you're providing a custom plugins to do some transformation magic, it's important to having the magic for both your dev and build. Noel Minchow: Nice. Yeah. That sounds awesome. And given the performance improvements that come with switching to Vite, I feel like that has got to make the entire Nuxt development experience quite a bit better. So that's super cool. I know you talked about it more broadly, but how did you find yourself working on Vite? How did you become interested in build tooling, or did it just seem a natural progression because you'd been working on these other libraries that were tied to Vue for so long? Anthony Fu: Yeah. I think my main motivations on developer experience is my laziness. I'm being lazy to do some repetitive things. For example, if you need to import the components in to use it in area of your components in the register, I feel that I'm being reluctant to do it. I would try to find a better way to do it so I can have my code better organized, or have my development speed faster. Also, that's why I made a plugin for Vite that auto imported components. It follows the conventions. If you put the components on the components folder, you can use the malware, but without the limitation of your global components, but it will be import on demand with matching the philosophy of Vite. It will be only bundled or transformed the way you use them. Basically, that's my main motivation to do that. Also, I think for open source in general, I can think the comments or the feedback from the community is really the source of my motivation. If I made the tools and people use it and people say, "Oh, this is really great, and save me a lot of time," that make me feel my work on these things is very valuable, not for me, but also for others. So that keep driving me to do more of the... Becomes a bit magical. Noel Minchow: Well, if you need more motivation in that regard I've independently stumbled upon both the auto importer plugin and VueUse and have used them heavily. So yeah, major props. I have found them immensely useful. Anthony Fu: Thank you. Noel Minchow: Yeah. Yeah. They're so good. I love it. We chatted with Matias Capeletto a few weeks ago about Vite in general, and he was telling us about that whole development process and how you guys work on it. Have you ever taken energy or thought about helping devs migrate from Webpack to Vite, and what that looks like? Any tips you could give developers who are on the fence right now? Anthony Fu: Yeah. I think I'm being the lucky guy. I don't got a Webpack project to migrate to Vite. So yeah, probably I just starting new projects using Vite. I actually don't have this concern, but I understand that it can be a long process or a bit painful process to do it, especially when new app's getting larger. My work is basically on the tooling side. For Nuxt I made a tool called unplugging, which providing uniformed APIs for plugins to have your plugins right ones to run on both Webpack and Vite, and also for [inaudible 00:28:01] and ESbuild if you want. So this one is that I'm trying to helping the developers, the libraries authors, to making it easier to supporting for both Webpack and Vite. So that's indirectly helping users to migrate, I guess. So if you use the tools that work for both worlds you can use this tool first, and then when you migrate to Vite it doesn't change the behavior, so it will help you to migrate easier. Noel Minchow: Nice. Awesome. Yeah, I mean, that does sound like it'd be super handy. And then again, I know we're covering a lot and moving really fast, but I want to make sure that we cover everything a little bit. And I want to talk about Vitest a little bit. What motivated you to start working on Vitest? And what is different about it compared to Jest or the other existing JavaScript testing frameworks? Anthony Fu: Yeah. The first is that I love Jest a lot before Vitest, I think. Jest as one of the most popular testing tools in the JavaScript framework. I'm really enjoying the auto box experience it's providing, the snapshot features and providing the coverage. That's auto box. You don't need to configure anything. But compared to the other solutions you need to... It's really hard. For example, if you want to [inaudible 00:29:29]. I don't know if there's a way to get a snapshot working, which for me I'm being lazy people so I'm really into using snapshot to do the testing so I don't need to write the result of the test. The bummer of Jest is that at that times it doesn't providing good ESM support. And while for Vite we are advocating to moving the ecosystem to ESM since we're shipping the ESM to the dev server. That's your browser to handle the request and handle the part of bundling thing. It becomes a bit harder to use just along with Vite since Vite is in ESM, but Jest doesn't. The motivation for me is that when we do biweekly meetings for the Vite team, there is a position for us is that we cannot really recommend a good testing tools in company with Vite in our documentations. So people are asking how we can test a app building with Vite. If you're using Jest, it'll be a lot of configurations. And maybe it's easier for [inaudible 00:30:56] but you are losing a lot of good features that Jest provided. With the previous experiment we did to run Vite on note side I feel that, okay, maybe we can use Vite to build a testing tool so you can reuse the pipeline and reuse your plugins to run the test. And yeah, I think that's being the reason it comes out. I work really close with Matias, the other coding member of Vite. And we cause this tool, and then more and more contributors comes in. I think we now have a six people team for Vitest and we're iterating really fast. I think that's really promising team I have. Noel Minchow: Yeah. Like I was saying, we talked to Matias a few weeks ago and it was awesome. He gave us tons of insight on Vite three and what was coming down the pipe. So go check that one out if you're interested, listeners. It sounds like with Vitest, it was motivated by the fact that it would've been a lot of work to try to get these other testing frameworks working in a Vite first environment. And it almost seemed easier to start writing a testing framework. Is that an accurate synopsis? Anthony Fu: Yeah. Essentially not easy to write from scratch. Noel Minchow: Right. Of course. Anthony Fu: Yeah. Initially, my thought is that maybe I can get Mocha working with Vite, and I can use just snapshot to get the feature back to gather the features we lost when switching from Jest. Initially, I was just trying to make a testing tool with the bundle of the other tools, or a bit like preconfigurations of how the testing tool could be. How about with that maybe we want to have a more customization, or maybe we can provide better developments variance if we're in line some part of the components. So yeah, it stands out. We initially use a thing called Sinon for mocking and for spining a function call. And later we decide to write our own, which is now in another organization called Tiny Labs, which are called Tiny Spy. Yeah. We also care about the full point of the package, so that package will be really small, I think, in a few kilobytes, I think. Basically, it's not an easy work, but it's just the nature output of we're trying to make testing tools to work with Vite. Noel Minchow: Right. So if devs want to check out Vitest, do they have to be fully bought into the Vite ecosystem? Maybe this is a better way to frame this question. Say you're using Vite with React, could you use Vitest to test that app? Anthony Fu: Yeah. Just like Vite is framework agnostic, Vitest is also framework agnostic. So yeah. For example, the Vite support of Vite is providing a plugins called Vite plugin view. Only when you install it it will change the Vue's files into the correct JavaScript. And since Vitest also reuse the Vite's pipeline so you can just use that plugin in Vitest to enable the testing for Vue. So similar for other framework, like Svelte or React, if you just install their corresponding plugins and it will just work. Also, if you are not testing from in, if you want to test back in, it's also possible. It just use Vite, but you don't have to use Vite to build your app, but you can still use Vite to test in your functions. Noel Minchow: Oh, interesting. So what would that look like? Say we have a very basic backend framework system of some kind. How would I use Vite to do that testing? Anthony Fu: Yeah. You don't use Vite, you just use Vitest, and Vitest will install Vite if you don't have- Noel Minchow: I'm sorry. Yeah. Vitest. Anthony Fu: Vite is one of the dependency of Vitest. So even if you don't use Vitest for your apps, it'll install it if you install Vitest. The APIs of Vitest is very similar to Jest, so we're being inherent from their designs and their good parts and we take it from that. Also, make it easier for people to migrate from Jest to Vitest. You're just changing a few things to Vitest and it should work for the most of the case. So the API is highly compatible. It's just like how you're testing functions with Jest you can testing with Vitest. Noel Minchow: Yeah. That was my next question, that is what the migration looks like. So it sounds like you wouldn't have to change the logic or the functional part of most of your tests. The APIs are largely compatible? Anthony Fu: Yeah. Noel Minchow: Nice. Say you have an existing project with a very extensive Jest test framework, would the way to go about migrating then just be try to switch it out for Vitest and update all those at once, or would there be an incremental migration possible? What would you recommend? Anthony Fu: Yeah. I'm not really sure about it. Indeed that's using a basically similar format. You can run a test file for Jest and Vitest. Maybe you can tackle space on folders or files. You can have global rules of how the test being included. So yeah, I don't think most of the time you don't need to change the code. You can just trying to run the test file with Vitest instead. And if that would work, yeah, great, you can move into the next file. Yeah. It's basically, indeed it can be progressive if you want, but that need to have a bit effort of splitting test, which is for Jest, and which is for Vitest. Yeah. I think this one is for how you management your project. Noel Minchow: Yeah. I'm sure it depends on project structure and even how you specify what tests are running against what, so there's some nuance there. But cool. Yeah. Thank you for covering that a little bit with us. Is there anything else you'd like to share? I know you have a ton of projects and there's always a bunch of stuff going on. Anything else you're excited about or want to point listeners towards? Anthony Fu: Yeah. I think maybe give a try on Nuxt story. So we've been working on this for almost two years. We are now in our safe phase. We are close into stable release. We did quite a few, I think, innovations to how to adapt to, or how a framework could be, and how these tools could help you to write better application while having good developer experience. Also under Nuxt three, we also have a new server side rendering engine called Nitro. Nitro is basically [inaudible]. It's also a framework agnostic. It's [inaudible Nuxt, but it can be providing as an engine for the server side rendering app. I think for any firm it will work, but we're meaning for using it for Nuxt now. It is providing compatible layers for any of the providers, the deployment providers, for example, for Netlify, for Vercel, or for CloudFlare workers. It also can deploy to, I think, 4H, to Netlify H. It's called Vercel [inaudible]. It's also possible for static host. It have pages. All of them are providing universal interface, so you can write the code once to deploy the functions to any of the host providers to get the best performance of it. If providing server side functions, to mapping with the serverless functions for each providers, which they're having a slight different APIs and the design. So we ease out the difference. With the power of Nitro and Nuxt story it's also working as you can write it once and deploy it to any provider you prefer. Yeah. I think if you are using Vue you should definitely check out Nuxt 3. Probably if you are two author or a friend with author, maybe you can have a look at Nitro. Noel Minchow: Awesome. Cool. Well, yeah, we covered so much. Thank you for going through all that with me, Anthony. That was an awesome chat. I appreciate it. Anthony Fu: Yeah. Thank you. Emily: Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcast. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs, like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts.