Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about frontend views and development. I'm Dave Rupert. With me is Chris Coyier. Did you see what I did there, Chris?

Chris Coyier: It was good.

Dave: It was good, huh?

Chris: Mm-hmm.

Dave: The best.

[Laughter]

Chris: With us is Evan Vue. Oh, sorry. I mean Evan You. [Laughter] Hey, Evan. I'm sure nobody has ever done that before.

Evan You: Actually, you're the first one.

Chris: Oh! [Laughter]

Evan: I'm surprised. I'm surprised.

Chris: I'll take it. Evan You is the creator of Vue, which is unbelievable and amazing. We're lucky to have you, so thanks for coming on, Evan.

Evan: Thank you.

Chris: Can we just get right into maybe a little introduction about yourself and Vue? That seems like, certainly, your major project these days. Yeah?

Evan: Yeah. I primarily just work on Vue full time now. I've been actually doing it for three years now.

Chris: Three years.

Evan: Yeah.

Chris: I'm sure it feels an eternity. That does to me.

Evan: Actually, no. It actually feels pretty fast. When I look back, it's kind of surprising it's already been three years.

Chris: Oh, wow.

Evan: It feels like I haven't been working on it that long. I guess that's because I actually enjoy working on it, so it's not like when you are working on a job you don't like; it feels like an eternity, but this is not the case.

Chris: Yeah. You love it. Well, that's a good feeling to love the project that you're working on. Vue is often mentioned in the same breath. I don't know if you like the word "framework" or not. Probably it doesn't bother you too much.

Evan: It's fine.

Chris: Yeah, I know React people are sometimes like, "It's not a framework," but whatever.

Evan: [Laughter]

Chris: It's mentioned in the same breath. People are like, "In a JavaScript framework like React, Angular, or Vue." I don't know. Some people say, "React, Vue, Angular." The order doesn't matter, but it's used for that same -- I don't know. It's used if you're building a JavaScript-powered app. You may choose a JavaScript-powered framework to run that app. React is a big dog, but I'd say Vue is dang near second place, if not second place these days, and growing.

What's unique to me about Vue is that literally everybody loves it. [Laughter] If you meet a Vue person, they're in love. No? Have you found that not to be true?

Evan: Right. I've had plenty of -- I mean a lot of diehard React fans, they're like, "Oh, template strings. Horrible." [Laughter] You know?

Chris: Oh, okay. Okay.

Evan: Yeah, people who actually use it mostly love it, so that's good.

Chris: What is it? Can we just do that? Yeah, I think a lot of our audience probably knows, but it'd be nice to hear from the creator how you think of Vue. What is it and what is its place in the world?

Evan: Sure. Today, I actually call it as a framework proper because its scope has expanded from the original definition of just a view layer library. We've now expanded to include a routing solution, a state management library--

Chris: Mm-hmm.

Evan: --an actual CLI with a build toolchain and a lot of dev tool extensions, so it now encompasses a wide range of things that work together as a framework, but we try to take a more progressive approach where we don't force you to use everything all at once. Instead, you can just pick the core if that's really what you just need.

Chris: Mm-hmm.

Evan: Then, if you're building something more complex, you can opt into the additional stuff. That's the high level idea--

Chris: Yep.

Evan: --of what the progressive framework is.

Chris: Do you think of it as component-based too? I guess I think of React in that way is that what you are building are components that deal with each other in some way. Is that the Vue--?

Evan: Yeah, I think component is pretty much the common standard among all the most modern frameworks, right?

Chris: Mm-hmm.

Evan: If you look, Angular has components, Ember has components, Vue has components and, conceptually, the work very similarly to one another. React probably is the one that they have come up with a lot of interesting patterns of just using components for unconventional purposes. But, at the core, the conceptual model of these components among these frameworks share the same idea where a component renders something. It contains a bit of state and it can respond to user input.

Chris: I can see that being massively appealing to people choosing a library is that, is what you mentioned that Vue has this routing solution, state management solution, and all that. I always find that these frameworks, they need those things anyway so that if you're left with React, now it's your choice. I need to choose a routing solution and maybe there's a clear winner. That's great if there is, but there often isn't.

Then you're like, "Oh, no! I'm forced with this extreme burden of having to choose one. What if I choose wrong? Will I shrivel up and die?"

Then not just that choice but, also, what's going to be my styling choice? What's going to be my state choice? What's going to be my offline choice, in a way?

It seems like Vue has strongly chosen for you. Please use our thing or you can only use our thing. I don't know.

Evan: Actually, Vue takes the middle route, right? If you look at, say, Angular or Ember, these are more convention over configuration where they pretty much say, "Please just use our thing. We've designed everything for you and this is the way you should do it."

Vue's approach is more like, "We have a blessed approach. If you don't know what to use, you should just use it. But if you have strong opinions on what you really want to use, you can actually ditch the so-called official solution and just use something else you've built yourself." The whole framework is structured in a way that these official solutions are not mandatory.

Chris: Oh, okay. It really is middle ground. Dave, you've been using it lately, right?

Dave: Yeah. I started a Nuxt project, which I would be curious what your viewpoint on Nuxt is. [Laughter] It seems like Vue with a few more rules, sort of, or conventions around it.

Chris: Is Nuxt blessed, as you put it, or not quite?

