What’s New in Vue 3 Ecosystem: Introducing Vite 2 with Evan You

EPISODE 58

[INTRO]

[00:00:00] T: This episode is brought to you by Ionic. For more, visit ionicframework.com/vue.

[EPISODE]

[00:00:15] T: Hi, everybody. Welcome to Enjoy the Vue. I’m Tessa. Today on our panel, we have Alex.

[00:00:20] AR: Hello.

[00:00:24] T: And our very special guest for this episode is Evan You. Evan, would you like to introduce yourself?

[00:00:30] EY: Hello, I'm Evan. I work on Vue and Vite. That's it.

[00:00:35] T: Great. That's a lot. I think, our guests probably know about Vue. Alex, do you know what Vite is?

[00:00:43] AR: Yes, I think. It's the command line tool that you use to make various applications and it can bundle stuff. It's uncomfortably fast.

[00:00:56] T: Yeah. I think if you had asked me the last time Evan was on here, I might have described it as like Vue, but fast for developers. Now my impression is it's a bit more like Webpack, but different. Like you said, a bundler, but really fast. Evan, why don't you tell us what it really is, or how far off we are?

[00:01:17] EY: Sure. I tend to call Vite just a build tool, because it does quite a few things in a single package. If you think about Vue CLI, it's a thing that's built on top of Webpack, with a lot of added features pre-configured. It serves your code during development with hot module replacement. It [inaudible 00:01:40] your code for production. Vite is something that's more than a more than just a bundler, because it's opinionated, it's pre-configured in a lot of ways. A lot of the features that we are used to today works out of the box, like importing CSS, importing TypeScript, or to a framework agnostic extent.

A lot of these things, or modern front-end developers are used to. It's baked in. It works out of the box. During development, it's a dev server that serves your code over native ES modules. It's pretty fast. For development, it uses roll up under the hood to bundle your code for production. We add a lot of these pre-configuration stuff, so that it works the same way during dev and prod and you don't have to mess with the configuration that much. If you want to say, use Vue with Vite, there's a plugin. At the plugin, and it just works.

I guess last time, we already talked about Vite 1. There are a lot of new stuff in Vite 2. Yeah, so the biggest changes is it's now framework agnostic. It's not just Vue specific. It works equally well for most of the other frameworks that people want to use.

[00:03:07] AR: Super exciting. I've definitely mentioned that to a couple of people who I was like, “Have you played with Vite?” They're React developers. They're like, “Yeah. No, it’s that Vue.” I'm like, “No, no, no. You can use it with React.” They're like, “Really?”

[00:03:22] EY: They're skeptical, because it’s from –

[00:03:24] AR: They are skeptical.

[00:03:26] EY: Yeah. I can imagine.

[00:03:28] T: What inspired the change to make it more officially agnostic?

[00:03:33] EY: Well, the thing here is first, I realized we have a lot of these Vue specific logic inside Vite, which just felt dirty in a way. I realized we will need a plugging system anyway. What better way to test it, by integrating Vue with it? I feel like, if we can design a plugging system that allows Vue to work nicely with Vite, then it probably can handle anything. That was one of the motivations.

The other thing is I felt I've invested a lot of time into Vite. It would be great if it could benefit not just Vue developers, because a lot of these stuff is shared across all modern front-end projects. It would be a pity if we built this blazing-fast implementation, but only Vue developers can experience it. I guess, the I tend to ask the question in reverse. Why would we want to make it framework specific, if it can work equally well for all the other stuff?

[00:04:39] AR: Yeah. Make the field of dreams a thing, where build it and they will come. Make it so that anybody can use it and then there we go. Now, everybody else will want to use it.

[00:04:52] EY: Yeah. I think the benefit here is there's also a mission involved in that, we want to encourage people to migrate to more modern practices, native ES modules. Use better authored package formats. Ship to production modern by default, if you can. A lot of these things, you can only achieve by pushing people to adopt new tooling. Because all the existing tools are stuck with these previous assumptions that you have to do things this way. If you change it, people will be mad.

[00:05:36] AR: Yeah. I know at work, we're using Vue CLI. It's doing the modern build. It's also, when you do a modern build, it still does a legacy build. I've been running into some issues with that lately. I have a personal project that I recently migrated to Vite. I realized like, “Oh, it's not dropping in any of the polyfills anymore. This is way lighter. This is nice. Oh, this is good. Okay.”

[00:06:03] EY: Yeah. Yeah, especially if you think about, Jason Miller just recently tweeted about this, about how the browser support scene is actually getting better than we expected, where 95% of global browsers are running baseline ES 2015 now. If, unless you are targeting very specific segments, like organizations that stuck on old hardware and can only use IE. Most end consumer devices like mobile phones, or new laptops, they're all running modern browsers now. This will only improve over time.

Now that Microsoft has completely moved over to edge powered by Chromium, so future Windows devices will now just be modern. I think that makes a really good argument for us to start thinking of our projects as if you are targeting modern, then why transpile in the first place? Dropping the transpile makes your development process faster, leaner. If you really need to, let's make it opt in, so that most of the developers would be targeting model by default. Then if you need to support IE 11, you can have this similar to how Vue CI modern mode, where build tool modern and legacy bundles and let the browser selectively pick the right one. I think it's about time that we flip it over to do the modern by default thing now, for the ecosystem. [00:07:36] T: Speaking of development, I'm curious after working on Vue for such a long time, how your development process was different for making a framework, or library agnostic build tool.

[00:07:49] EY: I guess, the reason I enjoyed working on Vite is because it's a new thing. The thought process doesn't have to be so, so involved, like Vue nowadays. With Vue, the ecosystem is huge and the stakes are huge. If we want to make big changes, we have to discuss it with people first. We have to weigh the decisions in all aspects. With Vite, because it's a new thing, I can be as opinionated as I want.

It's a new area of exploration, where I'm not confined to some of the existing decisions we've made in the past. At the same time, also get to connect Vue to it. It's like, I don't know, it's maybe a strategy for lead Vue developers to also go on that route. Yeah, it's quite different in the sense that Vite is very new, very early. There really isn't too much formal process involved. It's mostly figuring out what we want, listening to early adopters and just shipping what we think is useful.

