10 Years of Vue: the Past and the Future

Hello everyone and welcome to Vue.js Live 2024. I'm Evan Yew, the creator of Vue and Vite. Today I'm super excited to share with you a 10 years retrospective on Vue.js. Yes, you heard that right. Vue is already 10 years old. Sounds like a very long time in front-end world. And of course, Vue is no longer a new technology, but in this talk we'll see some of the history of it and we'll also see what we're doing to Vue to keep it alive and well.

Okay, let's dive right into it. First of all, Vue's today in some numbers. Here are some stats of combined Vue.js slash Vue and Vue.js slash Core combined stats on GitHub. We have today over 9,326 commits across the two repositories. We have released over 493 versions of Vue. We have over 2 million users worldwide, 250,000 GitHub stars, 4.9 million weekly npm downloads, and over 1 billion monthly CDN requests on jsdeliver.

And we also want to talk about some of the technical impact of Vue, because despite using it day to day, maybe a lot of new users today aren't as familiar with the history of it and what ideas first came out of Vue and what ideas kind of influenced other technologies, right? Back in 2014, Vue was the first JavaScript framework to do deep tracking-based reactivity. Now, tracking-based reactivity is a paradigm that dates all the way back to Knockout.js and Meteor Tracker. That's an even older technology than Vue, but Vue was the first one to apply this principle into deep objects. So you can have an object mutated and things just work, and Vue was the first framework to do that. Vue was also the first framework to combine the idea of single-file components with build tools. The idea of single-file components isn't necessarily new. There was in fact an internal project at Google when I was working there, it was a source of inspiration. But Vue was the first one to combine this idea with a build tool called Browserify Backend, and later on, we also supported Webpack. But the ability of single-file components with build tools, the uniqueness of that is that we can use additional languages in these script blocks or template or style blocks. So you can use CoffeeScript back then, today you can mostly use TypeScript, you can use SAS, LASP, preprocessors, you can use PostCSS to process your CSS, you can even use POD, which was called Jade back then, different templates in text with templates. So Vue was the first framework to support this kind of usage. And Composition API was the first to combine Signo style reactivity, which is also the tracking-based reactivity that we talked about earlier, with modern component models. So you can use Vue refs in a script setup syntax with modern component models, and Vue was the first to actually combine that model into the model component model that we are all familiar with today. And Vue was also the first to explore a compiler-powered reactivity sugar for Signos in the form of the reactivity transform, which was an experimental proposal that we ran with for a period of time, but in the end we decided that it was not the best direction for Vue. However, we are actually pretty happy to see that this direction is being picked up by other frameworks, for example, Svelte 5, that actually is also exploring this direction. So it might be a better fit for Svelte, but we believe Vue is in a pretty good place with its own paradigm. Now, Vue is also unique in supporting both template and virtual DOM render functions.

This affords a very good balance that offers familiarity for users who prefer the template syntax and a smoother developer experience for people who prefer HTML-style templates. But at the same time, in advanced use cases and for library authors, you can still skip the template layer and drop down into manually writing render functions that gives you a lot more flexibility in doing advanced features.

And finally, Vue pioneered the concept of the progressive framework, the idea of a framework that is not monolithic, the idea that a framework can be made up of individual pieces but with a coherent design that you can adopt and use incrementally based on how much you need from the framework. I believe Vue is the first one to pioneer this idea, and it's also the only one that has implemented it really well.

Now, looking back, here's a brief timeline of what Vue did. We did the first release with the name Vue.js in 2013. That was the first time the name Vue.js ever appeared. But the public announcement was in February 2014. It remained as a side project for me for a very long time, and it took quite some time for me to polish it enough to feel comfortable, to feel confident to share it with the world. In October 2015, we reached 1.0. I actually took a long break in order to push it towards 1.0. And after 1.0, the template syntax largely set. In 2.0, we did the major rewrite, which we implemented the rendering to use virtual DOM, and was released in October 2016. 2016 was also the year that I started working on Vue full-time. Now, the work on Vue 3 actually started in September 2018. That was a very long time ago. But 3.0 took much, much longer than expected because of the scale of changes and the scale of impact on the ecosystem it created. Vue 2 was already very, very widely used, and the work on 3.0 was a learning process for us. There were definitely ups and downs, mistakes that were made, and lessons learned. So 3.0 was soft launched in September 2020, and eventually became the default version in January 2022. So the whole process took a few years. But we are really happy that the ecosystem has finally embraced Vue 3, and we'll see some stats later. So Vue 2 has officially reached end of life in December 2023. And we really encourage users who are still on Vue 2 to consider upgrading, or you should seek out relevant support to keep your Vue 2 versions running.