Evan: It's not really an official project, so it's not maintained by me or the core team, directly, but it is an important piece in our ecosystem because it gives you this out of the box, higher level framework that's more opinionated but also solves more complex problems for you. I would like to think of it as, if you think about the framework as layers, Vue provides both these underlying pieces or building blocks and a loosely opinionated layer.

Nuxt is this higher level thing where it's more strongly opinionated but, also, because of this strong opinion, it is able to provide a smoother experience, for example, when you're working with server-side rendering. Server-side rendering is a particular thing that Nuxt is trying to solve. If you're trying to manually set up a server-side rendering app with Vue, that's going to actually be pretty complex. There are a lot of things involved. You need to use Node.js. You need to use a Web server. You need to set up the build process properly.

Nuxt pretty much covers all those for you. If you use and install Nuxt, you're opting into all the conventions Nuxt enforces. But, at the same time, you pretty much get a zero effort server-side rendering app working out of the box. That's a tradeoff, right? If you want more control, you might want to dig into how to actually manually set up everything. But if you're happy with what Nuxt provides, it's definitely the easiest way to do server-side rendering with Vue.

Dave: Yeah. I come from kind of a Rails background or, even before that, Kick PHP used that as well. I kind of like that MVC sort of like, "Hey, hey. [Laughter] Don't just make up folders. These are actually what you should name your folders."

I feel like Nuxt gives me that. Vue, I think you culturally probably have some conventions, but Nuxt sort of reinforces those. It says this is actually where the folder where your components go. It's called components, so use that one. [Laughter]

Evan: Yeah. It's also part of the thing because our effort in Vue core mostly focuses on -- you know, there are different use cases for a framework. Some people just import, use it to enhance a primarily server rendered app, a traditional server rendered app like a Rails app or a PHP app, where they are just adding some interactivity to a frontend. Some are actually building a single page application that talks to the backend. Some are building a full stack, server rendered app.

Vue core mostly focuses on the first two use cases, that is, enhancing a legacy app or building a proper single page application. Nuxt pretty much covers the full stack server-side rendered app approach.

I think it's good to have them because the Nuxt team, they have their own team, and they have a pretty active community as well. I think it's good to delegate that part of innovating in the server-side rendering area to the Nuxt team. We actually communicate very often. If they have interesting ideas that will require support in Vue core, we would work together to find out what's the best way to do it.

Dave: I like what you said about one of your focuses is to upgrade legacy apps. Recently, I work on a legacy Java application kind of like evaluating our options. There is quite a bit of state, so we're just like, "Oh, we need something. We have to figure out something."

I was just like, "Well, I have a little bit of Vue experience. Let me just cut some prototypes here and see what we can do." I like that Vue can kind of exist in an application. I think if I were writing -- I want to ask about these .vue file things. You can write Vue components in JavaScript and then just load them anywhere you want onto the page. It's really pretty easy, even just with a script tag.

Chris: You're talking about a zero build process kind of way, like Vue is happy to support.

Dave: Like a zero build process.

Chris: Just load up the Vue library, write some JavaScript, and you can use it.

Dave: Right, but you look at other competitors, we'll call them, like Angular is a pretty heavy build process no matter, especially with its TypeScript default. You look at React. React is pretty good, but it's got JSX kind of in there, and so now you kind of need to handle that.

I found Vue to be kind of the best candidate for something like upgrading this legacy Java app. I think, ultimately, we may end up rewriting all that in Angular. I don't know. But it was just kind of this one thing. That was sort of like, what's the team comfortable with?

I think one thing is, Vue just stood out to me. I was just like, "I think this is the best pick, y'all. I don't know. I think we can just ship things now. Today, we could drop it in." I like that aspect about it.

Was that sort of a demand or was that your situation? Why did you guys focus on that? Why did you all focus on that?

Evan: This is really an overall philosophy of keeping of entry of barrier low as much as possible. This is important not just for upgrading a legacy app, but also for beginners to get into the framework. The learning process, if you require someone to just first install Node.js, set up a build process, just to be able to build something and see something on the screen, I feel that's just putting too many things in between from getting zero to one. We want to make that process as painless as possible.

Dave: I think that's really cool. You probably hate these analogies. [Laughter] Often, I hear Vue kind of called the jQuery of frameworks because it's just something you can sort of sprinkle in.

Evan: Yeah. That's the intentional position, right? We want to keep it that way. We want to keep the options open. Overall, the point of being incrementally adoptable is a big strength of the framework, I believe, because you can use it in all these different situations by taking a different amount out of the framework so that your knowledge applies to a wider range of scenarios.

Chris: That's nice. You don't necessarily find it burdensome to have to support that. What would Vue look like if you're like, "Well, in order to use this, you have to run a build step"?

Evan: Well, the only actual real constraint that we have is there are some edge cases where, when you write HTML strings, and when you write a template directly into HTML, the browser forces everything to lower case. That's been a pretty annoying restriction. Outside of that, I guess the other thing is, we have to be aware of the bundle size of our compiler because the compiler needs to run in the browser when people are trying to compile templates directly on the fly.

Currently, Vue 2's compiler size is around 10KB Gzipped, which I think is pretty good. When we are writing the compiler, we have to intentionally be aware of the final size of the bundle. So far, I think we've managed to keep it at a reasonable size.

