One Year Into Vue 3

Hello, everyone. Evan here, and thanks for tuning into Vue.js Live. Today, I'll be talking about what's been going on after one year of Vue 3's release, what has changed, what was shipped, and some of the lessons we've learned along the way.

And most importantly, I'll also talk about what's coming next. Vue 3 was released on September 18th, 2020. It's crazy to think that it's been out for over a year already. Over this past year, we shipped another two minor versions, 3.1 and 3.2. 3.1 was mostly focused on the migration build, and 3.2, which we'll talk about a bit later, shipped a ton of new improvements. And in between that, we had 52 patch and pre-release versions.

Today, Vue 3 has crossed 1.2 million downloads per month. But many of you are probably wondering, why haven't we switched vuejs.org and npm tags to default to Vue 3 yet? The short answer is, it will happen very, very soon. The longer answer is, well, it was planned, but only to some extent. When Vue 3 was first released, we knew it wasn't ready for instant mass adoption, most notably, some core libraries were still in beta, the new DevTools extension wasn't ready, and IDE support and the tooling story were both lacking. In addition, major ecosystem projects like Nuxt and Vuetify also needed time to come up with a Vue 3 compatible version. So we intentionally opt for a soft launch strategy. This would allow early adopters to start using Vue 3, while giving us time to stabilize core and give the ecosystem the time to catch up.

But we have to admit, this soft launch took much longer than we had hoped. Here I'm going to be completely honest and discuss some of the lesson that we have learned. The main issue that caused the ecosystem around Vue 3 to move slower is the breaking changes between Vue 2 and Vue 3. Because of breaking changes, it was challenging for existing projects to migrate. With fewer end users moving to Vue 3, library authors also had weaker incentives to upgrade their libraries to support Vue 3. And because many libraries did not support Vue 3, end users were unable to upgrade their projects. So, you see we're in a kind of deadlock here. This was addressed to some extent via the migration build. But it was also shipped a bit late, right? It was shipped in July 2020, July 2021. So much later than we had hoped. In an ideal world, we obviously wanted to make Vue 3 100% backwards compatible. However, in reality, it involves some extremely difficult trade-offs. Imagine reengineering a propeller into a jet while it's flying. Well, maybe that's a bit too exaggerated, but let me dive a bit deeper into this.

What kind of updates do we consider major? Note that I am not talking about a SemVer major. I'm talking about something that we typically only do to a framework maybe once every few years, right? The common reasons for such major updates include, first, to correct architectural design flaws. Second, to introduce fundamental new capabilities, and three, to shed technical debt of the existing architecture. Note, these usually involves mass refactoring or even ground-up rewriting, which was the case for view three.

The common traits of these core reasons are that they are extremely expensive to do in an incremental fashion, right? Because some of the issues are rooted in the architecture and without overhauling the architecture, some of the improvements were simply not possible in the first place. So, doing such big updates while retaining fully backwards compatibility is sometimes just prohibitively expensive to do, right? Why, because full backwards compatibility is a burden that compounds with every major new change introduced. The more ambitious the new changes are, the more technical debt will incur during the process.

In the long run, it will make the process even harder, adding new features, much harder. And most importantly, it becomes more and more costly to maintain software in the long run. Now on the other hand, we can reduce the scope of changes in order to make things more feasible, but this also results in less ambitious improvements, fewer possibilities explored and potentially stagnation. So it's almost like there are a bunch of knobs that you can try to turn, but when you turn one of them, the other ones will move in reaction to the one you're turning.

So, here I visualized some of the factors that we have to consider while doing major updates into four knobs, right? These are backwards compatibility, how easy it is to upgrade, the cost to implement and maintain the changes and maintain it for the long run, and finally, the level of improvements these changes can bring about. So, in the case of Vue 3, the example is if we turn the backwards compatibility to 100%, this will make it extremely easy to upgrade, but it'll also significantly increase the implementation and maintenance costs. And if we try to push the scale of improvement up to 100% at the same time, it will drive up the cost to nearly infeasible scale. Now, if we turn the compatibility knob down a little bit to 90%, we can now have both reasonable cost and somewhat major improvements, but user upgrade will suffer, right? It will become more difficult to upgrade.