Now, so this was a really kind of like a nostalgic moment where I still have this blog post up somewhere talking about the first week of launch of Vue.js, and I was really happy that I got a few hundred GitHub stars in the first week, which was a great achievement for me back then. But after the initial launch, right, there were the moments, there were ups and downs where the reality hits. So I don't know if anyone has heard of the technology adoption cycle. There is, whenever a new technology comes out, there is a technology trigger. There's a peak of inflated expectations. Then there's the trial of disillusionment, slope of enlightenment, and finally you reach the plateau of productivity.

Now, I would say there is a very similar process when you get into open source over time. Now, when you first get into open source, there's this great excitement, peak of excitement and output. I was working almost all day, every day on Vue when I was pushing for the initial launch and also pushing for 1.0, pushing for 2.0. Those were the moments where I could just work on it all day.

But there are also moments of burnout and self-doubt when there are bugs, issues, people criticizing the design decisions that we made. And I had to adjust to these comments over time. I had to learn what are the actual right decisions. It takes a really long time for you to realize you can't really please anyone and sometimes you just have to make hard calls. And eventually we reached the slope of rebalancing and reached the plateau of productivity.

But obviously there are challenges when you need to get through those burnout periods. And that's what I call the chasm. For a lot of open source maintainers, crossing this chasm is the major challenge that you have to go through. And if you're working on open source projects, there will definitely be moments like this. And just know that you have to learn to adjust how to deal with this and you need to learn to find a balance between your goals, your life, your work, and open source. And I really hope that everyone working in open source can get out of the chasm and reach this balanced plateau of productivity.

So here are some graphs. If you look at my GitHub contribution graphs, you will see that there are definitely moments of burnouts and self-doubts. So I want to be really open about this. I want to let everyone know that even behind some of the most successful open source projects, maintainers are human too, right? So there will be a time where they need to adjust. There are times where they need to take a break, they will need to find inspiration, they need to go and recharge and find their motivation again. So this happens, this is normal. And I want to normalize this for open source maintainers so that we feel less pressured and I hope to see few fellow maintainers burn out. And it wouldn't have been possible to carry through without the support from the AmazingView community. So I'm putting the word up here three times because that's how important it is. If I were Steve... Ahem! Sorry. Cut this part out. Okay. Thank you. I'm putting the word up here three times because that's just how important it is.

The View community is the one single thing that I'm the most proud of. View is about people, it's the most diverse, inclusive, welcoming, and open-minded community that I know of, full of amazing and wonderful people. Without the community, I would never have had the energy and persistence to keep working on View and push through those chasms or burnout periods. So View wouldn't be where it is today without you all. So here's my deepest gratitude to our team members, to the contributors, to the ecosystem library maintainers, to the community partners, conference and meetup organizers, View advocates, and sponsors.

Now, let's talk a bit about sustainability and independence, which I think is also another aspect that really makes View unique. View is currently the only mainstream framework that remains independent, i.e. not dominantly owned by a single corporation. Why is this important, you may ask? The reason I think is we are not constrained by the financial support of a single entity, which means we're not going to be swayed in the technical directions just because one big backer wants us to go a certain way, right? All of our sponsors, all of our financial supporters are decentralized and they don't really have strong swaying power into the technical decisions made for the project. So the project is able to operate solely considering the interests of the users and every user's opinion will get equal consideration. And another important aspect of the View ecosystem is the collaborative mindset. Thanks to the independence, the View ecosystem is unique in a way it spawns many, many notable efforts that end up benefiting more than the framework itself. If things were for benefits, this would look quite different. The View community has been the source of multiple efforts that benefited the entire JavaScript ecosystem as a whole. Just to name a few, we have Vite, we have Bolar, we have Un.js, Nitro, and some cross-framework dev tools work that's being worked on. All of these from View and Vite community members.