There are a lot of feature requests. I would say at this point, Vite is still very much shaped based on how I imagined, opinionated, but still framework agnostic and flexible tool is. There is always this very difficult balance point, where on the one end is you make every single thing configurable, like Webpack. The problem with that is obvious, is that everyone has to maintain these very, very, very complex configuration files to get the things work the way they want. All these options and configurations loaders, they interact and the complexity explodes.

If we fold that into the tool, because now people don't get to mess around with it, you can make a lot of assumptions internally, you can simplify things here and there. On the other hand, you don't want to be overly opinionated, say, to the level of a meta framework. Say like, Nuxt or Next is essentially, it goes all the way to how you write your code. It goes all the way to how you structure your code. Vite is not that. Vite is something just sits in between where you probably want to do this in all kinds of projects.

Yeah. I didn't actually realize this until I'm talking about it here. I think, a good way to explain Vite to people is that it's a middle point between Webpack and a meta framework, in terms of scope. It's not as configurable as Webpack. It's more opinionated, but it works out of the box for most common stuff. It's also not as fully opinionated, like a framework, where it dictates what library we use, what code or structure that you use. You can build a meta framework on top of Vite pretty easily. That is what I'm thinking.

[00:10:59] T: That is the main motivation to go with Vite still speed of development, or are there other pluses there too, that we should highlight?

[00:11:10] EY: I think, speed of development is what gets people excited and gets people – it's what people know Vite about. I think, that's not just the only thing that's going on for Vite. I think, as a development tool, it provides this – I would say, it aggregates all these learnings that we've gathered while working on Vue CLI over the years, and figured out like, this is probably what most developers want. Let's make an opinionated, make it work out of the box, so that people don't need to mess around with it. At the same time, also make it really, really fast. That would be a really nice combination. Then let's make it work for all frameworks.

[00:11:58] T: Yeah. My impression for the last few years has been that you keep pretty good finger on the pulse of what's new and the other frameworks and libraries and Vue alternatives. I'm curious if you've had to step that up while developing to ensure compatibility and stuff?

[00:12:17] EY: Yeah. I think, it's interesting, because the only framework that has its really heavy own opinionated tooling is probably Angular. It's really heavy in its own specific things. I think, a lot of it is coupled to Webpack in some way. I mean, I didn't really look deep into it. Surprisingly, most of these other modern front-end frameworks, they are all doing just pretty standard stuff. Vue and Svelte are probably just the only two that has a very custom file format. All the other stuff, like React, Preact, or these other new frameworks is coming out.

I mean, the worst-case scenario, you just write a plugin to compile specific file format and you can get it working with Vite. The idea is the common needs that most frameworks will need is a sensible plugin API, a way to handle hot module replacement. If you have that, and just make everything – The idea here is to try to make the plugin system just work. That's where Vite learn from roll-up, because, while working on Vite’s build part, I realized, “Oh, roll-ups plugin API is pretty nice. It's pretty easy to understand.” Most developers can pick it up pretty fast.

Vite’s plugin, Vite 2 has this plugin system that's a superset of roll-up plugins, where some of the roll-up plugins would just work as a Vite plugin out of the box. This makes it pretty simple for people to, especially if say, a project, or framework. It already has a plugin for roll-up, then it can be easily adapted to Vite. Also, because a lot, most of the stuff is standard. We're just loading things over ES modules. If your framework works for native ES modules, then it will just work in Vite.

[00:14:18] AR: Was the interest in roll-up and using their plugin architecture, because it's a really good plug in system? Or is it because it was already available and you were just like, “Oh, yeah. That works.” Or, what was your decision-making behind that choice?

[00:14:37] EY: Yeah, that's a good question. I think, I've always felt Webpack, while being extremely powerful is a bit heavy-handed in terms of its internal API design. While working on the loaders, or Webpack plugins, it's always a struggle to figure out what to do and where to hook into the system, because it's just so complicated.

At the same time, while I was working on roll-up plugin Vue, I realized, oh, this plugin API is simple, but it's really, really capable of doing almost everything I need. I also really liked how roll-up was a ESM-first bundler, in the sense that roll-up was designed to bundle ESM code, instead of common.js and then ESM. It can directly output ES modules as well. That's an important consideration.

When I was picking a bundler for Vite, roll-up was the obvious candidate, because it's ESM first and that aligns with Vite very much. Then in the process of working on the production bundling, writing all these plugins, I realized, “Oh, this plugin format is pretty nice. If that can be adapted to the dev server as well, that would allow us to ship universal plugins.” This idea actually came from WMR, which is the similar unbundled dev server project that Jason Miller created for Preact.

The Preact team worked on this project, which is in terms of scope, is very similar to Vite. It also had this ESM dev server bundle with roll-up. It first came up with this idea of using roll-up plugins for both dev and production. When I saw that, I was like, “Oh, we are also already using roll-up for production. That seems like a really neat idea.” That was one of the big refactors that went into Vite 2 to make the plugin system work for both build and development. [00:16:42] T: I got to say, it's really heartening to hear that you also have trouble navigating Webpack.

[00:16:48] EY: It reminds me of the days I was trying to figure out how to write Vue loader. It was difficult. At the end of the day, I was like, “Wow, I can't believe this worked.”

[00:17:01] T: Yeah. I was curious, if you could talk a bit more about what you mean by plugins in the context of roll-up and Vite, how that compares to the system, the Vue dev tools, or sorry, CLI?

[00:17:18] EY: Sure. Yeah. Vue CLI’s plugin and the Vite plugin are completely different concepts, in the sense that Vue CLI is already opinionated. It only supports Vue works out of the box. CLI plugins has a larger scope in a sense, it can both add features to your project, and also scaffold a new code. Vue CLI compared to Vite, Vue CLI does a bit more in the sense of scaffolding, and create all these files and then modify the files for you, by adding a plugin. The plugin can also tweak the internal Webpack configuration.