This essentially sums up the trade-offs that we have opted for in Vue 3, right? We tried to keep the majority of the framework concepts and APIs intact while introducing new capabilities. So the API is 90% compatible, it's not 100% compatible. Most importantly, some of the internals have changed, right? But we were able to bring major updates in almost every aspect from performance to bundle size to internal architecture, long-term maintainability, TypeScript integration, right? It's an improvement across the board. Unfortunately, we also had to introduce some of the small breaking changes. Many of the public API changes are now covered in the compact build. However, some of the exchanges are more fundamental, for example, the switch from using ES5 getter-setters to proxies for the reactivity system or changing the underlying virtual DOM format. These changes were necessary for the level of improvements that we were aiming for. However, they also made it more challenging for existing projects to upgrade, especially apps with external dependencies that rely on Vue 2's internal behavior. This is the biggest blocker that we have seen in practice.

Now, I'm not trying to look for excuses by talking about all this. Looking back, we probably could have done some things a lot better, especially with the breaking changes to make the upgrade process smoother. We could have introduced a compact build earlier and we definitely should have worked on the new docs earlier as well. But ultimately, I still believe making Vue 3 100% backwards compatible, especially with other libraries that relied on Vue 2's internal behavior, is something that was just too costly to commit to. We won't be able to get the level of maintainability and the level of improvements that we want, that we have right now at the same time, if we commit to 100% backwards compatibility. So, enough about the breaking changes, but now let's talk about something more optimistic.

The good news is, I believe the turning point is very close and we will see Vue 3's adoption grow significantly in 2022. Now, outside of Vue itself, one of the reasons that this major, this switch to Vue 3 by default has been delayed for so long is that we spent a lot of time on stabilizing Vite. So this is kind of a detour which we hope will be worth it in the long run. Vite is a brand new build tool that greatly improves development experience with blazing fast server start-up time and hot module replacement performance.

Now, today Vite has already crossed 1 million monthly NPM downloads and being actively used in many production projects. We will also be switching our recommended tooling for Vue 3 to a Vite-based setup very soon. If you haven't tried Vite yet, trust me, it's going to knock your socks off. So definitely go try it, check it out. Anthony from our team and Vite team and Alex from Vue School are both going to talk about Vite in their talks. So definitely keep an eye on those.

While my primary focus is still on Vue as an open-source developer, my ultimate goal is to help other developers do their jobs faster. So that's why I'm particularly proud that although Vite was initially created specifically for Vue, it has now evolved into a framework agnostic tool that can benefit all web developers. Another aspect for increased Vue 3 adoption is that IE 11 is going out at a faster pace. Since Vue 3 no longer supports IE 11, this has been one of the concerns for many users. The good news is, more and more major players are dropping support for IE 11. One of the recent ones is Google Search now officially dropping IE 11 supporting its main product. It still has a fallback experience but they essentially said, we're not going to invest more support into IE 11. And here's what they said, we did the math, it is time. So hopefully this will also send a signal to more and more companies to start dropping IE 11 together.

The most important thing and probably what we, as users, care most about is that the ecosystem is really catching up now. NUTS 3, just recently entered public beta with tons of improvements, amazing features. Many of you are probably, have been waiting for this and Alex from the NUTS team will talk about it very soon. ViewUse is another project that manifests the power of Composition API. It's a huge collection of composition API utilities ranging from browsers APIs to device sensor APIs, merges to animation, to state management. The best part is, you can use as many of them as you want in your project without any of the drawbacks of mixings, right? No namespace conflicts, fully supports tree shaking. So definitely check it out if you haven't. Now, if you're looking for UI component frameworks, there are also already many choices that are stable for V3. Quasar 2 is already stable. Virtify is currently still in alpha but will reach beta in December. John Leeder will talk about this probably in his talk.

There are also other great choices, such as naive UI, prime view, element plus and design view. And if you're building something specific for mobile, there are great choices too, right? Ionic view is built on top of V3 from the ground up. There are also V3 compatible versions of the vent UI and a new project called Valet. So also check these out if you're building for mobile.

