One Year Into Vue 3

♪ Hello, everyone. Evan here, and thanks for tuning in to 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 18, 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 patched and pre-released versions. Today, vue 3 has crossed 1.2 million downloads per month. But many of you are probably wondering, why haven't we switched vue.js.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 DevTool extension wasn't ready, and IDE support and the tooling story were both lacking. In addition, major ecosystem projects like Nuxt and vue Defi also needed time to come up with a vue 3 compatible version. So we intentionally opted 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 lessons 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 the 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 re-engineering 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 on the existing architecture. Note, these usually involves mass refactoring or even ground-up rewrite, which was the case for vue 3. 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 the 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, right? 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 in 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 reduce, make it extremely easy to upgrade, but it will 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. So 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 Compat Build. However, some of the exchanges are found 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 the Compat 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 all the 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 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 startup 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 probably have been waiting for this and Alex from the NUTS team will talk about it very soon. vue Use 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, bridges, 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. 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 vue 3. Quasar 2 is already stable. vue.ify is currently still in alpha but will reach beta in December. John Leader will talk about this probably in his talk. There are also other great choices such as Naive UI, Prime vue, Element Plus, and design vue. And if you're building something specific for mobile, there are great choices too. ionic vue is built on top of vue 3 from the ground up. There are also vue 3 compatible versions of the Vant 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 vue 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 the talk, check out these slides. There are links to everything I mentioned. We also had an announcement blog post for 3.2. So check those out if you're interested. We also greatly improved the IDE support for vue single file components via the Vola extension, which is now the new recommendation. So if you're still using Veeder, 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 additions. So WebStorm now already supports script setup in vue single file components as well. We now also have a dedicated tool called vue TSC, which can type check vue components alongside normal TS files. So it can treat both vue files and TS files in the same project. There's one type checking pass. You can do this in your CI build pipelines. 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 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. But in most cases, the rendering performance is already pretty great. And finally, we have a new release called vue. And in terms of rendering, the new VMemo directive gives you the opportunity to do very fine-grained tweaking, many optimizations in cases where it's extremely demanding. 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 IFC that allows us to use refs with reactivity, 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 vite via vite plugin vue 2. And you can even start using script setup with vue 2 via unplugging script setup vue 2. Now, both these plugins are authored by core team members. We also haven't forgot about 2.7. The main thing that we want to 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 contain updated recommendations and best practices. There are 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. 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 de facto recommendation. You can go there. You can find what is the best way to do things. And we have also restructured the learning paths. 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, vuejs.org will default to the new docs for vue 3. npm Distact, vue, 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 repo separate. Instead, we will rename the vue Next repo to vuejs.org. And that's it. I can't wait to show you the new vuejs.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, the 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 for some projects, 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. 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 going to 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 are also starting vue 3 with all the things I mentioned in the talk. I think I still heard some people concerned about IE11, but I'm very optimistic that it's going to die sooner than we think. 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. 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, unpacking stuff and everything. So still some time to go. So I'm still not really back in 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 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, it's simpler, 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 Kia and Eduardo have actually been working together. We've been brainstorming on what should vuex look like, but some of the things that we came up with feel very different to the current form of vuex. So essentially, it's an interesting question of whether it should still be called vuex 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 exported from a file, import it in 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 an inject it from the app root, and that's kind of what we're doing in VitePress. 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 dev tools integration, inspectability, and PNIA 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, 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. 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, so Options api will definitely still be very viable or even probably better suited in those scenarios. But if you're using a build step, you're 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 free form. 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. 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. Like, 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 you can, we have something that allows you to toggle between Composition 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. But, so you can still read the same guide. It's the same, like, 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're 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 only the reactivity APIs. So it essentially bridges your imports to APIs like Ref, Reactive, 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 Defi, 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, 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, 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. So we're essentially saying just use the vite plugin system, leverage the vite ecosystem instead of having a walled garden with plugins that only work with vue CLI. So this is also, you know, 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. And 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 additional features, we do have default options like typescript or setup typescript or TestRunner or other stuff. But in general, vite tries to focus specifically just on the build and serve. So let's say you want prettier or ES-linked, 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. OK, 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. 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. Because technically, any version of vue can always be used over the CDN. Now there are of course disadvantages of that, because you can't do tree shaking. So if you do everything over the CDN, you're going to end up with a lot of unused code. But I mean, it's still viable if your whole setup isn't really complicated to learn the 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 vue 2 or vue 3? Definitely vue 3. I had a feeling that would be the answer. All right, Evan, thank you so much for joining us today. It's been a pleasure.