A Vue CLI plugin is something that injects configuration into the internal Webpack instance. In Vite, a plugin is I guess, it's more direct in the sense that you can use a plugin to do all kinds of things. For example, if you do – Vite already provides this alias option. If you want to do a custom aliasing, you can use the resolve ID hook. Say, if a module requested is named Tessa, let's redirect it to something else. You just return a different path. Then you can use the load hook to load something. The load hook will say, “Oh, this is the path that we redirected Tessa from. Now it's Alex. Let's serve this file.” Like, “Hello, I am Alex.”

You just return a virtual file, like export default, “Hello.” You've essentially created a plugin that allows you to say import tester, but it actually gives you a string called “Hi, I'm Alex.” In a nutshell, that's how a roll-up plugin works. It works equally the same way in Vite. Then you can use the transform hook to do transforms. Say if, “Oh, if the file is a TS file, let's do this transform. If the file is a JSX file, let's do that transform.”

Similarly, for Vue, we are essentially just adding this transform hook say, “Oh, it's a Vue file. Let's compile it and do all this other stuff and return the compiled JavaScript.” Yeah. Obviously, the real plugin is a bit more complicated, but the general idea is a Vite plugin is something that works more directly into all these concepts that we can think about. Like, when you import something that goes into the resolve phase. Once it's resolved, and we're trying to read the file, it goes into the load phase. Once the file has read it, before we send it back to the browser, that's the transform phase. Once you understand these three hooks, then you can pretty much do anything in Vite. You can redirect things, serve non-existent files, transforming to all that stuff you want. That's pretty flexible, but also very simple at the same time.

[00:20:16] T: I was curious, if while you were working on Vite, you thought of ideas, or seeds of ideas that you want to bring back into the Vue project?

[00:20:27] EY: In fact, it's pretty well separated while I decided to make it framework agnostic, I realize, okay, Vite core can be nicely separated from Vue. Yes, there are some things in the server-side rendering part where I was – when I was working on the server-side rendering support in Vite, which is now included, I was thinking, “Oh, one of the goals was to make this work for Vue, so that we can use Vite for Vue server-side rendering projects in the future.”

I was thinking, “Hey, if we build something like Nuxt on top of this would be nice.” Then turns out, Nuxt says, “Okay, we can just support Vite,” which is pretty nice. Then we have community members that's building higher level frameworks on top of Vite, say like, [inaudible 00:21:14] already built Reen. He had this previously, but now he just rebuilt the whole thing on top of Vue 3 and Vite. I think it's pretty cool. Probably worth checking out as well. Then, I know there are other people like, in the React ecosystem, there are other frameworks like Svelte, they are building their service I rendering stuff on top of Vite as well. A lot of exciting stuff going on in this scene.

[00:21:43] T: Yeah. Did you expect it to pick up as quickly and broadly as it did?

[00:21:48] EY: Well, I don't know. In some way, I'm always struggling with myself in the sense like, if I popularize it too much, then I get a lot more users, a lot more issues, a lot more problems to fix. At the same time, it's like, this is cool stuff. More people should know about it and more people should use it. I think it will make people's work experience better. Yeah.

Overall, I think we're doing pretty good. I think we're seeing a lot of people talking about it, using it. There's also a very active community on Discord already building up. I'm excited to see all these cool ideas that's being built on top of Vite. I think we're going to see it later this year.

[00:22:36] T: Is the version change from one to two, because it went from being something for Vue to something being framework agnostic, or why such a big jump in the numbers?

[00:22:47] EY: Yeah. The funny story is, we already went into 1.0 RC in the 1.0. We got stuck in the RC, because I just felt we're not there yet. It doesn't feel like, while we are working on RC, we keep coming up with this idea, “Oh, what if we do this? Oh, what if we do that?” Then I realized it would be super weird to ship such major changes in a RC increment. Going from RC 9 to RC 10, you essentially rewrote the thing. That would make sense.

I’m like, “Oh, maybe we should just scrap it. 1.0 is dead. Let's just cart to 2,” so that people know, okay, we actually made these really big changes. It's funny, because as I'm working on Vite, I always have this file open to do. I have a list of things that I think we should have. Then at one point, I feel like, “Okay, we're good. Let's go into 1.0 RC.” Then the list suddenly starts growing. I'm like, “Wait a second. This doesn't look right. It doesn't feel we could actually sneak all the stuff into RC releases.” Does that make sense? Ended up being a 2.0.

[00:24:01] T: Where does 2.0 leave Vite Press? Is that still happening?

[00:24:07] EY: It's already running on 2.0. The migration was actually pretty painless. Did it in 30 minutes, surprisingly. Vite 2 was in fact, a complete rewrite. The whole architecture changed. I mean, retaining some of the good stuff, the idea has remained the same, but the whole implementation was completely rewritten from the ground up. Then, when I went to migrate Vite Press, I guess the good part is as a tool with a plugin system, or the parts where Vite Press interacts with Vite is somewhat limited. Most of the Vite press specific stuff was left intact.

Only the part that interacts with Vite needs to be updated. That was a single plugin. It's like a 100 lines of code. Then some code that adjusted how to use the build API. Because of the experience of building Vite Press with Vite 1, that informed a lot of the API designs changes in Vite 2, because I was realizing like, “Hey, if we change this API to just work like this, it would make Vite Press so much easier. In fact, I think Vite Press when migrated to Vite 2, actually got simpler in terms of the integration part. It's already running on Vite 2, so I'm pretty happy about it.

[00:25:23] T: Yeah. I think previously, I had thought of Vite Press as the potential successor to Vue Press, but on Vite. Is that still an accurate summary, or have things changed?

[00:25:35] EY: I think it has all the capabilities to do that. It's just, we are currently – I don't currently have so much time to completely invest into making it, to bring it to full feature parity with Vue Press. I believe, eventually, it probably will. In some way, Vue Press has this plugin system, which turns out, Vite Press can simplify, because it's running on Vite. If you add a Vite config file in a Vite Press project, it just pick it up, so you can directly configure your underlying Vite instance in a Vite Press project, which I think is pretty powerful. Running with a plugin that transforms markdown files into a few components. That's pretty much it.

