Season 7 Episode 2 Nov 17, 2021

The Story of Vue with Evan You

Pitch

Look up at the sky! It's a library! It's a framework! It's Vue!

Description

In this episode, we talk about Vue and its creation with its creator, Evan You.

Hosts

Ben Halpern

Forem - Co-founder

Ben Halpern is co-founder and webmaster of DEV/Forem.

Christina Gorton

Forem - Developer Advocate

Christina Gorton is a Developer Advocate at Forem. She is a LinkedIn Instructor and technical writer.

Guests

Evan You

Vue.js / Vite - Project Lead

Evan You is an independent open source developer and is the author / maintainer of popular projects such as Vue.js and Vite.

Show Notes

Audio file size

39995849

Duration

00:41:40

Transcript

[00:00:00] EY: If I look back the first version of Vue that I wrote, the code is really, I don’t know, by today’s standards, it’s very all maintainable.

 

[00:00:20] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all of our lives as developers. I’m Ben Halpern, a Co-Founder of Forem.

 

[00:00:27] CG: And I’m Christina Gorton, Developer Advocate at Forem. Today, we’re talking about Vue with its creator avenue, Evan You. Thank you for joining us.

 

[00:00:35] EY: Thank you for inviting me.

 

[00:00:37] BH: So Evan, really awesome to have you on the show. Can we start off having a little bit of background about you? I’m sure a lot of our listeners are familiar with a lot of your work, but may or may not know some of your origin story or Vue itself or anything like that. So please feel free to fill us in.

 

[00:00:56] EY: Sure. I was born in China, came to the US for college, then stayed here. So when I graduated, worked a bit at Google and then a startup called Meteor. And in 2016, I decided to go full independent to work on Vue.js full time. So now I’m an independent open source developer, and I’ve been doing that for over five years now.

 

[00:01:22] CG: And in 2014, that’s when you really spew. Right? Okay. So for those in the audience who may not know exactly what Vue is, can you describe to us what it is and maybe compare it to some of its competitors?

 

[00:01:35] EY: So Vue is a JavaScript framework. So I would say the two core features of most modern JavaScript front-end libraries or frameworks that typically provide is, first of all, you declaratively describe your templates or JSX or whatever, essentially declarativeness, you’d no longer manually mess with a DOM anymore. Right? And the second is managing state. So you have some states. You need to change them. And when you change them, you want your DOM to update automatically. So at the very core, that is what Vue attempted to solve in the very beginning. So initially, I called it a library. But nowadays, I agree, it’s actually a framework now because we cover a lot more in the sense that we have build toolchains that allow you to build more sophisticated stuff, for example like single-page applications, full stack stuff with server-side rendering or static site generator. So it covers a lot more in that sense. And I would say the most defining part of Vue is that it’s designed to be really flexible and incrementally adoptable. So for example, we have a lot of users who just got into front-end development or who are primarily back-end developers. Okay? They don’t necessarily know a lot of JavaScript or want to know a lot of JavaScript, but they can still get some job done with Vue even without build step. On the other hand, we also have folks who are really invested into front end. They’re building really complicated stuff, but they can’t actually do that with Vue as well. They actually do it with a full old pipeline with single page routers, typescript, all the fancy stuff, unit testing. Right? So Vue, as a framework, kind of allows you to scale between one and two all the way to the other. And we try to be as flexible as possible on a spectrum.

 

[00:03:30] BH: This sort of brings up our journey of how we even got you on the show and I’ll sort of speak to that a little bit. So I think the first topic that came up in our little discussion was we wanted to have someone on to talk about framework creation in general. This sort of conversation went, “Are we talking about frameworks or libraries?” Eventually, we got down the path that like, “Either way, let’s have Evan on.” Because from my perspective, you’ve been willing to understand that maybe it’s a library, maybe it’s a framework, and maybe it’s not that important or maybe it is important. How much does that matter to you? Or how much do you think that should matter in general?

 