Chris: That's an interesting thing about Vue. When you talk about HTML template, you literally mean the template tag in HTML, which is not a Vue feature. It is just a standard feature, right?

Evan: You can, also. You can use the HTML template, which is the literal template tag. Alternatively, Vue also supports just taking anything you're written in HTML, a plain element, and it can just use that as the template source. It just uses outer HTML and compile it into JavaScript.

Chris: Or you could even write a template literal string in JavaScript, couldn't you?

Evan: Yeah. Yep, you can do that.

Chris: [Laughter] There are so many ways! It's great.

Dave: Yeah, I find that to be kind of cool. I do different things for different purpose. There's also this other thing, the Vue file. Can you talk about what the heck a Vue file is?

Evan: A .vue file, a file that ends with the V-U-E extension, is what we call a single file component. In this component, in this file, you can include a template tag, a script tag, a style tag, pretty much just like a normal HTML file. The difference is, it's treated as, when you import it from another JavaScript file, it's treated as a module. This single module would contain the logic of your component, the template of your component, and the CSS styling of your component.

All of this is used as a source file, so we pipe it through a build process, for example, with Webpack. We have a loader called Vue Loader, so the Vue Loader will parse this file, extract the relevant parts, compile them as necessary and, finally, reassemble everything together.

In this single file, you can actually also specify different pre-processors for each part. You can use LESS or Sass for your style block. You can use Babel or TypeScript for your script block. You can even use Pug for your templates. Everything can be hooked up to your Webpack and then, finally, compiled into plain JavaScript that you can use just like a normal Vue component.

Chris: Can you write HAML, though? That's what the people want to know.

Evan: Yes, you can. As long as there's a Webpack loader for it, you can use it.

Chris: I wonder if there is. That's funny.

Dave: When you get into Vue files, now you're in use a build step territory, right?

Evan: Yep. Yep, you have to, but there is something interesting going on because there is a spec called HTML modules that's currently being discussed under the Web components umbrella. The Edge team is actually starting to actually try to work on it now. If that becomes a native feature of the platform, which looks so, so, so similar to Vue single file components, I think a plain Vue single file component can be changed to a native HTML module with just one line of code with some support from Vue core.

Chris: That's awesome.

Evan: That would be really interesting because, maybe in the future, you can just write native single file components with Vue.

Dave: Whoa! Whoa! Okay. Can I ask a zinger here? Are you ready? [Laughter] What's the story with Vue in Web components?

On the surface, a Vue file looks a lot like a Polymer element, kind of, or something like that. But I think, in your docs, you're even like, "It looks a lot like a Web component but it's different," or something. What's the story there? Would you ever adopt Web components or what's preventing you?

Evan: Right. Vue came up with single file components and we actually have some mechanism, for example, slotting Vue, our model, loosely after the Shadow DOM slot mechanism. But when we first came up with single file components and the slots mechanism, Web components were still a bunch of specs that were not even finalized.

Google were pushing all these Polyfills, but they were heavy. Some of them are not performant enough, so they require a lot of Polyfills to actually work properly in older browsers. If you're using Vue, you don't actually need any Polyfills. The same code would work all the way down to IE9. That's one of the reasons we were--

Until Web components is natively supported in all the browsers within Vue support range, it just doesn't make much sense for us to go full Web components by forcing our users to have to include all these Polyfills just as a baseline upfront cost. That's one of the big blockers. Back then, it's also a very risky choice because, for example, HTML imports was part of the Web component spec, but now it's completely abandoned because Firefox don't want to work on it.

Today, custom elements and Shadow DOM are pretty much stabilized. If you think about, say, when you talk about using Web components, the first question is, what exactly do you mean? Can you say, "I'm using Web components," if I'm using custom elements and Shadow DOM? If I'm just building an app where all the components in this app are only used by myself, then what's the point of making them custom elements?

The whole benefit of custom elements is that you can shift something. You can distribute a component to others that they can use without subscribing to a framework. That is nice. But if you're only building these components for your own use, then the value of custom elements is really, you know, I just don't see where the value really is.

Chris: Well, Shadow DOM would be valuable, so you don't have to write any kind of fancy scoping stuff into your library.

Evan: Right. Shadow DOM with scope styles is a nice thing, but it has problems with server-side rendering.

Chris: Hmm.

Evan: If we use Shadow DOM by default, there is still currently no declarative Shadow DOM, which means your server render output would not include any of these styles upfront. So, you would have this flash of unstyled content.

Chris: I see. I see. Yeah.

Evan: Until your JavaScript kicks in, right? For us, if we can solve the server-side rendering with Shadow DOM and scope CSS, then it would be very nice to just adopt it. But from the framework's perspective, when we adopt something, we have to think about how universally applicable it is. There are plenty of users who use Vue with server-side rendering, so if our default solution doesn't work in server-side rendering, it creates a lot of friction and confusion for our users. That's why we're still sticking to the compile-based scope CSS implementation so that it works consistently across all use cases.

Chris: Yeah, there's just not -- you just don't see the value there. There are more problems than solutions, in a way.

Evan: Yeah, there's always trade-offs, right? For us, all the drawbacks of potentially going full Web components just outweigh the benefits it gives us. For example, the benefit of shipping libraries as Web components is actually a good one.