[00:26:24] T: Maybe this is a silly question. Is it possible to use Vite Press in a Vue project, or Vue Press in a Vite project? Or would that be tough?

[00:26:34] EY: I mean, I don't see a reason why you cannot. Should just work. Running Vite Press alongside a Vue project is totally – it's something you would definitely do, I guess. In fact, Vite builds its own docs on Vite Press. I guess, that's not the direct equivalent to what you're asking. I think a lot of people are already using Vite Press in their Vue 3 projects for documentation. I believe it should just work. Yeah, I think the documentation for say, router four and Vuex are both already – Vue 3 compatible versions are already running on Vite Press.

[00:27:15] T: Where does that leave Vue Press? Is it a project that will continue to grow, do you think, or you don't really need it?

[00:27:22] EY: Vue Press has its current ecosystem and community. I think in the long-term, I would hope for people to start migrating to Vite Press in the sense that in the short-term, I don't want to declare that Vue Press is dead, because obviously, it's not. If you're starting a new documentation site and you don't have very, very strong customization needs, or reliance on existing Vue Press stuff, then I think Vite Press will be the better choice. In a sense, it's lighter and faster. It's also based on Vue 3. The thing is we have some community members, some team members working on a Vue Press Next. That complicates stuff. The thing is, it's always tough to say this old version is no longer relevant, because there are differences, right? It's not a direct replacement. There are different design decisions involved. Although, these design decisions probably only matter if you are using it in a certain way. It's always tough for us to say like, you should not use something. Still, if you're starting a new documentation site, definitely check out Vite Press and just feel it, compare it to yourself, see if it fits your needs.

The thing which I don't want to say like, this will be the next Vite Press, is because I don't want it to inherit all the existing design decisions from Vite Press. There are a lot of similarities, right? The same way that you write markdown files, the same way it pre-render stuff. At the same time, I don't want to want it to inherit all the how the plugins work, how the things work. If you say this is the next Vue Press, people will be expecting like, “Oh, this used to work in Vue Press, now doesn't work in Vite Press.” If it's something different, then it makes sense for them to be doing.

[00:29:18] AR: Vue Press is not dead, but it will continue to live on alongside Vite Press, because they have similar features, but they are differing products and have different reasons.

[00:29:31] EY: Yeah. They have different opinions on how you customize the project. Vite Press intentionally keeps the API surface very minimal. You need to be a bit more diligent in understanding the internals, understanding how it's actually just the Vite server with some special configurations. If you want to customize Vite Press, you probably need to know how Vite works, how Vite plugins work. If you already know how to work with Vite, then it will make it much easier.

On the other hand, Vue Press is pretty much its own thing. It has its very significant API surface as plugins. Vue Press is just a bit more heavy-handed in how plugins work with it. Vite Press is intentionally minimal. We don't want to ship all these plugins stuff. Just tweak it in a bare metal way if you want to. Otherwise, just use it as the default.

[00:30:30] T: It sounds like the migration from Vue Press to Vite Press if you wanted to switch would be manuals, is that right?

[00:30:37] EY: Yeah, unless you're using heavy plugins. If you don't use a lot of plugins, it should – especially if you're just writing markdown files, then it should just literally be a drop in replacement.

[00:30:48] T: How about from Vite 1 to Vite 2? Is that also a pretty smooth migration?

[00:30:53] EY: It's pretty smooth, because most of the public-facing, the source code handling stuff is almost the same. I mean, we didn't have that many users in the 1.0 phase anyway. I don't think that's going to be a huge problem. Most users who are all 1.0 are super early adopters, and they are pretty comfortable navigating all this stuff.

[00:31:15] AR: Yeah. Since it never really hit 1.0 proper and was always just released candidates, you didn't pick up very many people.

[00:31:22] EY: Yeah. People who are using it in those days aren't just really tech savvy people. They dig into source code. They actually figure out how things work. Yeah, 1.0 to 2.0 is probably a piece of cake.

[MESSAGE]

[00:31:39] T: Hey, Tessa. Your new PB and J topping selector website is really blowing up. I wish it came in a mobile app version, so I didn't have to bring my desktop to my kitchen every single time I'm hungry.

[00:31:53] T: Tell me about it. I don't know the first thing about mobile. I'm a Vue developer through and through. Oh, well.

[00:32:02] AR: Are you telling me you haven't heard of Ionic?

[00:32:06] T: Ionic?

[00:32:07] AR: It's a mobile app development platform that empowers web developers to easily make native mobile and progressive web apps, all in Vue.

[00:32:17] T: That sounds too good to be true. How do I know if I can trust it?

[00:32:23] AR: Well, Ionic is the technology behind about 10% of the world's mobile apps, including ones from Home Depot and Target. It's also open source, so anyone can contribute.

[00:32:34] T: Nice. What if I need help?

[00:32:38] AR: Well, Ionic’s got you covered there, too, with their premium tools and services.

[00:32:43] T: Wow. That sounds almost as smooth as my favorite brand of peanut butter. I'm no good at design. Don't Apple and Google have super stringent standards on mobile user experience design?

[00:32:58] AR: Well, that's the best part. The Ionic Vue library comes with over 100 native components and utilities, including animations and icons. You don't need to design anything to get started. Capacitor will take all your JavaScript and package it into a stunning mobile experience for you.

[00:33:18] T: Amazing. How do I get started?

[00:33:20] AR: At ionicframework.com/vue.

[00:33:25] T: I can't wait to make everyone jelly of my new PB and J mobile app.

[INTERVIEW CONTINUED]

[00:33:36] AR: Are there plans and I may be asking a big question of this, but are there plans to make Vite the default way of doing things in Vue CLI?

[00:33:48] EY: Yeah. Here's the thing, because Vue CLI is in terms of scope, it covers more capabilities than Vite, because it also scaffolds stuff. You add something, it modifies your code, generate new files. I think that part will probably stay in Vue CLI. The thing is Webpack fundamentally is just something different from Vite. While we can provide limited source code format and compatibility between the two, like say, if you didn't customize anything, you just started a very, very standard plain project with completely standard usage across the project, then it should theoretically be a drop in replacement.