[00:04:13] EY: So I think that the most defining difference between a library and the framework is that when you use a library, the user intends to decide the architectural problems, like make architectural decisions themselves. So a library is just a piece of the puzzle that fits into an architecture that the user wants to create. Framework essentially brings its architecture to you with it. Right? So if someone is adopting a framework, they’re essentially agreeing with the architectural decision the framework is making. So it really depends on what the user is looking for. Right? It’s not about which one is better because in some cases you may have very niche use cases where you’re like, “I have a very specific architecture I have in mind. I’m just looking for a library that fits this exact piece of the puzzle.” But on the other hand, some users, maybe they’re like, “I don’t want to make any decisions. Just tell me what to do. I want a framework that just solves every problem for me.” Right? These are all very legit. They’re both legit needs. So there will be different tools to cater to these needs. So on one end of the spectrum, you have React, which is a library. And despite how most people use it today, React itself really doesn’t concern itself with too much of, say, how do you set up your build tools or whether you do server-side rendering on them. Right? Those are kind of handled by metaframeworks like Nix. So React, in itself, it is still a library, but Angular is strictly a framework. It kind of dictates how you build stuff, how you organize stuff, how the whole architecture fits together, right? Different users will kind of be evaluating that based on their needs. So Vue essentially tries to be flexible in this definition because our core can be thought of as a library. But if you want a framework-like setting where you have build tools, linters, test runners and everything. We actually have that too. So it’s kind of a spectrum.

 

[00:06:21] BH: So seven years ago, when you were first starting Vue, what were your expectations for the project? Did you see yourself working as a full-time open source maintainer? Where was your head at when you got this going?

 

[00:06:36] EY: Definitely nothing ambitious. The initial motivation for creating Vue was just scratching my own edge because I wanted something that’s really simple and lightweight for my own personal projects. And we were using AngularJS, the original Angular in some of the projects we were working on at Google. And actually, the department that I was working at was called Creative Lab. It didn’t mandate what framework we should use. So some of my coworkers used Angular in one of the projects. I tried it. I was like, “Some of those stuff that I like, essentially the part where you just write templates, write your states and everything is kept in sync automatically.” But I just felt for my own personal use cases I really didn’t need all the concepts about controller or dependency injection, all that stuff. So Vue was essentially an attempt to say, “Let’s write something that only does these two things, mapping some stages to a template and just keep them in sync automatically,” and also wanted to do it using ES5 getters and setters. So back in 2014, people still wanted to support IE8, which didn’t even support ES5. So the decision to go with an ES5 only feature was kind of you’re essentially saying, “This won’t support IE8 forever.” Kind of like dropping EI11 today, but I kind of always liked that, just using the new features in a fancy personal project. So that’s really how it started. The rest is really organic growth. Like every couple months, there will be a surge of new users discovering it, and then I didn’t really put in time very consistently in the beginning. It’s really like when there are a bunch of new users, then I notice a bunch of issues, discover a bunch of ideas that I could incorporate, then I would maybe have this surge of commits that just push out a new version occasionally. It really kind of grew. Basically the more users I had, the more time I spent on it and it kind of just snowballed from there.

 

[00:08:47] CG: So you talked about some of the challenges you were trying to solve by building Vue. It was kind of a personal thing. What were some of the major challenges that you faced while you were building Vue?

 

[00:08:57] EY: So I think the most interesting part is I grew as a developer myself as I was working on Vue. Because if I look back the first version of Vue that I wrote, the code is really, I don’t know, by today’s standards, it’s very all maintainable. We didn’t have bundlers back then. We basically use a lot of outdated patents to simulate classes or the old tricks that we used to pull before we had native ES modules nowadays. So essentially, I have completely rewritten Vue maybe three times up to this point. Every time it’s kind of like, “We accumulate all these new ideas that we learned along the way.” And I felt like, “Okay, now I have a better idea of how to organize this whole piece of things so that it stays maintainable for the longer run.” I think Vue 2’s codebase stuck around for like four years, which I think is pretty good. But the challenge actually becomes over time when you have more users, when you have more historical burdens, you have the past positions, all the past technical debt that’s there in your framework and they won’t go essentially. Every time we publish a new major version, we try to get rid of some of the old stuff that we consider no longer good. But there will be some users who strongly get attached to it just because they use it and people don’t like things being taken away. And they’ll push very strongly back. And they’ll be like, “If you remove this feature, I won’t use Vue ever again.” So a lot of times, the challenge becomes just how to figure out the best way to move forward with all the past decisions you’ve made. Some of the decisions maybe you kind of want to throw away now, but you also need to balance it between the actual needs of your users, like how are they actually using it in the wild. I would say over time, the biggest challenge just becomes how to make decisions, how to balance what you want to achieve technically versus what the users want, how your framework is actually being used in the wild. It becomes a very complicated topic.

 