In our CLI, we have this functionality where you can build normal Vue components wrapped as native custom elements. You can build with --target WC and it outputs a bundle, which registers all these components as native custom elements. The consumer of these components no longer need to use Vue to consume these components. They can just use them as real custom elements.

This is something; if we find there's real value in these new features, we'll definitely find a way to support them. When people say, "Frameworks should just switch to use Web components internally," I just often feel like it's sort of platform for platform sake. There are just a lot of tradeoffs you usually don't notice unless you actually work on these frameworks.

Chris: I appreciate the explanation there because it seems like it's easy to think--I don't know--wouldn't it be nice if just all the frameworks used the same platform. That way innovation could happen at a different level. We don't have to disagree at the base component style. We can work on different things.

Evan: Yeah, I feel like when you -- there is another layer of it to it, right? These specs, like custom elements and the Shadow DOM, they don't really solve anything about how to efficiently re-render your DOM--

Chris: Right.

Evan: --how to compose your components, how the data flow works.

Chris: Yep. Nothing. No. [Laughter] No state management. Yeah, nothing.

Evan: Exactly, so these are still pretty much the responsibility of these frameworks. Even Polymer, right? Polymer is built on top of it, but Polymer is a framework of its own. It has its own templating system. It has its own conventions and all that. I don't see Polymer actually being that different from other frameworks except for the fact that it's built directly on top of these real custom elements.

At the same time, a framework like Vue, we can totally evolve to take advantage of native custom elements if that really becomes a worthwhile tradeoff. It's not really that hard for us to actually do that.

Chris: You're already the closest ones there, I'd say, with the native template support.

Evan: Yeah, totally. Yeah, I don't really see it as a "this or that situation," but more like when is the right time and when is the right situation to actually use them together. Yeah.

Chris: It sounds like it's probably not Vue 3, yeah? [Laughter]

Evan: Well, Vue 3, there's nothing inherently preventing us from using them, per se. It's just like using them by default doesn't actually bring us any benefits for the majority of the use cases.

Chris: I mostly meant it as a segue to get you to talk about Vue 3, really.

[Laughter]

Evan: Yeah. Vue 3, yeah, we are underway. I have a pretty extensive post. If you want, I can just go over some of the major things we're working on.

Chris: Sure.

Dave: Yeah, isn't the highlight that it's smaller and better? Is it smaller and faster?

Evan: Smaller and faster is obviously a goal because, whenever you do a big rewrite, you always want to take the opportunity to improve those objective metrics. Being smaller and faster is always a good thing. The other major thing is we are rewriting with TypeScript.

Dave: Oh, wow!

Evan: This is mostly for long-term maintenance purposes. Vue 2 already uses Flow. We used Flow in the very early days of Vue 2.

Over the time, over two years, TypeScript has really improved in terms of ID support, ecosystem, and the language stability itself. All of these are pretty much a clear winner now, so we figure we'll just switch to TypeScript. It also makes it easier for us to maintain our typing because right now we have to actually write the source code in Flow and then maintain a separate set of types for typing, which is a lot of overhead, to be honest.

Chris: Also, it doesn't matter to anybody else, right? It's just an interesting little side note or people might be interested and be like, "Oh, I see the Vue core team is having success with TypeScript, so maybe that might matter to my project," but it doesn't mean that your project needs to care about TypeScript.

Evan: Totally. Yeah, this is a common FUD coming from some users who don't use TypeScript. They'll be like, "Oh, do I have to use TypeScript to use Vue 3?" Obviously, the answer is no. The API will remain mostly the same if you don't want to use TypeScript.

If you do use TypeScript with Vue, rewriting in TypeScript also allows us to -- it makes it easier for us to provide better TypeScript support. That's another bonus. We can give you a smoother TypeScript experience if you do use it. If you don't use it, you don't have to worry about it.

[Banjo music]

Chris: This episode of ShopTalk Show is brought to you in part by Jetpack. It's Jetpack.com. It's a plugin for your self-hosted WordPress site that brings just this massive slew of features to your WordPress site. I use it on all my sites because of how useful all those features are.

Here's one of them. It kind of connects your self-hosted WordPress site with WordPress.com, the mega site that has a bunch of functionality all to itself, including being able to be a CDN and leverage those kind of abilities. It just kind of automatically gives you power to access that if you want.

Here's another one that I like, though, is, because you're on WordPress.com, then you can use the WordPress mobile app, like on your phone, and kind of manage your site that way, which is cool, which does all kinds of stuff. It can do automatic plugin updates for you, which is nice. I can sit there and look at all the comments on my site and approve comments, which is just a job I have to do on CSS-Tricks that I can now do through the WordPress.com app. I do that all the time.

Recently, they've launched an activity feature, which is kind of cool, and not a feature of your self-hosted WordPress site. Just like, "This user did this. This user did this. This user logged in. This user changed their avatar. This user updated this blog post." Just proof of what people are doing on the site, which is nice for you to just check in and look.

If you're like, "What happened to this?" there's a reference where you can go look and see what happened, which I just think is kind of nice. I think a lot of good Web apps have that feature, that activity thing so that you can check in on things. It's pretty cool.

Use Jetpack. Bye-bye.