The thing is, most non-trivial projects will involve something like, people will inject custom webpack loaders. They will use custom Webpack plugins. They will do this and do that, which makes their configuration, their set up coupled to Webpack. This will be difficult, because these are two fundamentally different things. I do believe for beginners, especially, for new users, for beginners, for small to medium projects, it just makes sense to start with Vite, because it's simpler. It's more directly to the point.

Vue CLI in the sense, is more production, serious, enterprise, where you want a very, very integrated solution, you want scaffolding, you want all the opinionated stuff picked out for you, then you want to be able to get a test runner going by default. You want all that stuff. I think in the long run, we will probably build these company tools. Scaffolding isn't really coupled to how the dev server, or the production [inaudible 00:35:41] work.

We can maybe find an existing tool, or then combine it with Vite. Then we figure out the testing story for Vite, which is still something we're working on, how to get Vite code to run smoothly in say, Jest, or how to integrate with Cypress, or other end-to-end test runners. These are the part of the work that already exists in Vue CLI, which is just out of scope for Vite, because that's not what Vite is trying to achieve.

In the long run, I think we will probably have – it's totally possible for us to build something that is equivalent in scope with Vue CLI, but using Vite under the hood. I think that's going to be the sensible direction for us to move towards in the long run. I'm not a 100% sure how we would say, position it as say, this is the new Vue CLI, or it's just something different, completely did with a different name. Because Vue CLI now is coupled to Webpack. People assume, “Oh, this is a Vue CLI project, then I can use all these Webpack related stuff.”

If we just suddenly one day say, “Oh, Vue CLI is now a Vite-based thing.” No longer works other Webpack stuff. I think that's going to be creating some confusion for the ecosystem, because people will be googling about Vue CLI and they say, “Oh, just add this Webpack plugin.” Wait, this new version is working on, running on Vie. It doesn't work that way. I think, this is something we have to consider. Functionality-wise, definitely, we will have something that's similar in scope with Vue CLI, but on top of Vite. We're not sure if it should be called Vue CLI.

[00:37:26] T: How do you balance your time and mental space between developing on both the Vue and Vite?

[00:37:34] EY: It's tough. It's probably the toughest problem for me right now. Context, I hate context switch. I'm really bad at multitasking. When I'm focusing on technical problems, especially hard ones, I like to be able to just go in the zone and forget about everything else. If I'm working on say, Vite, I can't just juggle with fixing Vue bugs alongside the way. My brain just doesn't work that way, because the context switching would be so expensive. It would take me a day to jump from a Vite context back in Vue context and vice versa. Unless, I'm fixing some bugs that touches both at the same time.

Yeah, and similar to what I've been trying to do when juggling between, say, Vue or router, or Vuex is just to focus weeks, like focus on this thing for a week or two weeks. Then switch back. I don't know how that would work in the long run, because Vite is still a new thing. It's also a recent decision to make its own thing outside of Vue ecosystem. Because initially, it was just supposed to be this experimental new stuff for Vue. Now, it turned out into its own thing.

I think, one of the goals I want to achieve is to probably build up a community and build up, maybe a build up a team for Vite, so that we have people working on Vite and taking care of it, while I juggle between the two projects. I think there are already people, very active community members helping out on the Vite repo. I'm really appreciative of them. We're in this phase where we are just out of 2.0, a lot of new users coming in, a lot of new issues coming in. It's a chaotic phase, where we just need to watch it burn for a few days and see if there's really anything that's urgent and need fixing.

Probably, it'll quiet down over time and then we can – because Vue 3 is obviously, going to be the more heavier focus for me overall. I think Vite in terms of scope is more manageable in the sense that with a tool like that, it's mostly edge cases. There will always be bugs, but it's just – it's not yet at the scale of Vue yet, because Vue has over a million users and Vite maybe has only a couple 1,000. I don't know. Maybe 50,000. I don't know.

Compared to Vue, the workload on Vite is so somewhat okay, if we build up more committee members to help triage the issues, can contribute PRs. Maybe even build up some maintainers to just handle the daily patch releases. I think that would be in a good place for me, so that I can just overlook the higher level decisions and only tune into specific serious issues when I really need to. Then move most of my focus back on Vue.

[00:40:47] T: Yeah, that makes sense. As someone who also detest multitasking, I'm really glad to hear that there are other people like me in the world, because I feel like so much about context switching in tech is more focused on like, “I'm really good at multitasking.” I'm not.

[00:41:02] EY: Yeah. I feel like, multitasking is, in some way, it's almost like, you're tricking yourself into I'm doing a lot of stuff, while I’m not actually doing a lot of stuff. I feel like when I'm multitasking, I feel like, “Oh, I'm doing this. I'm doing that. I did a lot of things today.” When I look back at it, it's not as productive as what have been deep focus in solving hard problems. Those are different work modes, I guess. Sometimes I would do this chore day, where I just reply to emails and do all these things that I've procrastinated on for a very long time.

[00:41:39] T: Yeah. I mean, speaking of doing hard things, I'm curious if when you set out to build Vite, were you like, “I already know all the things I need to know. This is going to be a walk in the park,” or did you have to learn stuff to build it? What did that development process look like?

[00:41:55] EY: Definitely had to learn a lot of stuff along the way. The initial idea of Vite actually started out almost two years ago. There's a proof of concept called [inaudible 00:42:08]/devserver. It's actually still on GitHub, but archived. That was the initial hacky prototype, where I was like, “Hey, what if I have an HTTP server that in the request handler, I see oh, this is a request in the Vue file, then I compile it on the fly and send it back to the browser and the browser just loads it over native ES modules.”

That idea came about like, more than two years ago, when I first learned about Native ESM support in a canary version of Chrome. I got that PLC working. I was like, “Wow, this is cool.” Then I realized, if I want to actually do something like Vite today, then I need to solve these – how to resolve to NPM node modules, how to resolve these package entries. I had to build a bundler. There's a lot of things that I didn't really know back at that time. That stayed a proof of concept. Until later. I don't know how, but one day, I was coming back to this idea. I was like, hot module replacement. How do we crack it for ES modules?