[00:11:11] BH: How do you set expectations for deprecating features or just doing stuff that you think is right that the community is going to disagree with?

 

[00:11:19] EY: We now have a formal RFC process. Essentially, if we want to make really impactful changes, we will always come up with an RFC first, then collect user feedback. And if a lot of people disagree with it, we probably won’t try to force it through. But a lot of times, if we believe this is really for the good in the long run, we would try to argue with people. I mean, not argue in a bad way, but try to argue with reason. I guess that’s the original purpose of the RFC is you use a long form proposal to outline the motivation, the pros and cons of doing this, and why do we need this, why is it worth it. This process is essentially a self-enforced to think through these problems, to be honest with yourself before you try to push it onto others. And I think it’s kind of necessary when you have so many users, you want to make sure you give them a chance to voice their opinions too.

 

[00:12:19] BH: And you manage your own sense of importance in the project, like yourself, I would imagine. So maybe there’s a lot of people who would really trust everything you have to say because they really believe in your work and then maybe some people don't trust you as much as they should because they haven’t bought into your insight. Where do you feel like the challenges and just navigating some of that stuff, like how much people should listen to you versus debate the RFC themselves or where you fit into the team now? Give us a picture on that front.

 

[00:13:01] EY: So if we were to describe the governance model, it’s still kind of close to BDFL, essentially the Python model where you have a benevolent dictator for life, and in a way it’s because when we compare, say, making decisions as a committee, you really can’t move that fast. And for any project like Vue, we’re not, say, backed by a huge corporation where we have all day to just sit in meetings. So a lot of times we still need to make decisions, make calls, and be able to ship stuff while being very loosely organized as a team. So I think having someone who’s still able to sort of set the vision and call the shots when necessary, I think it’s kind of a balance that you need for certain types of projects. It really depends on the scale of the project and how the team dynamics work. But I think so far, it has been working out pretty well for us. I try to delegate some of the sub areas to our team members, for example, like the router, the dev tools, our CLI build tools stuff. I pretty much delegate them a hundred percent to some of our team members and occasionally sort of communicate in our team meetings, but I trust them enough to just let them handle it. And on the other hand, they trust me to sort of make these high-level decisions on where we should go next. Of course, we also have sometimes even intense internal discussions, like when I propose something, there will be team members who disagree with it. So we kind of need to sort it out inside the team first. And I will never try to say, “Because this is my decision, you’ll have to agree.” I always try to sort of reason with them and try to make sure everyone at least agree that this is something they are okay with. And ultimately, the dynamics is in a sense like how you run an open source project. Right? Sometimes the maintainer of an open source project may make decisions its users disagree with. And the worst-case scenario is the maintainer will lose trust and the users will fork the project and just do things on their own. So even though it sounds like a BDFL is kind of like a dictatorship, if you read the original document that kind of describes this model, the BDFL actually still has the responsibility to make sure he listens to not just the team members, but also community feedback. Because ultimately, this person is responsible to the trust that all the community has entrusted on him. If I don’t do my job, I will lose trust and someone maybe will fork Vue into something different. And I think that’s an interesting power dynamics. I’m kind of just figuring it out myself as I go along. And I think so far it’s been working kind of okay, but really I don’t have enough to say that I can write a book with authority on this topic because I’m just someone who is doing this stuff while figuring it out.

 

[MUSIC BREAK]

 

[00:16:23] CG: What would you say are the major differences between Vue of the past and Vue now?

 