Finally, let's take a peek into the current state and the future of View. So View 3 usage has increased by 77.6% over the past year, a very strong growth for View 3 and it's also taking up a much larger percentage of total View downloads and now constitutes over 58.3% total MPM usage. A lot of legacy View 2 applications are obviously still running and people will still continue to work on it. So it's still good to see the percentage of View 3 continues to grow over time. Now, 3.4 is the current minor release which was released in December 2023. The main flagship feature in 3.4 was a completely rewritten posture that is two times faster than before. So one thing I want to really emphasize is even if View is a 10-year-old framework and View 3 itself is almost six years old, the code base is six years old, we are still finding lots of room of improvements here and there. And we are always going to keep digging into these opportunities and finding performance gains and experience improvements for our users. Now, 3.4 also shipped a more efficient reactivity system that reduced a lot of unnecessary calculations in computer properties. We also stabilized defined model and shipped VBind, same name, shorthand on. Both of which have great developer experience improvements. Now, the most recent notable change in 3.4 is in a recent patch, we shipped some pretty important server-side rendering performance improvements. Now this was largely triggered by a public benchmark that has been circulating around on Twitter.

Now this was largely triggered by a public benchmark that has been circulating around on Twitter. And by inspecting the benchmark, I was able to identify a few cases where some of the optimization was leading to View's poor performance in the original benchmark. So now with those changes landed in 3.4.22, we see a whopping 3.8x improvement in that benchmark for View alone. And for Nuxt, there's also a very, very notable 1.77x improvement. And Daniel has also submitted a pull request that optimized the Nuxt usage when using async data that avoids using deep data structures when fetching the data, which is going to be the default in Nuxt 4.0, which again improves the performance in that benchmark by quite a bit. So if you're using Nuxt, or you're using server-side rendering with View, your other methods, make sure to upgrade to the latest version.

So let's talk a bit about what's planned for the next version in 3.5 and beyond. So first of all, we're shipping even more reactivity efficiency improvements. So the current minor branch on GitHub is the in-development branch for 3.5 has already merged two very important pull requests for the reactivity system. PR number 10407 provides a rewrite of the reactivity system again. So the internal tracking data structure has been refactored with a 56% memory usage improvement. So memory usage is quite important because in data-intensive applications, garbage collection can actually be a performance killer. So using less memory is going to help a lot for highly dynamic applications. Now 9511 provides a 10 times gain when tracking large reactive arrays. Now this has been actually quite a common source of performance bottleneck when you have really, really large arrays and you put it into a deep data structure. Now this PR actually provides a smarter way to avoid tracking unnecessary dependencies when iterating through over these larger arrays and provides very, very significant gains in these cases. We are also thinking about stabilizing reactive props to structure because we're seeing quite positive feedback in the RFC discussion. But before we finally do that, we would encourage you to voice your opinion in the RFC to help us make a final decision. There are also planned SSR improvements in 2.5, but the primary one being to stabilize suspense. It has been experimental for a very long time and we're really looking forward to stabilize it. And then there are small APIs like useID, quality of life improvements like built-in HTML nesting validity check, help you to catch cases where you're accidentally putting divs inside peas or peas inside divs. And we are also going to look at a possibility of built-in lazy hydration using async components as boundaries.

Now, a lot of you are probably curious about the status of vapor mode. Now, we are making great progress on vapor mode. So it can already run to do MVC in case you didn't know. So you can try it out in the playground already. So there, if you download the slides later, you should be able to find the link and try it out. Or you can go to the core vapor repository on GitHub and see it. You should be able to find the link there. The current stage focus for vapor mode is component implementation.

And the good news is we're almost there. So if you look into the linked issue here, we've covered a lot of the parts of components and there are only a few things left. And once we finish components, the next stage focus will be on the interop between vapor and virtual DOM, i.e. being able to compile and embed vapor components into your current applications. That's going to be the next big milestones to hit.

Vapor mode is a team effort. It is being led by Kevin, and we have a lot of great contributors helping with vapor. It is really exciting to see because this is a pretty advanced implementation, and I was happy to see that by setting the initial direction, a lot of community members are stepping up to help us work on vapor in parallel to current Vue core work.