I sketched on paper. I was like, “Oh, maybe this is just how it can work.” Hot module replacement over native ES models. Let's combine it with that Vue file server thing that I had in the jar. Then we have something really cool, right? That's when I started actually, start working on Vite version one. Then while test running version one, testing out a lot of different architectures, switch server implementations and all this stuff. Finally going into RC and then realize like, “Oh, we should just do it completely different this way.” Which led to the 2.0 rewrite.

This whole process is just a constant discovering new ideas, trying it out, realizing it doesn't work, then try something else. It's never going to be a straight-line process. Unless, you're just working on some really well-defined problems, right? Because when you're creating something that's new, you can only find semi-references. You're like, Vite is something that combines a lot of small problems. It's a coherent, big solution. I guess, the process is figuring out the most core part, then break down the rest into manageable little problems. Then when I'm looking at those problems, some of these will have existing references. Like say, “Hmm, this problem? I mean, Webpack probably has to solve it. Let's see how it does. This problem, roll-up probably has to solve it. Let's see how it does it.”

Once you go into very concrete, small problems, you have all these existing projects that you can reference. Figuring out how the project as a whole should fit together is always iterative process. It's very hard to get it right on the first try. It's almost like, you're drawing something. You always get out of structure first, then go into the details a bit. Then you like, “Oh, I need to move this a bit, move that a bit.” Then maybe you have to just scratch, scrap it and just, let's start over.

I don't think like, for any software of scale, it's difficult to plan everything out on first try. Especially if it’s a new thing. High-level architecturing is also a bit different, because you're essentially just putting pieces together, just you know that already works well together to solve a specific problem. For Vite, it’s like, we don't even know if this would work. We have to try it. Try it first and then figure out how to go from there.

[00:46:03] T: Yeah. I feel like, I can tell you’re really experienced by that drawing metaphor, because most beginners would start with some very small detail and get it perfect first and then move to the next small detail.

[00:46:15] EY: Yeah. Because I used to do studio art in college. I'm an art history major. I also draw a lot. I guess, that translates a little bit into how I do software development. If I'm doing something, I always try to ask like, what is the hardest problem that I need to get right first? Once you figure that out, all the rest is just filling in the details. To get that first thing right, you have to try a few things. Be as hacky as possible. Just like, once you validate that core idea, everything else will fall in place. Until you have that click, you have to try this, try that, try a lot of different things.

[00:46:59] T: Yeah. After you've tried everything, how do you go about designing the API, so that it has a really friendly developer experience?

[00:47:08] EY: I guess, that has to do with how you position yourself as how a designer would have to imagine oneself as the consumer, as the end user. Put yourself in the shoes of your user. If I am using my own tool, how I would like it to be? I think that's a very simple question to ask. It's always difficult for you to actually change your mindset, because as developers, we're so deeply involved in what we're working on. We always assume a lot of context. I say, when you’re reporting issue, a lot of people just say, “Hey, I ran into this bug.” Without all the context around it, it's really hard to figure out what this bug really means.

It's similar, like when we are designing API's, I think it's important to take a moment and cut off all the contacts that you have when you're working on it and assume like, “Oh, I'm someone completely new to this thing. I don't know anything about Vite internals. How could this thing make sense for me?”

When designing APIs, I think it's important to be able to change your mindset and just assume you're a complete outsider, and then to look at it from a different perspective. It's difficult. It's not always easy to do, because even when I tried to do that, sometimes I would assume like, “Oh, every developer knows this. Every developer knows that.” Turns out, some people just don't. If they don't, they will find something confusing. It’s always, they will be seeing certain things that you will learn only when people raise an issue to tell you about it. Just try to do it as much as possible. I mean, I guess I've accumulated a bunch of experience over the years answering people's questions and issues and stuff.

[00:49:10] AR: I guess, I have a question about, you have the Vue RFC process for new features, new things in Vue. Are you planning on any Vite RFC process for new features and new things in Vite?

[00:49:29] EY: Yeah. I think, we are still – Vite is really, really early. It's literally a new project. Up to this point, the decision process is pretty arbitrary. I think, now that we are 2.0, I guess it would be good idea to just move it towards more community-driven and start proposing big, new things, so to get people's feedback. That will be a good start. I don't know if we want to go the full RFC route yet. Because I feel like, RFCs are, I don't know, when you have a big enough user base. I don't know. Honestly, maybe it's worth it. Maybe not. For now, I think we can start with something like simple proposals. Maybe it doesn't have to be as formal as RFCs. Or maybe, RFCs are just not as involved as I thought. I think that would be good idea to try it out. Either way, yes, I think we should start having, I guess, a formalized, or structured feature addition process to Vite.

[00:50:39] T: Maybe your new project is going to be a lighter way to submit ideas with that in RFC.

[00:50:46] EY: Just, people just do that and get up issues anyway.

[00:50:50] T: Oh, that's true. Are there any big changes from one to two that we haven't covered yet? Or any other topics you want to talk about?

[00:50:59] EY: Yeah. I guess, the pre-bundling stuff. What makes people realize like, “Oh, this is blazing fast.” It’s how we switched to using ES build for the dependency pre-bundling. This is an internal change that doesn't change how you use Vite. It just makes everything faster. To explain it involves – we have to go all the way back to, because Vite is a – ES dive server, it serves everything over native ESM. When you have a lot in a lot of modules, they translate into a lot of HTTP requests. Because HTTP requests have overhead, ideally, you want to reduce the number of requests, if possible.

For your source code, that's inevitable. For dependencies, some dependencies like [inaudible 00:51:49], when you import it, it contains 600 modules. That can make your page load a lot slower. The idea is we pre-bundle it into a single file, so that when you're loading it during development, it's only a single request. The reason we could do pre-bundling is because we only need to do that when your dependencies change.

Your dependencies change very infrequently once your project stabilizes. Your source code will probably change every hour, but your dependencies may stay the same for days, or even months. If we separate the two concepts, and say, let's still do bundling to speed up the dev server load speed, but we only need to do it whenever the dependencies have actually changed.