[00:16:29] EY: We did a lot of improvements in Vue 3 centered around TypeScript, IDE tooling, and composability. So Vue 3 introduced something called “Composition API”, which on the surface looks kind of like React Hooks. So the most powerful thing about React Hooks is you can write your own custom hooks to encapsulate any kind of logic. So Composition API essentially allows you to do that, but with a kind of different mental model, because it’s still rooted in how Vue treats state. It’s about mutable reactive states. So you have an object which you have some state, which is the source of truth. Then you sort of have chain reactions built on top of them whenever things change. So ironically, because people kind of think of React is reactive, but I think a lot of other libraries, including Knockout, Solid, Vue or Scout tend to think of reactivity to me when you change state. It’s a push-based mechanism, whereas React is more like a poll-based mechanism where it’s kind of simulating reactivity by repeatedly calling all these hooks. But with Vue, with the Composition API, you’re only setting up everything once. You’re essentially declaring the reactive graph once and then let the system do its work. The subtle is it’s kind of hard to dig into by just talking about it. But on the very high level, it's quite a different mental model when you actually try to use it, but it kind of has very similar composition capabilities. We have a community project called VueUse, which encapsulates a ton of very useful composition functions. So the naming combination is kind of similar to hooks. We have like use media query, use dark mode, use this, use that, but all using Vue’s APIs. This new API is also essentially written with a type inference in mind. So it works with what’s really well with TypeScript. We also greatly improved our IDE tooling. So if you use TypeScript with Vue now, you even get full type checking, props auto-completion, and all that inside your template, not just your script part. It almost feels like TSX. We are actually working on a major overhaul of our docs to sort of highlight some of the new stuff that we’ve introduced over the years because our current docs is a bit outdated in terms of how the features are presented.

 

[00:19:08] BH: Telling folks that docs are out of date is probably the most evergreen statement no one can make in software development. It’s probably something that’s always on all of our minds, the awareness that parts of the docs are out of date and it’s easier said than done to reconcile that. Where do you see the Vue project and sort of the universe of development that you do? If you want to speak to the other work you’re doing, Vite, where do you see some of these projects in maybe five or six years? So like a longer horizon, then maybe you’re thinking about for the most part. So you’ve been doing this for about seven years. Nearly that long in the future, do you anticipate certain evolutions or are you not thinking that far ahead?

 

[00:20:00] EY: So I think Vue’s development model is still pretty good in the sense that we are still trying to polish a lot of small stuff here and there. But honestly, I think the way that we develop modern UIs today, like you have some state, you have some declarative templating system that updates the DOM, I think this model is pretty sound. There will be new solutions coming out, but I doubt that within the six or seven years’ time span, there will be something to be able to challenge our script in terms of dominance on UI development just in general. Some of the more interesting stuff I’m thinking is in the tooling space, where compared to native languages actually have a better chance of replacing JS based tooling. One of the interesting stuff is, for example, for a language like Rust, when you talk about application layer code and tooling layer code, the trade-offs or the things we optimize for is completely different because when we talk about front-end applications. Correctness is in fact sort of, I wouldn’t say it’s not important, but compared to tooling layer or security layer, it’s fine if you have one or two runtime errors. The users, worst-case scenario, the user just refreshes the page, but the more important part is you want to be able to ship stuff on time. So a lot of times as developers, we optimize for efficiency over correctness when we are thinking about web UI development. This is kind of part of the reason why I believe why functional programming just never caught on in front end space. There are diehard users who prefer that. But at the broader scheme of things, most developers still kind of emphasize efficiency over correctness. But when you move to the tooling layer, it kind of becomes different because now performance and correctness pays off much more compared to how fast you can build some tools. Right? Because when you have infrastructure level tools, the need doesn’t change as often. You don’t crank out the new tool every two months or something. So you want to invest the right amount of time to make sure you build something that’s robust, fast and performant. So this is where it makes much more sense to opt into a language like Rust or Go to build a piece of tooling so that if it can be hundred times faster than the JS equivalent, that’s a much better trade off. So this is why I don’t think WASM will cause JS to lose its dominance in the application layer, but it is definitely possible for more and more tools to start to leverage WebAssembly or Rust or Go compared to native binaries.

 

[00:22:56] BH: And are you anticipating some of this in your work, like trying to stay flexible for a shifting future? Or are you sort of punting on some of that?

 