[Banjo music]

Chris: I wonder. Do you have a sense--? To bring it back to kind of the difference between using--I don't know--a CDN hosted version of Vue and just sprinkling it into an app or whatever, or the kind of Webpacked, more all in Vue file processed approach? I don't know if you have any metrics or anything or have a sense of how do people usually use Vue. Is it pretty sprinkled?

Evan: I think there are definitely a lot of use cases for both. Some relevant metrics: I think, for the more build oriented approach, you can take a look at our NPM downloads. We currently have probably three million downloads per--

Chris: Fascinating. If you do that, then it's in your build. You're not just hosting a….

Evan: Then in comparison, our CDN hits on jsDelivr is 451 million per month.

Chris: [Laughter] That's interesting because that's every page view-ish.

Evan: Yeah. Yeah, that definitely is, but it's still a huge amount, right? We are around half of jQuery.

Chris: But if it's browser cache, it's not really every page view, right?

Evan: The CDN is.

Chris: The browser might hold onto it. I don't know. It's a tricky story there with that, I guess.

Evan: Yeah, but being half of jQuery in terms of CDN hits, I think--

Chris: Incredible, yeah.

Evan: --shows that we have a huge amount of users that are just actually using Vue that way.

Dave: Well, and I think that's cool that you can just use it off of CDN.

Evan: Yeah.

Dave: Like you were saying, you can kind of enhance your way into it. I guess I still want to hear more about Vue 3 features. Yeah, we should keep going. What else is in Vue 3?

This is maybe a question I want to ask. Why is it smaller and faster? You rewrote it in TypeScript, but I don't have to use it.

Evan: Right. One of the important things I forgot to mention for Vue 3 is, we want to take advantage of some of the new native language features in ES 2015 and above. Currently, in Vue, our Vue 2 support ranges down to IE9, which means we have to try and spiral it down to ES5. We cannot use features that cannot be Polyfilled, which means we cannot use proxies.

Proxies are really nice for implementing change detection. Vue 3 is rewriting the whole data change observation system using proxies but, in doing that, we require baseline support for native ES 2015. The benefit of doing that, it also means we can output source code without having to transpile them. We can just output. We can ship native ES 2015, and native ES 2015 minimizes better.

A lot of these features, for example a class or just a for-of loop, these things, when you transpile it down to ES5, it becomes much, much more robust and bloated. But if you ship native ES 2015, it results in better minified code. It also parses faster, runs faster.

Chris: Don't you think we're in the middle of a big wave of people doing this, of people being like, taking a look at, "Well, okay, we can drop IE11 support, so what is our base?" All the rest of these browsers are so good at being evergreen. You're like, "Why am I even Babeling anymore?" [Laughter]

Evan: Totally. Totally. This is one of the reasons we actually have a feature called Modern Mode in our CLI where, when you build with the modern flag, it outputs two different bundles for your app. One is transpiled with Babel. The other only transpiles the necessary features that are supported by--

We have a baseline that's all the browsers that natively support ES modules. It's a pretty good indicator, so babel-preset-env has this feature built in.

Essentially, you have a bundle that includes as much native ES 2015 as possible. This bundle will be smaller, parse faster, run faster, and then we also generate the HTML file that automatically uses the correct bundle based on the browser it's loaded in.

Chris: How wonderfully convenient is that that you can just go type=module and get [laughter] a version that loads up that can be all ES6 heavy and stuff? That's a convenient little trick that the browsers have given us.

Evan: Yeah, it's actually an interesting hack because it uses script type of module, type=module, right? If the browser supports that, it definitely supports a lot of these ES 2015 features. If it doesn't support it, we can then fall back to the normal imports.

Chris: Yeah. Super nice. Okay. Dave, are you happy?

Dave: No, I think that's good. IE11, that is not in your feature matrix, but you're saying this kind of modern module system can kind of fall back to IE11?

Evan: For IE11, Vue 3, the default build of Vue 3 will not support IE11. The baseline requirement is evergreen browsers with full ES 2015 support, but the system -- we can actually swap the observer module, which has a hard reliance on proxies, to a legacy implementation, which maintains largely the same API but with some of the limitations that are currently in 2.x. That results in a sort of IE11 build that would work in IE11 but with the same limitations of the 2.x change detection. If you don't have to support IE11, you would be able to just use the more modern output.

The change system that leverages proxies gets rid of a bunch of things, a bunch of the caveats that's currently in Vue 2.x. In Vue 2, we currently have some limitations on, for example, we cannot detect a newly added property. If you add a new property to a project, Vue cannot detect that but, with proxies, we can. Then, for arrays, if you mutate the length in ES5, we're not able to detect that. But in Vue 3, all of these edge cases go away, which is really nice.

Dave: Interesting. I'm curious how it's going to work in practice when people upgrade their system. Does it seem like it's passing tests, like for IE11 or something?

Evan: We haven't really started backporting all the tests yet. Vue 3 is still in early stages where we are pretty much trying to validate all the things we want to do. I think, in terms of reimplementing the system in proxies, that's already done where also some of these size and performance improvements are also based on our current prototype, which is largely in feature parity with 2.x, but there are still a lot of internal improvements that we can keep exploring.

Dave: Cool.

[Banjo music]