And finally, we want more development experience. So some of the work I've been doing outside of Vue is further improving Vite by investing in lower-level toolchains. So a lot of you may know that we've started a new Rust-based bundle called Rodown, which is intended to support Vite in the future. Rodown is now open source, and we're seeing great performance. And we currently have finished basic bundling, basic chunk splitting, and source map support. And with all these implemented, we're able to run some benchmarks, and we're currently being 1.5 to 2 times faster than ES build, which is super impressive. And we are also contributing to OXC, which is the lower-level language toolchain, Rust-based possible JavaScript that we're using inside Rodown. And we are having a very tight collaboration relationship with the OXC team. And we also have team members working on extracting reusable layers between Nuxt and Vue dev tools and potentially use the same kit to support other kind of dev tools in the future. And we also have continued improvements in VolR V2, i.e., Vue language tools. So VolR V2 was shipped with the support for hybrid mode, which allows us to use the single TypeScript language server to support inferring the entire project, both TS and Vue files. Now, this is very, very efficient memory-wise, performance-wise, but there are a lot of edge cases, and there are still some rough edges we need to stabilize. But we're seeing really, really great promise in the performance of this direction. Okay, and finally, native Signos. This is something I want to talk about a bit extra. In case you don't know, there is a TC39 proposal to add Signos as a native JavaScript language feature and is now Stage 1. Signos, if you are not familiar with the term, are reactivity primitives similar to Vue refs. So if you've used Vue refs, you've used Signos. The Vue team has been involved in the discussion of the proposal from the very beginning, and we're experimenting with the possibility of a native Signal-powered version of addVue slash reactivity, the lower-level reactivity engine that's powering Vue proper. By using native Signos, we should be able to get less code to maintain and bundle, so less code to maintain in the Vue code base, less code to ship to the end users. There should be better performance and memory consumption because native Signos can be implemented in native languages, and there is the potential for cross-framework interop, think cross-framework Vue use. If we can use Vue use across multiple frameworks, that would be a dream.

So we're looking forward to this happening in the future, and we're working with other participants in the proposal to make sure that we reach very interoperable implementation when it actually lands. So that is all for today, but we are far from done. So Vue is 10 years old, but there's just still so much to be done. We experienced a period of fragmentation during the Vue 2.3 transition, but now that Vue 2 is officially end of life, the Vue 3 ecosystem is thriving with higher-quality utilities, component libraries, custom renderers, and meta frameworks than ever before. And we're here to support more of this in the coming years.

We've survived through the JavaScript hype cycles. Vue is here to help you get your job done, not to sell you pay service. We're proud to say we stay true to that statement. We may not be the most trendy solution nowadays, but we are here to stay, and we'll always be consistently improving, one thing at a time.

Thank you. So what is your current version and build tool framework? I can see that 52% of the people are still on Vue 3 and Vite SPA. Second leading one is Nuxt 3. So that's nice, at least everybody's migrated to Vue 3 as of today. Unfortunately, not everybody. I do see Vue 2 SPA is like 9%. Oh, it just got overtook by Vue 3, other setup. Nice. 16%, Vue 2 still. I mean, it's still better than a year ago, so, yeah. Yeah.

Okay, so now let's go back to the Q&A, finally, sorry for V4. So, hello, I'm a React developer. Recently, I started to learn Vue.js. So my question is how to become a pro in Vue? What is your advice to a beginner in Vue.js? Sure, so I think it should be maybe a bit easier since you already know React. Composition API has a lot of similarities with React hooks. So you should feel right at home. In fact, there should be a bit less to worry about in terms of tracking dependencies, passing dependency arrays, you don't need to worry about that in Vue. So I think the first thing you want to do is just read through the docs, and I think the biggest – a lot of the concepts like state flow, component model, in fact, are really similar between these mainstream frameworks. So you should be picking those up really fast. I think if you want to get more advanced, read some source code of, for example, libraries like Vue.use. That's actually one thing I really recommend. Take a look at how people extract these common utilities into reusable Vue composables, aka hooks. I think that's a really good way to get more acquainted with how Vue reactivity works.

Okay. So the most voted question is, the first one has been around for a long time but still warned as being experimental and likely to change. Is this still correct? It is still experimental. We're planning to stabilize it soon. In fact, I don't think the API is going to change much. So it's mostly making sure it's – if anything you want to change, it probably won't affect end users very much. Will you have maybe like a wide ETA? Like 2025 or the end of the year? This year. This year, hopefully. Nice.

And maybe a quick update on the Vue.js plugin on VS Code. Yeah. So the recent 2.0 release, I know there has been quite some issues with some users. So some of the issues are actually due to the bugs in VS Code. And then there's a recent issue where if you're – check your VS Code Vue extension version. If it's on 2.0, it's stuck on an old version. Do a new search on install the old one and install the version that is 2.0.14 or above so that you get continuous auto-upgrades. So that's an issue we are trying to get in touch with VS Code to resolve. So it's not even like a Vue.js issue.

Perfect. So thanks again for all of those questions, Evan. See you some other time and have an amazing day. Bye. Thank you. You too. Bye.