[00:23:07] EY: I try to stay flexible, right? So Vite in itself already leverages ES build and under the hood. And essentially, we’re using ES build in a way that we’re just using it in parts where it makes sense. So if necessary, we can even swap it out for something else, but ES build just does such an amazing job and it’s so performant. It just fits into Vite very well. And on the other hand, say for Vue itself, we actually have some community members exploring, writing the Vue template compiler in Rust, which is pretty crazy. I also know someone who’s working on replicating Rollup with Rust. If these projects materialize and stabilize, because Vite currently uses Rollup, we can sort of combine this Rust-based Rollup with ES build to swap it out inside Vite. And then in the Vue stack, we swap out our compiler with the Rust compiler, then everything just becomes faster, but the higher level development model doesn’t need to change for the end user.

 

[00:24:10] CG: So a lot of people when they think of Vue, they think of it as a framework that was created with beginners in mind, right? Like it was kind of made a little bit simpler. How have you tackled making Vue more sophisticated over time, some of these things we were just talking about, while trying to maintain the simplicity that it’s core mission?

 

[00:24:28] EY: Yeah. It’s definitely a challenge. Right? So one of the costs that we have to pay at this point is when we introduced Composition API, some users find it a bit harder to grasp than our original options API, but we’re not removing the options API. We’re still keeping it. And we’ve discovered that these two kinds of APIs kind of catered to different types of constraints that the users are facing. We’ve actually had people who’ve been, say, in a team with a bunch of very entry-level developers who just barely learned JavaScript, but they’re still able to use the Options API quite efficiently because Options API is designed to sort of be hand-holding forward to some extent, right? It has better guardrails. So you kind of have to put things in the right bucket for things to work. Composition API on the other hand is more freeform. So it’s more like you need to know what you’re doing, but once you know what you’re doing, you have a much higher ceiling in what you can achieve. You can write higher quality code if you want to. So in a sense, these are two APIs, one with a higher-lower bound and lower-higher bound. And the other one, you can write really shitty code, but you can also write really, really good code. So it’s an interesting coexistence of the two styles, but we believe that with more ergonomic improvements in the compile step, we can make the Composition API more approachable to the point where entry-level developers can also use it efficiently without shooting themselves in the foot. So that’s kind of something we’ve been trying to still achieve. But for now, beginners can still use the Options API. It’s not going anywhere. We even came up with a thing called Petite Vue, which is an alternative distribution of Vue, that it’s a subset of Vue core features, but it’s made even simpler. So essentially just give it an object of stuff and you can use Vue syntax to render it. It’s very small. So it’s optimized for the cases where you really don’t want any complexity. You just drop the scripting and go.

 

[00:26:43] BH: Since you build new APIs and shift some subtleties around old APIs, drop a few things here and there, replace components, do you ever face a moment when you question whether you are still building Vue, like what is Vue? How much can I change while it’s still recognizable as Vue?

 

[00:27:06] EY: Definitely. There are moments like that, but the core thing that convinces myself is when I write the code, right? I know I’m not changing anything fundamental. Say Composition API, when we introduced it, a lot of people think, “Oh, you’re completely changing how Vue works.” The reality is we are really just exposing some of the internal function that’s always been there since Vue 2, right? Options API is in fact more like an encapsulation on top of Composition API. So if you think about the framework with layers, Composition API is the primitive functions that you can call directly to create reactive objects or set up reactive effects. And Options API is just a layer on top of it to make things easier. So when we built Vue 3, we in fact essentially defined the Composition API or the Reactivity APIs first, then we built Options API on top of it. So essentially replicated Vue 2’s API on top of this new layer with a couple of hundred lines of code. So when we were able to do that, we know the fundamental part about how Vue works internally. It doesn’t change. It’s really just how you expose new capabilities in a different way. So there are different interfaces to the same underlying system and all the new stuff that we introduce, the framework kind of follows that principle. So that we know even though we’re giving you new syntax or a new sugar compile time stuff that you can leverage, the underlying system, how reactivity works in Vue is still the same.

 

[00:28:44] CG: So we talked a little bit about how you all go about deciding some of the features with your RFC process or you might drop things if you don’t take stuff, what have been some of your most favorite or most successful components that you all have at them?

 