In addition to the ecosystem, we also shipped more improvements in view itself in 3.2. The most important new feature in 3.2 is script setup, which significantly improved the ergonomics when using composition API inside single file components. Now due to the time constraints, I'm not going to show off every single feature in 3.2, but after talk, check out these slides. There are links to everything I mentioned. We also had an announcement blog posts for 3.2, so check those out if you're interested. We also greatly improved the IDE support for view single file components via the Vola extension, which is now the new recommendation. So if you're still using Vedar, definitely consider switching over to Vola to check it out. And WebStorm has also been doing a great job in keeping up with our latest Syntax editions. So WebStorm now already supports script setup as in view single file components as well. We now also have a dedicated tool called ViewTSC, which can type check view components alongside normal TS files. So it can treat both view files and TS files in the same project, and it's one type checking pass. You can do this in your CI build pipelines, so you don't have to, so you can rely on the IDE instant feedback during development and then run this during build or during CI. 3.2 also shipped major performance improvements for the reactivity system and for, in terms of rendering, there's also the new Vmemo directive, which gives you the opportunity to do very fine-grained tweaking, many optimizations, in cases where it's extremely demanding. Nah, but in most cases, the rendering performance is already pretty great. And finally, we have some pending RFCs that can potentially introduce even more ergonomics improvements for Composition API. For example, the ref transform RFC that allows us to use refs with reactivity, but without the need to use dot value everywhere. So if you have been bothered by dot value, definitely check out this RFC. So we believe these combined together will push Vue 3 to a whole new level.

But of course, we also want to help Vue 2 users to either migrate, or if you can't, benefit from some of these new improvements. So first of all, we shipped the migration build in 3.1. That can help eligible projects incrementally migrate to Vue 3. Typically, what we found is you should be able to migrate to Vue 3 via migration build, unless you have some hard dependencies that are irreplaceable, but also rely on internal Vue 2 behavior. Now, library authors. Our recommendation for library authors is to write most of your logic using composition API, and then you can target both Vue 2 and Vue 3 via the vue-demi utility. It automatically detects the right version of Vue and then aliases your APIs to the right version. Vue 2 users can also enjoy the speed of VEET via VEET plugging Vue 2.

And you can even start using script setup with Vue 2 via unplugging script setup Vue 2. Now, both these plug-ins are authored by Core Team members.

We also haven't forgot about 2.7. So the main thing that we wanna do in 2.7 is to backport composition API back into Vue 2 so that Vue 2 users no longer need to use an external package in order to use composition API. This is planned for Q1 2022.

Last but not least, we're working on a complete overhaul of vuejs.org. I wish we had done this sooner, but I am very, very excited for this iteration because it brings about so many improvements. As you can see, there will be brand new designs with dark mode. The site is completely rebuilt on VitePress. VitePress is the successor to VuePress, which is now built on top of Vue 3 and Vite. It can statically generate the site from Vue and Markdown.

The new docs will update recommendations and best practices. There is very scattered information about what is the best option to use, what you should use, how you should set up a project for Vue 3, right? It's kind of all over the place in the current docs and of all the information that's been around. So the new docs will consolidate all of them and there will be the defect or recommendation. And you can go there, you can find what is the best way to do things.

And we have also restructured the learning paths. Right, so we divide the new content into three major parts, the guide, the examples, and the tutorial. So the guide will have many rewritten parts to reflect the latest best practices. And more importantly, the guide will be written in a way that it has the same flow, the same concepts, but you can toggle between options API and composition API to see how they compare or just stick to the API that you prefer during the learning process. All the examples will also be available in both API styles and there are many new examples as well. There will be rewritten introduction and framework overview, Q&A page and a brand new tutorial for hands-on learning.

So as I have mentioned, the switch from Vue 2 to Vue 3 is right around the corner. It will happen as soon as the new docs are ready. And that will be very soon. After that, Vue.js.org will default to the new docs for Vue 3. NPM distacts, review, and other core libraries will all point to Vue 3 versions by default. The GitHub repos will still be kept separate. This is mainly because we want to preserve the issue links since they are an important resource for users searching from Google and trying to find answers to past issues. So we will keep the repos separate. Instead, we will rename the Vue.next repo to Vue.js/core.

And that's it. I can't wait to show you the new Vue.js.org once it's done and I hope you're as excited as I am.

So thank you very much. So let's take a look at what people are using today. Apparently, vast majority are still using Vue 2 but are planning to migrate to Vue 3. So 57% of you said that. A lucky 30% of you are already just using Vue 3 and 13% are happy with Vue 2.

Is that surprising at all? Not really. Yeah, that's pretty much what I... I'm glad to see so many people are planning to migrate to Vue 3 though. Yeah, but also I totally think it's for some projects like if it's been working well, it's stable. For certain type of projects, you don't really need to upgrade because sometimes you always have to consider the cost versus the benefits, right? Specifically for a scenario. Like if it's a legacy project, you don't have a lot of bandwidth, right? In many ways, upgrading, it may not result in any major difference from the user's perspective, but it's just gonna take, cost you a lot of time. So in those cases, I think it totally makes sense to just stay on whatever version that works for you.