Good thing is all these package managers, they have lock files. We just look at your lock file and say, “Okay, your lock file did not change, so we don't need to pre bundle the dependencies.” Now, Vite 1 already did this. The thing is, when it has to do it, it's still slow, because it uses roll-up to pre bundle all the stuff. Pre-bundling is one thing. Also, it also handles the process of converting anything that is common.js, or UMD, into actual ES modules. That process can take similar to how Webpack startup times, when you have heavy dependencies and design, or material UI, or stuff like that. Huge UI libraries, usually, can take a couple seconds to evolve.

[00:53:32] AR: Just the length, two seconds. So long. Oh.

[00:53:37] EY: Two seconds. I mean, sometimes I've seen projects with 20 dependencies, with hundreds, or thousands of dependency modules. It'll take 30 seconds for roll-up to even bundle it. You don't want to incur that cost every time say, I bump a version of a dependency and have to go through this again. We switch that to ES build. In order to do that with ES build, obviously, we had to run through all these kinds of wild, different packages, how packages decided to ship their entry points, how packages decided to ship weird formats, conflicting formats, like two packages, one is importing this A package and the other is requiring it.

All these edge cases, we fixed them, most of them. There are probably still a lot of them out there. We fixed most of the common ones and we finally got to the point where we are using mostly, ES build to handle this pre-bottling process. That bumps are previous. I have these test projects, the one that used to take 30 seconds to pre-bundle, now it takes 1.5 seconds. That's 20 times faster.

It's a whole lot of different experience when you have to – every time you start your project, you're like, let me just get go get a cup of coffee, then come back. Now, you can just, whenever I want to. I just start it. I don't have to leave my desk.

[00:55:09] T: No coffee for anyone.

[00:55:11] AR: Yeah. No coffee. This may be too big of a topic to discuss here, but how do you pick what to bundle as a dependency? Do you just look at package.JSON and say, “Okay, anything that's in the dependencies section, go bundle it?” Or are you actually doing – Are you looking through my source code and being like, here are the things?

[00:55:35] EY: Yeah. This is actually an interesting challenge. In the early version, what we did was we use your package JSON as the source of truth. Anything inside dependencies will be pre-bundled. Anything inside dev dependencies will be ignored. This will require you to always be careful about the dependencies versus their dependencies thing, which is not ideal. Also requires you to explicitly include, exclude a lot of stuff.

Most importantly, this strategy doesn't work well with deep imports. Some packages, they ship these deep imports, like I say import it from foo/bar. This is a nested file inside a node package. The thing is, when we are only looking at the package.JSON, we only know the top level dependencies. If we only bundle them by using their entry points, then at the runtime when you request a deep import, it's not actually – that deep import doesn't have a corresponding ES module file. The resolver will actually grab the original source file and results in duplicated copies of the module.

This has created a ton of problems. We decided to switch to this scanning model, where do look at your source code to find out all the imports. In order to find all the imports, essentially do a crawling phase of your source code whenever we rebuild our dependencies. We do that with ES build as well, so it's also blazingly fast. Essentially, we are pre-bundling. We do two ES build runs. The first run scans your source code, walks in and on every found import, it will check if it's a no dependency. If it is, it'll add it to a list of the dependencies we need to pre bundle. In the second phase, we bundle all of these as a multi-entry bundle together.

Each found import gets an entry file, and then save all the information into a metadata JSON file, which is then read by the dev server. Now, the dev server, whenever a request comes in, the dev server will check if this is a pre-bundled entry in our metadata, if it finds a corresponding one, it will then redirect the request to that pre-bundled file instead. Yeah, there's a lot of pretty complicated stuff going on there.

[00:58:19] AR: Yeah. That sounds very, very complicated. Very exciting, cool things happening in there, though. Awesome.

[00:58:30] T: Yeah. Any last questions, or things we want to talk about?

[00:58:35] AR: I mean, I can always bring up the controversial question. When are we getting a migration toolkit for Vue 3, from Vue 2 to Vue 3?

[00:58:44] T: Oh, that you’re going to say release date.

[00:58:46] EY: Yeah, that's going to be – This is still going to take a while, because obviously, we spend quite a bit longer than the – on Vite than we hoped. The whole 2.0 process was essentially added on. Because originally, we were planning to call it 1.0 and be done with it. It turns out, there's just so much things to gain from the 2.0 refactor. It ended up being a whole two months-long project. I think it's going to be worth it. It's going to be making all Vue devs and maybe even other framework devs’ lives better in the future. I think, it's a worthy investment. As I mentioned, now my goal is to set up a community and team structure for Vite, so it can take care of itself in the short term, while I focus back on Vue. Yeah, so the migration stuff is obviously, the thing we're going to be mostly working on next.

[00:59:50] T: I guess, I have two questions. My first question is, what are your thoughts about using only composition API and no Vuex? If you ever listen to music while you're coding, what kind of music do you listen to?

[01:00:08] EY: Using only composition API without Vuex is totally viable, if you don't – I mean, especially when we still don't have dev tools integration for Vuex Next yet. Especially for simple projects. Vuex is somewhat of a mix between state management and data fetch caching at the same time. With competition API, there are some different patterns that you can use, something like in Red Hook Swirl, there's SWR and React Query. I think they're already equivalent using Vue composition APIs. In a lot of cases, you probably want something more towards a data fetching, plus cache and plus share state solution, rather than something we call state management.

State management is something – the term state management entails there's a structural benefit. There is a convention benefit to it. You are intentionally writing more structured and verbose code in return for predictability. That's what Vuex is involved around. For a lot of projects, people maybe, we don't care about this being more verbose stuff. We just want to write simple code. We still need to deal with fetching some data, saving it somewhere and then being able to use it in multiple components.

This is a common problem that almost every project needs to deal with. With composition API, I believe, it's pretty straightforward to do that. Obviously, there are problems involved when it comes to server-side rendering. What we hope is the value of Vuex, especially the next version of Vuex is that it provides you with this – first its structure convention. The second is you know when you use Vuex, you have all these associated best practice for SSR handled for you as well. If you just write idiomatic Vuex code, your stuff will just work. You don't have to worry too much about it.