[00:28:59] EY: One of the recent successes was the script setup, syntax, and our single components. Previously, when you use Composition API, one of the major complaints users had was or both because you have to manually return all the properties that you want to use in the template from a function. So essentially, you have to, say, first declare something, declare an object, then you have to return it, then you can use it in the template. So the script setup is partially inspired by Svelte where now we essentially expose everything you declare in the script setup log directly to the template. So it’s as if the template is running in the same function scope as all your setup code. The mental model becomes a lot easier. And in fact, in production, we do compile it to the same. We do compile the template as an inline function alongside your logic code. So they are in fact in the same function scope. So the mental model essentially checks out with how it’s actually going on in production.

 

[MUSIC BREAK]

 

[00:30:27] BH: What one moment of interaction with the community has been the toughest? So we’re talking about a lot of wins and improvements and stuff, but there’s been some bumps in the road in terms of buy in and you spoke to this a little bit, like people angry, I’m going to leave you in this circumstance. Personally, what’s been the toughest where you had to really act with a lot of conviction?

 

[00:30:53] EY: The toughest one is definitely when we were initially introducing the Composition API for Vue 3. It’s kind of a long story because initially the motivation of introducing a new API was to improve TypeScript support because Vue 2’s options that API was essentially designed without any type of inference in mind. We were able to get some level of type inference for the API by writing extremely complicated types. If someone’s interested, you can check out the types that we do for the Options API type inference. It’s a piece of, I don’t know, I should call it a piece of art or just a monstrosity, but it’s a lot of complicated types. So essentially, we were trying to come up with a different API that just makes type inference natural without having to do all these kinds of crazy hacks. And the initial attempt was to use classes and then we tried classes for a bit, and then we discovered there are issues, essentially, say, when you use classes with Angular, you need decorators. If you don’t have decorators, the DX is going to be not quite there, but decorators were not stable. So when we were designing the new API decorators, we’re just undergoing another major overhaul. The previous proposal was just completely dropped, replaced with something completely different. And that really kind of made us uncomfortable going ahead with classes because it’s kind of dynamic because if you want good DX, we need decorators, but decorators are just really not in a good shape around that time. So we looked at other options and then it was also around the time hooks came out. I think hooks came out a few months before that. So I basically played around with it, trying to see if we can do some of the hooks-like composition with Vue’s reactive primitives, and it turns out it kind of worked. So we pushed out the new proposal. And I was a bit overly enthusiastic about it. And I was like, “Hey, this is a new API. We can even drop the old one.” And that really triggered people. Because as I said, people don’t like things that work being taken away. So few users really took that seriously. They believe that we are going to push this new API and completely deprecate the old API and pulled an Angular 2 essentially. So that was probably the hardest moment when we were trying to sort of remedy this damage because people are already kind of spreading the word saying, “Hey, Vue is going to completely change. Everything you know now is going to be obsolete.” We kind of have to, first, convince them that, “Okay, we’re not going to take away the Options API. This is still going to be the main way to do to learn Vue and use Vue.” And second, we also have to convince people that having this new API is actually a good idea, because to a lot of people, the moment they see something that looks like React, they just have this knee-jerk reaction like, “Oh, Vue is becoming React. Oh, I don’t. I just use React.” Right. But there’s really a lot of technical subtleties that you have to look beyond the surface to understand why is it different. And sometimes when you are caught in this kind of feedback storm, you kind of doubt yourself and think like, “Am I really just coming up with kind of a React-like thing? Or is this really something that would be really useful?” Now I’m kind of glad I pushed through because we have a lot of users who have migrated to this, especially with the script setup, they’re now being really productive with this new API and TypeScript. And most importantly, this kind of unlocks a problem that we’ve had with the Options CPI is you can’t easily extract, organize, and reuse complicated logic in a large application. And this is what a Composition API kind of solves perfectly. And this kind of achieves one of the goals of introducing the new API is to give you this new option that has much higher scaling ceiling, much better TypeScript integration, and also unlocks this sort of community-based reusable, composable utilities that we are now seeing today.

 

[00:35:17] CG: Yeah. I definitely remember when all that talk was going on. I remember seeing it back and forth and I’m sure the inside internally, it was very difficult for you, but I remember seeing you responding to people in a way. I think you handled it really well at the time.

 