And yeah, and 30% already on Vue 3 is great. Hopefully more new projects will also start in Vue 3 with all the things I mentioned in the talk. I think I still heard some people concerned about IE 11, but I'm very optimistic that it's going to die sooner than we think. So fingers crossed. Okay. Right.

So back to the first question. How has the move to Singapore been? So as you can see, I'm still in the quarantine hotel with two kids. So it's been kind of challenging, but we're managing. Actually, I think I barely managed to get over the jet lag because it's a 12-hour jet lag. So it's, and you have to do it with two kids. So it's been pretty tough. But once we're out of quarantine, I think then we have to get moving, packing, unpacking stuff and everything. So still some time to go. So I'm still not really backing work mode yet, but the food has been great. So that's the good part.

Food's important. Okay, so next question. Is PNIA likely to become the community go-to for state management? Yeah, I think PNIA is, Eduardo has been doing a lot of great stuff with PNIA. So one of the biggest things that we know that isn't ideal for the current form of UX, with Vue 3 is its TypeScript support, because it's all the dispatch functions are so string reliant. So you don't really get enough type checking across all the API services. So PNIA essentially is designed with all that in mind. Also is simpler, right? Less verbose. It also gives you this way to define a store using pure composition API, which also aligns with Vue 3's reactivity system a bit better. So overall, I think PNIA is definitely moving in the right direction. In fact, a lot of the designs that you see in PNIA kind of overlaps with the proposal that we've been discussing internally about what Vuex Next should be like. So Kiah and Eduardo has actually been working together. We've been brainstorming on what should Vuex look like, but some of the things that we came up, feels very different to the current form of Vuex. So essentially, it's an interesting question of whether it should still be called Vuex, right? If it looks very different. Well, fundamentally, I think what we really want in a state management solution is predictability, type support, dev tools integration, handles SSR for you with the least overhead possible. So PNIA kind of achieves all that. And in some way, PNIA is essentially this sort of let's play with the next iteration of Vuex, but under a different name. So if I were to introduce a state management system into an app today, I would probably also use PNIA. So, I mean, for even simpler cases, I would just use a reactive object as a singleton, export it from a file import, and a bunch of components, especially if I don't need server-side rendering. If I need server-side rendering, I can still do that. I can just provide inject it from the app root, and that's kind of what we're doing in BPRESS. It's very simple because you just provide, inject a bunch of Refs or reactive objects, and that's another form of state management. Of course, that only covers simple cases because it doesn't give you DevTools integration, inspectability, and PDM covers all that, while still keeping the API simple. So, I think that's a great solution.

All right. The next question is one I'm very curious about as well. Is the options API still the default recommended way to build UI components? Okay, so this will be answered more properly in the upcoming docs. I've already written the new introduction section, so to kind of rephrase all that, is essentially we will have both options API and composition API as equally viable options. And which to choose will depend on a bunch of factors.

First of all is, are you using a build tool? If you're not using a build tool, right, options composition API is going to be a bit verbose because you cannot rely on any of these sort of compile time quality of life improvements like script setup or ref sugar syntax, right? So in those cases, options API also, if you're not using a build tool, your overall complexity of your app is probably in the low to mid tier, right? So options API will definitely still be very viable or even, you know, probably better suited in those scenarios. But if you're using adult step, you are using TypeScript or you intend to scale up your app, you know, there are going to be multiple developers working on it. I would say composition API with TypeScript and script setup is going to be a very, very strong, you know, in terms of launcher maintainability, productivity, IDE tooling support and everything is going to be a very good choice. But I've also heard, you know, arguments where it depends on your team composition, right? If your team are all comfortable with TypeScript and, you know, the team is essentially because we all have some sort of different technical preference or taste, right? It's important to kind of consider when you go with an API, what kind of productivity, does it improve the productivity of your whole team as a whole, right? Because in some cases, if you are working with a lot of beginners, sometimes Options API gives you better guardrails because it allows you to get things done without thinking too much about how reactivity works. So Composition API, on the other hand right, it's a bit more freeform. It allows experienced developers to organize your code better, to use advanced patterns, to extract and reuse logic in very elegant ways, but it also requires you to be somewhat comfortable with the concept of how reactivity system works in Vue. So you kind of have to have a solid understanding of how Vue tracks stuff, how things are triggered to be able to use Composition API properly. So it's kind of a trade-off. So you kind of have to pick based on what you're more comfortable with, what your team is more comfortable with. But at the very high level, I'm going to say they are both equally very viable options. So a follow-up question to that. Excuse me. How long will the Options API be supported? Is there any plan at some point to migrate away from it entirely? Not really. So the cost of supporting Options API in Vue 3 is very, very low. Like really there's no... It's just several hundred lines of code. So once we... There's really not much reason for us to remove it. The thing is, in our documentation, in the new documentation, right? We write the documentation in a way where the main flow of the guide stays the same, but we have something that allows you to toggle between competition API and Options API anytime you want, and it's persistent. So once you have a preference of the API, the whole site essentially works with that API style. So you can still read the same guide. It's the same. We're still introducing the same concepts in the guide, but it will be in the API that you have chosen to see. But you can also say when you're reading the same section of the guide, you can toggle between them to see the comparison between them to better understand the relationship between them. I think it's also, the fact that we were able to rewrite the guide that way also shows that the two APIs are really just different interfaces of the same underlying concepts.