Chris: This episode of ShopTalk Show is brought to you by An Event Apart. It's literally AnEventApart.com, which is a conference series, my favorite conference series, that goes all around the different cities around the United States all year long. The 2019 season has kicked off, and you're missing Seattle. By the time you read this, it's very nearly over or over, and that's sad because I'm going to be at Seattle giving a talk that has its roots here on ShopTalk Show. I'm very excited about it.

Just because you missed Seattle doesn't mean you have to miss the rest of the year. There are lots more events coming up in 2019. Check it out. They're coming to Boston, Washington, D.C., Chicago, Denver, San Francisco. Is one of those near you and you can make it, or do you wish to travel to one of those cities? I think it's about half and half how that works out, usually, at An Event Apart.

They're just phenomenal conferences with phenomenal speakers. It's just really comfortable, fun, professional, and just packed full of big, wonderful ideas that make you think and make you better at your job. Please consider coming to An Event Apart, and I don't think you'll regret it, so check it out.

[Banjo music]

Chris: You know we got to talk with Henry from Babel a few weeks ago. He's in a unique spot. I got some sense from him that he's got the world on his shoulders, in a sense, some days and that it's been hard in some ways for him.

Evan: Yeah.

Chris: It sounds like he's kind of got the financials thing kind of figured out. There's a team around him, but he's still kind of a big part of guiding the effort forward and stuff. I wonder if you feel any similarity there. Right on the bottom of Vuejs.org it says, "Copyright 2014-2019 Evan You." In a way, it's just you. I don't know. You could explain what your team situation is, but it's even leveraged occasionally as a criticism, right? "Why would I pick Vue? It's just one guy."

Evan: Well, technically, it's no longer just one guy. Right now, I'm more or less -- actually, a considerable chunk of my time is more like setting the higher level vision for the project, writing RFCs, talking with team members on what they're working on. The only repository on GitHub that I am actively looking at every day is Vue core. The CLI, our dev tools, ES link plugins, router, VueX, all of these are pretty much delegated out, and I tend to only periodically look at them in batch.

My daily focus is on setting the vision for the entire project and working on the core. Then, for all these satellite projects, essentially, other parts, supporting parts of the framework. The daily maintenance is largely delegated out. I would periodically just process the issues that emerge that really need my attention. I think that's good because our team members, although most of them are volunteers, are actually doing a pretty good job in just keeping things on track.

In that sense, I feel, I definitely feel for Henry because I actually talk to him quite often. I think I'm partially responsible for pushing him to do it full time.

[Laughter]

Evan: When he was still working at Behance, he actually talked to me quite a few times. He was like, "I want to do this full time," and I was just trying to give some advice on how to figure out the finance bit.

I think, overall, there are multiple factors involved in working on open source full time, right? If you're not able to be financially sustainable, that's definitely a very challenging place to be because you're dealing with pressure from both sides, both from your actual life where, can you actually make a living out of the things you're working on? The other side is all the responsibility on your shoulder. I have this project. People are using it. I need to keep working on it so that people are happy.

Working on it full time is a huge commitment. Luckily for me, my financial situation is pretty stable. As I said, I've been working on this for three years now, and it's only been getting better financially.

Chris: Good.

Evan: I think I'm very, very lucky to have this sorted out so that I can actually focus on just working on the project and improving it.

Chris: I'm sure that's a complicated part of it right there because you can't just be like, "Oh, what am I going to do? Well, I'll just throw up a Patreon and see how it goes."

Evan: [Laughter]

Chris: You can't, right? It sounds like you have that, but you also have other ways of accepting donations, whether they're recurring or not, and you have sponsorship involved, too. I'm sure the whole model is pretty complicated.

Then it's not necessarily just Evan You's bank account, right? There are costs involved here. There are, I'm sure, people that are paid for various reasons and things.

Evan: Yeah, but believe it or not, for the most part, it was really just setting up a Patreon. [Laughter]

Chris: It was? Oh, wow.

[Laughter]

Chris: Okay. Well, there's nothing wrong about that.

Evan: Yeah. That's still the majority of it, actually. The thing about Patreon is, Patreon, really, if you think about Patreon, it's really just a payment processing thing, right? What matters more is how you actually set up your Patreon or how you set up the incentives so that people or companies are willing to give you money on Patreon.

It doesn't really matter if it's Patreon or not. If there is another payment processing service that allows you to just accept recurring donations, they're pretty much the same thing because Patreon, as a platform, is mostly for content creators. It's for people who make videos or produce stuff.

Chris: Right, so for you, you don't care. You're not promising anything from your Patreon. You're not delivering a recipe every month.

Dave: Yeah. If I'm a silver tier, what do I get here?

Evan: Yeah, so for us, Patreon really is more like, the higher tier you go, the better exposure you get with your logo on our website. That's pretty much it. I think that's good because I intentionally set up my Patreon to be as passive as possible. I don't want to have to constantly do things to just entice people to keep the sponsorship or keep attracting new users. I want to just make it so that, once I set it up, I can keep focusing on working on the actual thing instead of worrying about attracting more people to donate.

Dave: Yeah.