[00:35:33] EY: Thanks.

 

[00:35:34] CG: Something else I think you do really well that I’ve seen over time is that you’ve talked about where Vue is like good to use and where other frameworks might be good and things like that. So as of like today, and the way Vue is now, what do you feel like it’s really good at? And what are some things that another framework might be a better choice for?

 

[00:35:53] EY: I think Vue is sort of a jack of all trades. I think that its biggest strength is if you go with it, there are very few cases where Vue is a really bad choice I would say. There are specific cases where certain frameworks would be a better choice. For example, say, you’re shipping a one-off web component that needs to be really lightweight then something that sort of have advantage when you very small amount of components with small size, something like Svelte or Preact will probably be a better case for those. But other than that, if you’re building a full application, I think Vue can pretty much fit the bill for most of the use cases you can come up with on the technical side, obviously. So I think a lot of cases in the real world, some of the most driving factor for people is in fact, like, the job market or how easy you can hire people. So that is kind of out of our control. But in that aspect, I usually just say, “Vue is easy enough to just train people on the spot.” Because if you know JavaScript, you should be able to learn it really fast.

 

[00:37:03] BH: Do you set goals in terms of adoption rates or anything even bigger? Do you take into account how many job listings there are in Vue, like anything? Do you pay attention to anything outside of the core usability or anything like that?

 

[00:37:24] EY: Maybe I check it when there’s a new survey coming out. For Vue, I don’t really actively check the numbers anymore because it’s grown so big that our primary goal is no longer more market share, more dominance. The goal is to make sure we push out changes that make our existing users more productive. And also, if we can make it easier for new users, of course, that’s a great bonus too. But the cool thing is we are not operating as a for-profit company. We don’t have investors that we need to show our growth report to. So in lot of cases, the only thing I’m reporting to is, do I think Vue users are happy today? If they are, then great. And if our users are happy, then likely there will be more users coming too. So I think this is also one of the reasons why I didn’t want to make Vue a startup or a company and take investments because I just feel the project started out to really just to service users. And if you make it something commercial, it just distorts that sort of incentive and it would make, I don’t know, I just don’t think it’s going to be good for the project in the long run. Or at the very least, I want to make sure anything that’s sort of about making money or a commercial can be well decoupled from the main driving incentive of working on Vue. We want to make sure Vue is great. We want to improve it instead of work on it in order to make more investment returns.

 

[00:39:13] CG: So what can folks look forward to in the future of Vue releases? What are you excited about? What are the Vue community excited about? What could people be looking for?

 

[00:39:23] EY: One of the things we are working really hard on right now is the new documentation. It essentially has a completely new design, new implementation, and new content. We revised a lot of this stuff to highlight the new paradigms that we introduced in Vue 3. Obviously, I wanted to improve a lot of stuff regarding the new APIs. Right now, they’re kind of like, “Hey, here are the APIs. Just use them.” But I’ve always wanted to sort of write more detailed guides on how the best practice in the stuff. So we try to put that into the new docs as well. And the new docs itself is being built on top of this thing called VitePress, which is sort of the successor to VuePress. That’s a Vue-powered static site generator and basing a lot of really good defaults in there. So the site is dynamic, but also really performant. So once we ship the new docs, we’ll probably also push for a 1.0 release for VitePress. And then VitePress will also include some of the stuff that we’re experimenting with that will probably come in Vue 3.3 that pertains to improving server-side rendered stuff like lazy hydration or on-demand hydration, essentially focused on improving the hydration performance and maybe shipping less JavaScript. So this is an area that a lot of the frameworks are exploring right now. So we also have some ideas that’s probably coming in 3.3.

 

[00:40:57] CG: Very cool. Thanks again for joining us here today, Evan. We really appreciate it.

 

[00:41:02] EY: Thank you.

 

[00:41:12] BH: This show is produced and mixed by Levi Sharpe. Editorial oversight by Jess Lee, Peter Frank, and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, email [email protected] and make sure to join us for our DevDiscuss Twitter chats every Tuesday at 9:00 PM US Eastern Time. Or if you want to start your own discussion, write a post on DEV using the #discuss. Please rate and subscribe to this show on Apple Podcasts.