If you're doing something completely custom, you might have to worry about, “Oh, will this work, the server-side rendering? Would that work?” I do believe the necessity of Vuex is reduced, especially in small projects for Vue 3. If you can handle your case with just composition API, then I would say, that's totally fine.

I listen to a lot of different things, to be honest. Yeah. I could probably say this to the pick, but there is an artist that I really like recently. Name is Lexie Liu. Lexi is L-E-X-I-E. If you Google her, she just recently dropped a new EP, I think, which is really cool. I listen to it while I was working on Vite. Yeah. The other times I would listen to some cafe background music, slow jazz piano is my favorite. Bill Evans is an artist that I cycle a lot. [01:03:20] T: Very cool. With that, where can people find you on the internet?

[01:03:26] EY: My Twitter handle is @Youyuxi. That is my Chinese spelling of my Chinese name. GitHub, I am YYX990803, which is my middle school student number. A lot of people ask me that question, so I have to explain it. Yeah. Yeah, that's two of the places that I'm most active on.

[01:03:53] T: Great. I hope all the listeners memorize that. If you didn't, there will be links in the show notes. Now, it's time to move on to this week's picks.

[01:04:02] AR: I ran across the thing this week that I am both extremely excited about and mildly embarrassed about. They have come out with a thing called Fruity Pebbles Crisps. They are little circular rice cake things that are fruity pebbles as a potato chip, essentially. They're amazing. They are as glorious as you would expect them to be, like full of sugar and just delicious fruity pebble taste. They are also horrifying, because you're like, “Why does this exist?” I found out about them. An hour later, I had a bag of them, because I was just so excited that they existed. That is the pick that I have this week.

[01:04:58] T: Also, fascinated they call them crisps and not chips. Are they making fruity pebbles biscuits next?

[01:05:04] AR: Yeah, I don't know. I don't know when they have them in another flavor. They have coco pebble crisps and they have honeycomb crisps and they have –

[01:05:12] T: Are there cookie crisps?

[01:05:14] AR: Yeah, I think so.

[01:05:16] T: Oh, that’s weird.

[01:05:17] AR: Yeah.

[01:05:18] T: Okay. Evan, what picks do you have for us this week?

[01:05:21] EY: I just recently tried a game called Curse of the Dead God. I've actually been playing another game called Hades. I don't know if people have heard of it. Hades is –

[01:05:34] T: I’ve seen your tweets.

[01:05:36] EY: Yeah. I've been competing in it.

[01:05:40] AR: Yeah. I mean, I don't think anybody on this podcast has ever played Hades before ever. You're probably the first person.

[01:05:46] T: I'm actually the only one who hasn't played it.

[01:05:48] EY: I hope some of the readers.

[01:05:50] T: Sorry. Go ahead.

[01:05:51] EY: Nice. Yeah. Hades is a rogue-like, but it's an action rogue-like. You run around, hack and slash. Every room is randomized, so you don't know what's going to happen next. Every run is different. Hades is a pretty fun game. I've been competing with [inaudible 01:06:09]. He's a React core team member. Now, I think he's working on React Native. We've known each other on the internet for a long time.

He's a pretty hardcore gamer. We actually talked about our crazy World of Warcraft days in the past, but he's super hardcore. Anyway, we've been in this little speed run context for a while and it's been pretty fun. Hades is a highly recommended game, but it's probably quite popular already. Then recently, there's another one called Curse of the Dead God. It’s also an action rogue-like, but it’s a bit. It's a different combat style. It's also pretty cool. It's also extremely hard. Pretty hard. It's almost like Dark Souls, but in their rogue-like, Diablo-like setting. It's pretty cool.

[01:07:06] T: All right, and I guess that brings us to my picks. My first pick is, So You Want to Talk About Race by Ijeoma Oluo. It's actually a pretty short read. I finished it before minor feelings, which I mentioned a couple weeks ago. A bit more prescriptive, like minor feelings is more experiential. If that sounds interesting, check that out. I also had to clean my room recently and rediscovered that I own a copy of this anime called Birdy, the Mighty Recode, which came out a while ago. I was surprised how much I enjoyed it. I'm looking forward to re-watching it.

Another ancient pick, a friend of mine on the show before Felix, he had this childhood dream, or maybe college dream of becoming an expert in this super old game called Paneled Upon. It's available on Nintendo Switch for online co-op, through the Super NES collection, which is free. It's basically competitive Tetris, or any of those other line building puzzle games.

My final pick, it sounds really silly, but I got a electronic soap dispenser on a whim, because it had a character I really liked, Ryan from Coco. I guess, I never realized how much energy and joy it sucked out of my day to have to push the pump on my old foaming soap dispenser. Now that I just put my hand under, it gives me soap. I feel so happy every time.

[01:08:34] EY: Yeah. My wife got one too, but the battery goes – it just malfunctions so often. We ended up going back to the manual. I guess, we need to find a better one.

[01:08:45] T: Oh no. Yeah, I guess if mine lasts for a month, I'll let you know and we can check it out.

[01:08:51] EY: Okay.

[01:08:53] T: Yeah. Then just wanted to follow up on a couple of old picks. We had debated on the show whether a certain sticker maker went by Sosplush. Or Sosplush. I have confirmation. Alex is on the edge of his –

[01:09:08] AR: You told me. Yeah. I am on the edge of my seat.

[01:09:11] T: Sosplush.

[01:09:14] AR: Sosplush?

[01:09:15] T: Yeah. Also, just wanted to update that the wooden hairbrush is still working out very well. It's probably the longest streak of enjoying a hairbrush that I've had.

[01:09:24] AR: I probably need to get one of those.

[01:09:29] T: I see you also have hair, Alex.

[01:09:31] AR: I do. I have hair. It is on my head.

[01:09:35] T: That's all for this week's episode. If you aren't following us on Twitter, head on over and find us @EnjoyTheVueCast. Please be sure to subscribe to the show, if you aren't already. If you have time, leave us a review. Finally, remember to tell at least one friend what you found interesting about Vite. Thanks for listening and until next time, enjoy the Vue.

[01:09:57] EY: Bye.

[END]