Evan: I feel like, in some way, this may result in getting actually less than what you could get but, I think, for me, that's the better outcome because getting something completely off your table is really important. I actually spent a decent chunk of time automating the whole process of when a new Patreon sponsor signs up, I automatically send them an email and ask them to fill out the form, which goes into a database, which auto-triggers a pull request to our website to add their logo to it.

Chris: Nice. That's wonderful.

Evan: Yeah.

Chris: [Laughter]

Evan: I want to get this off my plate as much as possible so I don't need to think about it, so I can actually focus on the code.

Chris: A true programmer.

Dave: Well, one thing I like is, I feel like your sponsorship model has also filtered out to other components or like Nuxt or even Vue Tabs or something like that. It's kind of a very pro sponsor community. I don't think I've ever seen that in any kind of open source niche, really, that is just so welcoming of sponsor banners and things like that. I think it's really sustainable, and I think that's really cool.

Evan: Yeah, I think one of the reasons that our users are tolerant with that is because they know we're independent. In order for the project to be sustainable, there's got to be some way for us to generate income to sustain our living, sustain our time investment. Unlike Angular or Facebook where they pretty much have their corporate backing, so it makes sense for people to not care about it for us because they know, eventually, seeing these, tolerating these banners is essentially supporting us.

Dave: Mm-hmm. On that note, you're kind of the Indi choice, or one of a few, in terms of you don't have a Google, a Facebook, a Microsoft, even, if you look at GitHub as a whole. You don't have that kind of backing. What does that mean for your project? Do you have big clients coming to you and saying, "We'd love to be on Vue, but you're not owned by Facebook, so we're going to go with React"?

Where does that put you? Is that risky for big companies? Have you talked to companies about this? What's that situation like?

Evan: Yeah, definitely. This definitely has made us always be fighting the uphill battle. We've heard people saying, "Oh, it's going to die next year because it's not backed by a big company." We've been hearing that since day one, but we've been here for five years and we are still here. [Laughter]

The thing is, for a company, different kind of companies have different sort of risk tolerance in terms of technology. Small, more flexible companies, they typically are more willing to try out these independent projects. At the same time, there are people who are smart enough to know that corporate banking doesn't necessarily mean the project is guaranteed to be here for the long-run. Think about how Angular 1 ended up.

Chris: Right.

Dave: Mm-hmm.

Evan: Right? Think about, like, not every big company, open source project is guaranteed to be maintained. If you think about corporate-backed open source projects, these projects exist because their primary purpose is still to serve the company that created it. Their interests may not perfectly align with just an external user who happened to have a use case for these libraries.

In that sense, an independent project guarantees to always put their users first. We are not serving some for-profit product. We're not serving a purpose that may have misalignment with our users' goals. Our goal is to fulfill what our users want. I think, at the higher level, this is a big difference.

On the other side, the more practical side, when people think about is it risky to adopt a project that's independent, I always try to convince people to not think about big company versus independent but, rather, look at the track record of the projects. If you look at how Vue has been doing over the last five years, look at the releases, all the work that went into it, all the issues we've closed, all the releases we've made, just look at these numbers in data and judge for yourself. Do you think this project is here to stay? I think most people will make reasonable judgements if they actually look at the data.

On the other hand, it takes time for a project to grow and mature. That's why maybe when Vue just came out, it's totally valid for people to say, "Yes, it's risky." Right? But how we made it today is by being consistent. Despite people saying that this project is going to die next year, we keep working on it year over year. Every year, we become stronger. Every year, we get more users, which means we get to attract more users in the future because the more track record you build, the more reliable you become.

Chris: Well said. I think about that with CodePen. We're around.

Evan: Yeah.

Chris: Every year, we become a little bit like, "We're not going anywhere. We're in this thing," you know, like, "You can trust us."

Evan: Yeah.

Chris: "We're a long-time thing."

Evan: Yup.

Chris: Just because something is a big company doesn't make them automatically trust. I love looking at the Twitter typeahead library. That's a fun one to look at because it's by Twitter, how Twitter does open source. Amazing. How trustworthy.

Evan: [Laughter]

Chris: It's absolutely abandonware.

Evan: Yeah.

Chris: I'm sure it was just some developer at Twitter who put it together.

Evan: Yep.

Chris: I could probably just look, but there's no reason to. Who cares? Then they leave and then what? Does Twitter have to hire somebody to…?

Evan: Totally. Yeah. I feel like the biggest risk for these big company open source projects is the original lead or the original people who worked on this project just leaves the company. I feel like it's pretty much the project loses vision. The risk is almost the same as someone who started a project and independently decides to stop working on it. It's actually less likely because people who actually start an independent project are working on it full time. That's a very, very strong sign of commitment. It's like starting a startup, right?

Dave: Yeah. Are there any big brand name projects that use Vue, or is it just the Vue website? [Laughter]

Chris: Oh--

[Laughter]

Evan: GitLab would be probably one of the most well-known.

Chris: Wow! That's a Vue project? I use that every day.

Evan: Yeah. Yeah.

Chris: Yeah.

Evan: Yeah.

Dave: You were using Vue the whole time! Ah!

Chris: Ah!

[Laughter]

Evan: Yeah, I actually like to tell that to people because a lot of these companies use GitLab internally. They're like, "Who uses Vue?" I'm like, "You probably are." [Laughter]

