Video Summary and Transcription
This talk is a ten-year retrospective into the growth of the Vue.js framework as an open-source project. It highlights the challenges faced by open-source developers, the importance of finding balance and managing scope, and the collaborative nature of the Vue community. The talk also discusses the development of Vite as a build tool and the vision for a unified JavaScript toolchain. It emphasizes the need for community alignment, contributions, and testing, while acknowledging the challenges of bad actors in the open-source community.
1. Introduction to Ten Years of Open Source
This talk is a ten-year retrospective into the ten years of work in open source. It covers my experience as an independent open source developer, starting with the release of Vue.js in 2014. I now work full-time on Vue, Vite, and other related projects. Vue is a front-end JavaScript framework with significant growth over the past ten years, with numerous GitHub commits, releases, stars, npm downloads, and a large user base. The scale of Vue's growth has exceeded my expectations.
Hello, everyone. Really excited to be here. This is in fact my seventh or eighth time in Amsterdam. But I want to get into the talk quick because it was really late until I realised I only have 20 minutes and I have 40 slides or something. I'm going to try to go quick, otherwise I won't be able to finish in time.
This talk is about a ten-year retrospective into the ten years of work in open source. About me, I'm an independent open source developer, and I've been independent since 2016, so that's a bit over eight years, but my first foray into open source was releasing Vue.js back in 2014. This year marks a ten-year of working on open source and building in the open. I'm now based in Singapore and works full-time on Vue, Vite, and a bunch of other related open source projects. Before going full-time, I briefly worked at Google, and then at a start-up called Meteor.js. That's enough about me.
Things I work on. I work on two things, mostly. One is Vue, which is a front-end JavaScript framework created in 2014. How many of you have heard about it? Thank you. The other tool is a front-end build tool called Vite. How many of you are using Vite? Wow. Okay, great. So Vite was created in 2020, about four years ago. So let's talk about Vue first. It's a ten-year-old project. It took a long time to get there. But if we take a brief snapshot of Vue today, we have two repositories on GitHub, one for Vue 2 and one for Vue 3. Combine these two repositories, we have over 9,000 commits, 500-plus releases, 250,000-plus GitHub stars, 5 million weekly npm downloads, and 2.2 million users worldwide. This is statistics from our dev tool extension. It has over 1 billion-plus monthly CDN requests on JSDeliver. Every year, I look at these numbers and marvel at the scale that Vue has grown into, and I think it's probably, people have asked me the same question so many times. Did you expect this to happen when you first started working on Vue? And the obvious answer is no. I had no idea what it's going to be like. No expectations whatsoever.
2. Early Days and the Journey
I started working on Vue full-time after its humble beginning in 2014. The timeline of Vue's releases and updates shows its growth and evolution. Maintaining an open source project can lead to burnout due to high user expectations. However, the journey is similar to the technology adoption cycle, with initial excitement followed by challenges and eventual productivity.
Even when I decided I want to start working on it full-time. So it is a pretty amazing journey. But let's take a step back and think about, talk a bit about the early days. I won't dig into too much of the small stories of how it all started, why I got the idea. But the humble beginning in the early phases when I first launched Vue in February 2014, the result was I got a few hundred GitHub stars and I was over the moon about it. I was really excited. But that was just the beginning, so the excitement really didn't last that long, to be honest.
But let's take a look at the brief timeline. First release, with the name Vue.js was actually in 2013. It was private. I only put it on NPM but didn't tell anyone. The first public announcement is February 2014. It reached 1.0 in October 2015. 2.0 in 2016, 3.0 started in September 2018. And sublaunch, September 2020. 3.0 finally became the default in January 2020. And December 2023, we finally declared Vue 2 to be end of life. So that's a very, very quick overview, right? But I don't really want to spend this talk talking about all the little changes that happened over time about Vue. Because I want this talk to be more about the journey, the feeling, you know, the sort of how things have changed for me over the course of working on a project that grew beyond my expectations. So there were a lot of ups and downs.
A very obvious thing, if you look, dig into my GitHub profile and see, there is a graph here. So that's February 2014 when I first released Vue. And there were quite a few months right after that I didn't write any code on GitHub at all because I was quite burned out, right? So this happens quite a lot. How many of you here maintain an open source project? Not a lot of you. But if you've maintained an open source project over time, you probably experience some form of burnout, right? Because the expectation that open source users place on you, especially when you have a project that's grown bigger than you expected, is tremendous, right? So I like to make an analogy to this technology adoption cycle that many of you have probably seen. Usually when new technology comes out, there's this peak of inflated expectations. And then it just falls hard into this disillusionment phase where you're like, this is crap. And then you need to kind of just like get across that chasm to be able to go back to the slope of enlightenment and plateau of productivity at the end. So I make an analogy of that to open source involvement. When you get into open source, and this is personally for me, when I first got into open source, there is a peak of excitement and output.
3. Challenges and Finding Balance
As an open-source developer, I have experienced burnout and self-doubt. Despite the pressure and challenges, I have learned to find peace and adjust my expectations. Many open-source maintainers abandon projects in the face of burnout, but finding a balance between responsibilities and personal life is crucial. The journey of an open-source developer is filled with challenges and life events. When using open-source projects, it is important to appreciate the effort and consider giving back to the community. Managing the growing scope of projects is another struggle faced by developers.
I was like, wow, my thing is getting attention on Hacker News, it's getting GitHub stars, all these people using my software, and I'm trying to answer every single issue on GitHub, trying to fix every single bug. And then, you know, as your user base starts to grow, more flaws get revealed in the thing you thought that was perfect. And you realize, okay, maybe I could improve here, maybe I could improve there. Oh, wait, this other project has been doing this all this time, which I never thought about. Oh, I should maybe just close this project and ask people to use the other thing. Right? So there is very common for open source developers to go through this phase of burnout and self-doubt. And it's the same for me. And there have been multiple times that I have been going through this kind of thinking whether I should continue working on this, does it even make sense? Is it still worthy of pursuing and putting in all the time? And just the sheer amount of pressure you get, every day you wake up, you get 20 issues of people finding your software just does not work. That's tough, okay? So over time, I've learned to adjust, readjust. Over time, I've learned to just find peace with myself, and acknowledging that things cannot be perfect. And I think for most open source projects and for most open source maintainers, there is this process of once you get into this sort of burnout phase, a lot of them just never get out of it. They just stop there, they abandon the project. And that's why we see all the churn of different solutions coming up and go. Right?
If you can get past that chasm, and you find peace with yourself, and you're like you find a good balance of understanding your responsibility, and the limit of your capabilities, and drawing a good line between how much you want to put into your projects and how much you want to get out of in life, right, you need to find that balance to be able to keep working on open source productively. And that is not an easy thing to do, right? So, this is when I first released Vue, and there are multiple other phases in my career where I just stopped writing code for a few months. I'm like, I'm done with this. I don't want to do it anymore. But then I come back. Eventually, right? So even today, sometimes, you know, like I pulled the whole graph of like all the way from 2014 to 2022. And there are just multiple life events, right? Open source maintainers also have all these things going on in life, having babies, moving to new places, having COVID. So my whole point here is when people think about someone who's like me who's been working open source for ten years, it's not always smooth sailing. We have to just like go through a lot of challenges and just finding what is meaningful to us to keep ourselves motivated in working on these things. So my hope is when you're using an open source project, not necessarily from me, but from any other person who kindly shared their work with you for free, think about what they have gone through in the time that you don't see, the effort they put into it, maybe the burnouts they've struggled through. And just appreciate it a bit more. And think about giving back. Think about supporting them. Think about, you know, contributing, helping them fix issues, or donating, sponsoring them. So many ways you can help. And for me personally, a lot of the struggle comes from also handling the growing scope of the projects, right? Vue as a framework, you started as a very simple script that you can include your script tag on a page and it will just work. Over time, the scope just expanded so much.
4. Managing Scope and Community
Outside of Vue core, there are various aspects that require attention and maintenance. These include documentation, official router, state management libraries, build tool chain, IDE support, and browser dev tools. Handling the growing scope of Vue was extremely challenging. Additionally, tough decisions had to be made during the Vue 2 to Vue 3 transition, including the introduction of the composition API. Despite being a single person, I acknowledge that the project is now a community effort, and I express my gratitude to all the team members, contributors, maintainers, sponsors, and advocates who have made Vue possible. My role has transitioned to encompass mentoring, technical direction, community management, and managing relationships with sponsors and commercial partners.
Outside of Vue core, we also have the documentation which we have like hundreds of pages of all these detailed information, right? And need to be kept up to date. We have the official router, we have official state management libraries, we have the build tool chain, which somehow I ended up building a build tool myself because I wanted to improve Vue's tool chain. And then there's IDE support, which is trying to get all the typescript and CSS, embedded language, working nicely in Vue single file components. It's very complicated. It's a lot of work. And then there's the browser dev tools. We need to keep the whole ecosystem in sync. When we did Vue 3, it took us two years to get all these things up to date with Vue 3. So, you know, handling the grown scope was extremely challenging.
And then we also need to deal with a lot of tough decisions, right? The Vue 2 to Vue 3 transition, if you are a Vue user, you probably know it was not smooth. There were lots of mistakes made and lots of lessons learned. We also had pretty much reinvented the framework with composition API which opened up a new paradigm but also created fragmentation. Some Vue users prefer the old APIs. We have to go through lengthy discussions in RFCs and debates, trying to convince people that this is actually a good thing that can help you in certain ways.
A realisation eventually that I got from all these struggles is that I'm just one person. I can't write all the code. I can't answer all your questions. I cannot fix all your bugs. And that is fine, because the project is no longer just me. It's a community. So I will be like Steve Ballmer and repeat this as many times as I want, because this is just so important, because this is what made Vue possible. You see, I struggle as a single person, but we pulled it through because it's not just me, it's a whole team, a whole community. So, Vue wouldn't have been where it is today without the people around it, right? That's why we say open source is about people. So here's my deepest gratitude to our team members, contributors, ecosystem library maintainers, sponsors, conference meet-up organisers, community partners, advocates, all these people, not just contributing in forms of code, but just contributing in making people connect around the project, and helping it improve in every aspect possible, right? In the same time, my role kind of started to transition from just writing code. Sometimes I do wish I could just focus on writing code, but nowadays, there's just a lot of work outside of code that's about mentoring people in the ecosystem, helping team members grow into bigger roles. Technical direction, just like trying to making sure all these projects are moving cohesively. Community management, pretty much tweeting. Sponsor relationships. We actually had to make the project sustainable, and that's a part of Vue that I'm pretty proud of, and then there are commercial partnerships. There are companies building on top of Vue, building in the Vue ecosystem, and they want to collaborate and give back to Vue, and so all these kind of relationships that we have to manage just outside of work.
5. Contributions, Improvements, and Collaboration
We distribute a fair amount of money to Vue and Vue contributors. Despite being a ten-year-old framework, we continue to ship significant internal improvements such as a faster parser, improvements in SSR benchmarks, and a reduction in reactivity system memory usage. We are also working on ambitious projects like Vapor Mode and a new dev tool. The Vue community has a collaborative mindset and has contributed to the JS ecosystem beyond just Vue.
It's kind of like a full-time project management outside of just writing code. Something I'm really proud of is we actually distribute a very fair amount of money to Vue and Vue contributors in our ecosystems. Every year, we actually distribute more than $270,000 to our contributors in the ecosystem. Plus full position and sponsorships our contributors receive due to involvement in the projects. Sometimes, we would, you know, some contributors, for example, to Vue or Vue would land a job because a company wants to hire a core contributor or want them to keep working on these open-source projects. So opportunities created.
On the technical front, I just want to mention a few things. Despite being a ten-year-old framework, we are still shipping very significant internal improvements. We just recently had a 2x faster rewritten parser, we had 3.9x improvements in SSR benchmarks, and we had a new upcoming release in 3.5 that reduces the reactivity system memory usage by 56 per cent and improves dealing with large reactive arrays by up to ten times. So we're still well alive and shipping very significant internal changes. And then there are more ambitious stuff going on like Vapor Mode, this is a solid-inspired compilation strategy that takes the same Vue component syntax and outputs something that is more performant. Currently, it is still a work in progress, but we're almost done with the components, and the next stage is really trying to be able to allow users to invent Vapor components in today's Vue applications. We have a new dev tool that is coming up that just have better UX, more features, more performance, and smoother.
Another thing I want to mention about the Vue ecosystem is the collaborative mindset. The Vue community has been the source of multiple efforts that benefited the entire JS ecosystem beyond just Vue, right? So V to be the primary example, and then there is Volar which is the underlying framework for our IDE support but it is actually now also being used to support other embedded languages like Astral, or MDX, and JetBrains is in fact using Volar to support, trying to use that to support Angular language server as well. So cross-framework utilities like in the unjs section, if you've never checked it out, search for it. It has a lot of nice stuff that you can reuse. They come from the Nux team, but they are framework agnostic, and Nitro is a server-side framework that allows you to more easily build a full stack framework combined with Vite. I have only three minutes left so I have to go really fast into the Vite part.
6. Vite: A Lean and Collaborative Build Tool
Vite is a lean and extensible build tool that supports higher-level frameworks. It has a huge ecosystem and a collaborative cross-framework community. The future of Vite includes improving support for meta-frameworks, building a native JavaScript toolchain called OXC, and creating Rowdown, a bundler tailored for Vite's needs.
Let's talk about Vite. How it started, April 20, 2020, as I was going to bed, I just had this, it just clicked how to do hot module replacement over an ADBSN. It did it and it became Vite. This is how it is going.
We just recently crossed 13 million weekly downloads. That is, how much is that? More than 15 million per month? We have a huge ecosystem of all the tools that either is built on top of Vite, or supports Vite, or leverages Vite to some extent for some of its features. You probably see a lot of familiar logos here. So, yes, in perspective, we are probably now at half of webpacks. Hopefully we can see that gap shrink further later this year.
The philosophy of Vite is we want to build a build tool that is lean and extensible, push for the modern web, we take a pragmatic approach to performance, and we want to support higher-level frameworks. We want to build a collaborative cross-framework ecosystem that everyone is trying to build something better for the web, and everyone can focus on innovations that matter instead of reinventing the wheel, because Vite has become the shared infrastructure layer.
Along with the technical side, Vite has grown a very amazing cross-framework community. This is a picture from the Vite team panel at Vue.js Amsterdam last year, also in Amsterdam, which is really cool. We have contributors from all over the world, from different frameworks.
What's next for Vite? We want to do two things. The first is Vite internally in the current Vite release line, 5.3 and Vite 6, we want to do environment API which is focused on better supporting meta-frameworks that we have today. On the other hand, we want to improve Vite from the very bottom up. We're building a native one on top of native JavaScript toolchain called OXC. to better support frameworks that run in multiple environments, browser, Node.js, workers, and it's currently experimental in Vite 6 alpha. This is more framework author-oriented, so I won't dig too much into the details, but the idea is we are actively listening to the needs of people building on top of Vite and trying to come up with better abstractions so that all these different frameworks can reuse the same primitives to better support their high-level needs.
Rowdown is a Rust-based bundler designed for Vite. It is created, the project is started to address a few problems in Rowdown, namely we need better dev and prod consistency, better production build performance, and we need better production build asset quality. To achieve these goals, we essentially are trying to build a bundler that stands on the shoulders of giants, right? So, we want the speed of VS build. We want the plugin ecosystem of Vite and Rollup. We also want the production assets control of Webpack, right? There are nice things about these existing bundlers that we want to put them together and tailored for the needs of Vite, and that is Rowdown. So Rowdown right now is in a working progress. Milestone one library bundling is complete, and the next step we are working on are Vite and Rollup plugin compatibility and advanced chunk control for app-oriented output, so advanced chunk splitting and model federation in the future.
7. Building Rowdown and the Unified Toolchain
We want to tailor existing bundlers like Webpack to meet the needs of Vite, which led to the creation of Rowdown. Milestone one library bundling is complete, and we're now working on Vite and Rollup plugin compatibility and advanced chunk control. LXC is the foundation for Rowdown, a language tool chain for JavaScript written in Rust. Our vision is to create a unified toolchain with the V, Rodan, and LXC teams, enabling a consistent AST format and unlocking new possibilities. Join us on GitHub if you're passionate about JS tooling!
We also want the production assets control of Webpack, right? There are nice things about these existing bundlers that we want to put them together and tailored for the needs of Vite, and that is Rowdown.
So Rowdown right now is in a working progress. Milestone one library bundling is complete, and the next step we are working on are Vite and Rollup plugin compatibility and advanced chunk control for app-oriented output, so advanced chunk splitting and model federation in the future.
LXC is the foundation Rowdown is built on top of. Author Boston has another talk that is later going to be streamed remotely about LXC, but, in general, it is a language tool chain for JavaScript written in Rust that includes a parser, a transformer, a resolver, a linker, a formatter, and a minifier.
Our end vision for this is to have the V team, the Rodan team, and the LXC team work together to create this unified runtime agnostic toolchain for JavaScript and the web. The meaning, the value of a unified toolchain is now we can have a consistent AST format that handles everything. Pretty much the vision that Rome was originally created for, but somehow never achieved. I think now we have a much better chance to actually have it realised because we already have many of these parts built, and many people are already using this, and we do see a really good opportunity to build this foundation for more exciting future possibilities, right? These things don't necessarily have to be built by us. It could be built by you on top of the stack that we provide, so efficient interop between Rust and JS plugins, code instrumentation, advanced asset optimisations, and the reason we focus so much on performance is because you do need extreme performance to unlock the budget for you to actually do these advanced things. Otherwise, we are focusing on getting our builds fast enough to save CI minutes, right? Join us if you're passionate about the future of JS tooling, check out these projects on GitHub, and we welcome any form of contribution and involvement. Thank you. APPLAUSE.
The Vision, Sponsorships, and Protecting Trust
We have a vision to build a unified toolchain for JavaScript and the web, leveraging the existing parts we have. We focus on performance, interop between Rust and JS plugins, and advanced asset optimizations. Join us on GitHub and contribute to the future of JS tooling. In the early days, sponsorships and Patreon support helped sustain us, and now we have stable donations and partnerships. Unfortunately, the hoodie I'm wearing is only available to team members. To raise awareness about our open source projects, I used to tweet a lot and actively participate in discussions. We acknowledge the problem of bad actors embedding malware in the open source community and encourage vigilance to protect the trust we have built.
Pretty much the vision that Rome was originally created for, but somehow never achieved. I think now we have a much better chance to actually have it realised because we already have many of these parts built, and many people are already using this, and we do see a really good opportunity to build this foundation for more exciting future possibilities, right?
These things don't necessarily have to be built by us. It could be built by you on top of the stack that we provide, so efficient interop between Rust and JS plugins, code instrumentation, advanced asset optimisations, and the reason we focus so much on performance is because you do need extreme performance to unlock the budget for you to actually do these advanced things. Otherwise, we are focusing on getting our builds fast enough to save CI minutes, right? Join us if you're passionate about the future of JS tooling, check out these projects on GitHub, and we welcome any form of contribution and involvement.
Thank you. APPLAUSE. We have gotten some of your questions. You can still send all of your questions to Slido, please. We've gotten quite a few, so I hope you're ready. First off, people want to know how do you make a living as an open source dev? You mentioned sponsorships a little bit, but how did you do it in the early days? It's mostly sponsorships. In the early days, there was a friend who was a CTO at a company called Strikingly, and they're a big Ruby shop and they've been involved in open source for a long time. When the CTO was my friend, and when he heard about my plan of doing more open source, he decided that the company would put their open source support fund to support me for six months, so that really helped in the early days, but then I started to get, I think, when I decided to do it full time, I had about $1,500 a month from Patreon. And, luckily, it just kept growing over time, so now we have a pretty stable source of donations from sponsors and we also have partnerships with people who create paid content for Vue, and then we collaborate with some companies who are building commercial products on top of Vue, so there are combined different sources of these. Multiple sources.
Great, thank you for that. The next highest rated question was, where can I get this awesome hoodie that you're wearing? This one? Unfortunately, it was made in small batch only for the team members, but if people want it, we can maybe ... Contribute a little bit more and maybe ... We will probably make it, yes. Another important question. At the beginning, how did you make sure that you could raise awareness about your open source projects? Tweet a lot. Tweet a lot! I don't tweet as much as I did in the early days, but I think when I just first started out on Vue, I would just jump into every Hacker News discussion or Reddit discussion about front end stuff and try to get myself seen, but I no longer do that, but in the early days that's probably the lowest cost of way to doing it. Right, thank you. Then, we've recently seen bad actors embedding themselves into open source community to deliver malware. What is your view on this problem? Sorry, what is the question? To deliver malware. I think this is definitely a concerning problem. There are a lot of things in open source that's built on top of goodwill, and we just assume people are nice, so that kind of opens up loopholes for bad actors. It's unfortunate because people will abuse the goodwill of the open source community and force us to be more cautious, and then corrupt the trust that we have built along the ecosystem. It's sad, but I think, since that has already happened, people have just to be more vigilant. We've actually gotten outreach from the JS Foundation about some things that's related to Vue in the past as well. I think, as maintainers, we just have to be more vigilant, and as users, you can also help by reporting whatever you think is suspicious.
Testing, Community Alignment, and Web Assembly
Testing with VTest is an important part of the toolchain. Vue's direction is determined by the needs of the community, not by individual sponsors. Accepting different opinions and contributions is important for the success of frameworks. Web assembly is not included in Vue due to performance and complexity concerns.
Thank you. Definitely a concern. Let's see, which one? Right, let's do this one. Isn't testing missing in your vision? I didn't include VTest in the graph, and I apologise to Vladimir, who's the lead maintainer of VTest. But VTest is a very important piece of the toolchain as well, and it'll be able to leverage the same underlying parts that we're building for VT, because VTest is built on top of VT. Yes. All right, perfect, so shoutout to them.
With a growing community, sponsors and other stakeholders, how do you align on new ideas and determine the direction that Vue is heading towards? We mostly focus on the needs of the community. The thing about Vue's sponsorships is, we don't have these single big sponsors that would be able to dictate the technical direction of Vue. The source of sponsorships we get is very evenly distributed, so no single sponsor actually has a say on what we should do next. It's pretty much no strings attached, and we're very explicit about it, so if you sponsor the Vue project, we won't really do anything special just for your needs. We want to be mostly focused on what the users need, and trying to also gauge what the general trend of where the ecosystem is moving towards, so we want to make Vue stay modern, stay competitive, but also focus on the real problems that are reported by the users.
How difficult was it to let go and accept that other people have opinions and also want to contribute to your projects? I think in the early days, definitely when I first started out, you tend to think, of course my framework is the best, and anyone who thinks it's not the case is wrong, and I will debate them on the internet, but, you know, after a few years, you realise the web is very huge, the ecosystem is huge, it's very diverse, people have different opinions, people have different preferences. Some people come from a Java background and they just like things that look like Java. Some people coming from a functional programming background, and they just want to have functional components, and some people starting with simple HTML CSS will find Vue more familiar and more friendly to get into, right? So I think it's really futile to try to convince people who are just not your target audience to agree with you, and I think that's pointless. The goal for all these frameworks to co-exist is for each of them to find their happy audience, so that their users will be on a happy path with their chosen framework, and everyone gets more productive. I think that's the good outcome we want to see, right? So it's not about converting people who doesn't even like your stuff to become a user. That's pointless.
How do you see the future of Vue? Do you have any web assembly inside? Unfortunately, no web assembly. I think people have asked about would you allow people to write Rust and let it run in the browser. I think in general, the performance scale that we've seen from all the experiments just doesn't really justify the complexity added on top, especially when you think about Rust compiled to or other languages compiled to web assembly, it's already slower than actual native binaries and it's also not really comparable to the real native level performance you'd want. And then there's the overhead of communicating between web assembly and the DOM because the DOM is always going to be there and it's always going to be a major bottleneck. And then, for example, if you run virtual DOM diffing in the web assembly thread, there's a lot of data you will need to pass between web assembly and the JavaScript main thread, and that's the realisation of the cost offsets a lot of the performance gains, and now you're left with a lot of extra complexity in your build set-up and distribution, but not really noticeable performance gains for probably the most day-to-day use cases. There are good places where, for example, you want to do video encoding in the browser, you probably should, you know, leverage something like web assembly, but using it to write your day-to-day component code? I don't think that's a good idea.
Thank you so much for answering all of these questions, and thanks, everyone, for asking questions. Please keep asking everyone questions throughout the event. This is great.
Comments