So it's still the same how Vue works, how the reactivity system works, how everything fits together, right? The fundamental concepts are still the same. It's really just like kind of how you prefer to express your intentions using different styles. Well, that's that. The original question is no, it's not going away. So really there's no plan.

Okay. Next question. Will Vue demi allow us to use multiple root nodes in our components and still be compatible with Vue 2? Unfortunately, no, because Vue demi is strictly covering, Vue demi is strictly covering only the reactivity APIs. So it essentially bridges your imports to APIs like REF, reACTIV, to either Vue 3 if it exists or to add Vue slash Composition API, which is the Composition API plugin for Vue 2. If you want multiple root nodes in actual Vue 2, unfortunately that's not possible because just how Vue 2's rendering system works, but you can use the Migration Build, Vue 3 Migration Build, which has Vue 2's behavior but supports Vue 3's features. So check it out, check out the Migration Build. If your app is not complex, especially if your app doesn't have dependencies like Nuxt or Vue Defy, then Migration Build will likely get you on Vue 3 without changing too much code. Then you can piecemeal migrate those deprecated features off.

Okay, our next question is, will the Vue CLI be moving to Vite? And if so, how soon? So, short story. So Vue CLI is essentially going to be in maintenance mode soon because the whole architecture of Vue CLI is webpack based. And when we move to Vite, it's going to be much more fundamental than... You know, the thing is when you start a new Vite app with the Vite plugin, it feels pretty much the same from the source code perspective. So all the features were kind of the same. The only difference is our new scaffold tool called create Vue is going to be much less opinionated and much lighter weight. So it doesn't try to be as all encompassing like Vue CLI where it gives you like its own plugin system. We're essentially saying just use the Vite plugin system, leverage the Vite ecosystem instead of having a walled garden that with plugins that only works with Vue CLI. So this is also, strategically this is also because over the years, Soda who maintains Vue CLI has been spending so much time because we had a very ambitious scope for Vue CLI but we realized in the long run, a lot of things can be done at the lower level rather than having them specifically to Vue CLI. So the new scaffolding tool is essentially a thing layer on top of Vite. If you need special additional features, we do have default options like TypeScript or set up TypeScript or test runner or other stuff. But in general, Vite tries to focus specifically just on a build step on the build and serve. So, let's say you want pretty or ES linked, where we're not going to really like hold your hand on how to do that. Instead we're going to point you to documentation or community solutions that already works for any kind of Vite project, instead of only for Vue CLI.

Okay. Okay. Next question is, does Vue plan to keep supporting CDN installation and why are so many plugins only available as NPM installs? So Vue will always support CDN usage.

The fact that plugins only support NPM install, honestly, I don't think so because a lot of Vue community libraries all have their own CDN builds as well, right? So I think this is a, so if a library can support a CDN build, but does not, I think it's more of the library's problem, right? Because technically any version of Vue can always be used over the CDN. Now there are of course disadvantages of that is because you can't do tree shaking. So if you do everything over the CDN, you're gonna end up with a lot of unused code. But I mean it's still viable if your whole setup isn't really complicated to warrant a build step. So yeah, short answer is you will always support a CDN build.

Okay, now, quick last question. If we're starting a new project, should we be using V2 or V3? Definitely V3. Let's go. I had a feeling that would be the answer. All right. Evan, thank you so much for joining us today. Thank you.