Chris: Yeah. I use the heck out of GitLab. Well, look. Can we do one for the learners out there? I know maybe we've lost them already if you're an absolute beginner here, anyway.

Dave: [Laughter] Fifty minutes into this podcast.

Chris: Yeah, but maybe we'll have a hyperlink to Git right here, though. I bet, Evan, you have a pretty good idea of what clicks with people after all these years with Vue as a learner. What could we point them towards? Maybe it's a resource, or maybe it's just an abstract concept of what you would start with if you're trying to learn Vue.

Evan: Start with definitely just our documentation. I'm pretty proud of our documentation because we hear a lot of good feedback around it. Chris, who has been primarily -- so I started the initial documentation and then Chris pretty much took over. Chris Fritz has worked on the documentation a lot. Then Sarah Drasner contributed to our cookbooks. There's a lot of good stuff in our documentation.

If you're a beginner, the documentation is the resource to get started with. Once you're comfortable with that, there are a bunch of good resources. Some of them are paid, but websites like Vue Mastery and VueSchool.io both have a decent amount of free content. If you feel like you're more the video type guy, then you can try those instead.

Chris: I don't know what kind of project. I guess it doesn't matter, in a way. I feel like Hello World sometimes is not enough and Todo App is a little played out.

Evan: There are plenty of those courses that just guide you walking through a full, how to build an actual Vue application. Also, I believe there is a project called Real World Frameworks, or something. It has a real-world app for every framework. That could be used as a good reference.

Chris: Yeah. We talked about that last week, wasn't it, because we had Rich Harris on from Svelte.

Evan: Yeah.

Chris: It was kind of like, instead of doing the compare Todos, it's some kind of real-world application thing. I forget what it's called.

Evan: Yeah.

Chris: Yeah, it's more interesting than the Todo one. Okay. That's great.

Dave: Then is there anything; is there a project you wouldn't recommend Vue on? I think that's kind of a zinger we've been asking. Do you see situations where, like, ah, maybe you don't want to use Vue?

Evan: Definitely. This mostly has to do with what kind of team constraints you're working with. For example, you have a bunch of developers who are just strongly into TypeScript, Java, enterprisy stuff. Then you're probably better off going with Angular, right? There is just a natural match there.

Then if you have a team who are already pretty into React or whatever other framework, the cost of switching over to Vue is definitely not worth it because you have all these prior knowledge and investment into another framework. Sometimes I would hear people say, "Should we switch to Vue?" I'm like, if you don't have major problems with what you're working with, you should probably just think about it.

Chris: Okay.

Dave: Yeah.

Evan: But, overall, Vue as a framework, we intentionally designed it to be as flexible as possible. Our goal is to be able to cater to as many use cases as possible. Most of the time, I recommend people against it is when they have already strong investment in other solutions in place.

Chris: I can see that strongly. It's always funny when you get the Twitter recommendation. I'm like, "Oh, shoot. How do I do this in WordPress?" They're like, "Well, you switch to Hugo."

[Laughter]

Chris: You're like, "What are you? Crazy?"

Evan: Or VuePress.

Chris: Yeah, VuePress. Sorry. Sorry. [Laughter] Okay, well, is there anything that you want to make sure that the 35 to 45 developers listening to this show really -- [Laughter]

Evan: Well, thank you if you're listening this far.

[Laughter]

Chris: Is there anything you want to say to the world about Vue or you or your project or let them know?

Evan: We have VueConf US that's happening March 25th to 27th in Tampa, Florida.

Chris: Oh, Tampa. Wasn't it in New Orleans last time?

Evan: Yeah. Yes. Yeah, this time we're doing it on the beach.

Chris: I used to live in Tampa.

Dave: Nice.

Evan: Yeah.

Chris: Cool. On the beach.

Evan: By the time you hear this, if there are still tickets available, you should check it out, VueConf US.

Chris: March 25th through 27th in Tampa at the Stratz Art Center in sunny Tampa, Florida. That's wonderful.

Dave: Tampa! Good choice. Well, thank you, Evan, so much for coming onto the show. We really appreciate it. This has been awesome for me because I have been getting into Vue and like it quite a bit, so really appreciate that. For those who aren't following you and giving you money, how can they do that?

Evan: Giving me money? That's great.

[Laughter]

Evan: You can do it on Patreon or on our Open Collective as well. Patreon is my personal income. Open Collective money, we actually keep it for the project, pretty much like a foundation, and we use it to reimburse work done by our core team members. For example, if someone works on a project by just taking some weeks off and focusing on Vue or they do a pretty big long-term undertaking, they can reimburse from our Open Collective, so that is a nice way to support more people spending more time on the framework.

Oh, and I also want to mention that quite a few of our core team members also have their own personal Patreon. Chris Fritz, Eduardo, and Linusborg, they have…. Go to our teams page. Love them on their Twitter profile. They probably will mention how they personally would accept donations, and it would be great for them to also get more donations because of the work they've been doing for Vue.

Chris: Nailed it. I'm glad you got that. It's kind of like forgetting to thank your wife at the Oscars or something.

[Laughter]

Chris: You got it. [Laughter]

Dave: Awesome. Thank you very much. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter at @ShopTalkShow for tons of tweets a month.

If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you. Chris, do you have anything else you'd like to say?

Chris: ShopTalkShow.com.