Episode 15 • John Lindquist

Evan You, creator of Vue.js

John Lindquist asks Evan You when exactly did he become a developer? Evan talks about how the whole thing was a gradual process with no definite "I'm a developer now!" moment. Evan had a degree in art and art history, but he was finding it hard to find work. So Evan went back to school and enrolled in a design and technology program where everyone was forced to learn to code, this is where he first learned Javascript and found great enjoyment in using it.

Google's Chrome experiments are what drove Evan to learn Javascript on a deeper level. Evan landed a job at Google Creative Labs after he created and put a portfolio of his prototypes out there once he thought himself to be good at programming. Google Creative Labs were looking for someone who could bring in design and build cool things quickly, they contacted Evan, and things sort of just fell together.

Google Creative Labs was where Evan first started his work on Vue. As the project grew, the team started to use Angular 1. it had too many features that they didn't need. Evan also didn't like some of the design decisions that Angular 1 had. So, Evan started to work on a templating library just for his personal use. After six months, in February 2014, he officially released it as Vue.js, putting it out there for others for others to use. Initially, it was just a templating library but as the community grew and more features got requested Vue got built into the framework that it is today, being compared on the same level as React and Angular.

Finally, Evan and John discuss Vue's future regarding single file components and proxies. Currently, there are still a lot of problems going with the compile on the fly approach. However, there is a spec being discussed called HTML Modules. Html Imports are getting dropped from the spec. There has been discussion around the HTML Modules spec that looks very similar to what single file components look like on the platform level.

Evan plans to refactor Vue to leverage proxies. Currently, when Vue receives data, it will walk through all of its properties and convert them to getter/setters, this has caveats such as not tracking newly added properties when it finishes. Proxies allows them to get rid of these caveats. Proxy traps can track these changes!

Transcript

"Evan You, creator of Vue.js" Transcript

Resources

Evan You

John Lindquist

Transcript

John Lindquist: Hi, I am joined today by Evan You. Evan, you wanna go ahead and say a couple words about yourself?

Evan You: Sure. Hi everyone, I am Evan You. I am the author of Vue.js, and I work on it full time.

John Lindquist: A million thank you's from me and everyone listening, because Vue is amazing.

John Lindquist: So just a couple questions to kinda get this chat started. What kind of made you decide to become a developer? When did you first start playing around with code?

Evan You: Well this is kind of interesting, cause I think I didn't really have the point of time where I said I want to become a developer. It kind of just happened over time. I didn't study computer science at school, my undergrad degree was actually in art and art history. Then, after graduating, I figured it was pretty hard to find a job with a art degree. [crosstalk 00:01:00] So I went to Parsons, I went to a program called Master of Sign Arts and Design Technology. Which it was a pretty cool program, it had mix of both designing, artistic stuff, and the technical side of things. Everyone was forced to learn coding, regardless of their background. And that was when I was when I started to seriously learn Java Script. I did take one or two computer science classes in college, but it was in Java and I hated it.

John Lindquist: Yes

Evan You: But then I started building these things. I was building prototypes for the things that I designed, and I found I really like Java Script and Action Script also I think Action Script 3 was Flash was still a thing when I was graduating from college.

John Lindquist: I was a part of that community as well.

Evan You: Cool, What I like about it I can build something and put it up on the Web and everyone can see it. Some of the other things that we use like processing or open frameworks, the thing is you have to sort of bundle, like build a thing, then you distribute it as a some special format, which the other side would have to install some special software, in able to be able to just do it.

John Lindquist: Right

Evan You: Right, but stuff on the web you can just put it up on a URL. Everybody can see it. Which was why I really liked it and I started basically investing more time into it. I think in the beginning it was Action Script. Action Script 3 was the first language that I first seriously tried to understand and learn. And then Google came up with all the Chrome experiments, which totally blew my mind. I was like I can do all these things in the browser with Java Script. So I just okay, I am going to learn JavaScript. And then at that time JavaScript was mostly a tool for me to express some of the designing ideas. I had, I designed something and I wanted to build it myself, so I learned HTML [inaudible 00:03:26] JavaScript in order to build a prototype. Right, so I only got, I guess more serious into it over time. After I started working we also built more things which are less prototype and more like real stuff. So I had to learn how to actually build real apps.

John Lindquist: Right

Evan You: It was kind of a progress, it didn't just happen overnight that I said I want to be a developer.

John Lindquist: Yeah, its funny you mentioned that. I remember in college learning Java as well. And I think they just gave us Notepad and didn't even ave the clips or anything to auto complete or help me out with it. It was just a chore getting though those exercises.

Evan You: Yeah

John Lindquist: But as soon as getting into Flash, or more creative things, I could have an idea and I could implement that idea creatively with the code. I was like I love this! Whereas I kind of Java was going to turn me a way from programming for a bit.

Evan You: Yep

John Lindquist: Yeah, I mean to create and build cool things is still why I do it. It's still why.

Evan You: Same here.

John Lindquist: Do you remember your first, what was your first job after learning programming.

Evan You: My first job was at Google Creative Labs. I think I started, after I thought I was pretty good at JavaScript, I started building a portfolio for myself. Mostly it was kind of like creative experiments using JavaScript. Like drawing some fancy stuff with Canvas. It was more along the lines of the type of portfolios you'd see from digital agencies. To show creatives, that kind of stuff. And somehow it got picked up by a recruiter at Google Creative Lab. Because Creative Lab was looking for this type of so called creative technologists who are able to have a good design sense and also able to build, sort of play along with new ideas and build prototypes and playful things really fast. So that was why I just got picked up by them. And I was like Yes! I received the email that like: Hey! This is Google Creative Labs. Do you want to come for an interview? I'm like, Hell yeah.

John Lindquist: What a cool story, that's, way to put your work out there. I mean that's, I tell people that all the time, just take creative fun things and put them online. And share it.

Evan You: Yeah

John Lindquist: I was looking on the way back machine and I looked at VJS.org to see the very first iteration of what it looked lik and went back to, I think it was February 2014. I think it was Vue.8 or something. Do you remember at that time what Vue was, and what your first app that you build with Vue was and what the feeling of starting the framework was like?

Evan You: Yeah, the early days I actually started working on Vue when I was still at Google Creative Labs, but back then it was first just a really rough experiment. The whole idea started with we were building these prototypes in a set and we had to build them really fast. In the beginning I hand wrote a lot of them. I didn't really want to use, jQuery, and since those prototypes only needed to work in Chrome anyway. I used the latest API like querySelector, classList, and I felt pretty good. I was using the platform. And, but as the thing got bigger, obviously we had to, the code just became less maintainable.

Evan You: So some of the projects we started using Angular, Angularr1 back then. And I like the declaritiveness of it. You can write the template and the framework figures out what to do for you. But Angular1 also had all these extra things that I just I hated Java so I also hated some of the concepts that came with Angular1. So I was like I want to have a lean package that gives me this reactive templating system with out all the extra burden. Extra API that I don't need.

Evan You: So that was the initial idea. And I also had, I wanted to experiment with object USING ES5 getters and setters to build this reactive API because Angular1 used security checking and it was like what if we can do this with fine property and use dependency tracking. So I played around with the idea on and off. It remained an experiment for 6 months before I originally released it. The initial release was February 2014. And that was the first public release. Even for the initial release I didn't really want to build a framework. It was explicitly labeled as a library. I was like this is only a vuelit library, hence the name Vue. I didn't even care about routing or build tools or anything like that. All of these things kind of came along partially because as I was using Vue to build stuff I found I needed all the extra pieces.

John Lindquist: Right.

Evan You: And also more people started using Vue and they started requesting things like that. Additional pieces of the framework really added on over time, one by one. I first worked on a router then we added a browser refine transform. Then someone added a webpack loader implementation. The initial webpack loader implementation was written by someone else and I took the idea over and made the official one. Then we had the mistake management tools, CLI, all those things. They came one by one over time. Eventually it evolved into something that's more like an actual framework today.

John Lindquist: Right. It has conferences and...

Evan You: Yeah. And parades.

John Lindquist: It's just a framework. Conferences and parades. I love it.

Evan You: Yeah.

John Lindquist: So during this whole journey what has kind of surprised you developing an open source framework. What has either delighted or frustrated, maybe?

Evan You: I think the most enjoyable part...something I still...people always ask me, "When did Vue blow up? When did it become popular?". To me there's really no such point of time where it just suddenly started being popular. I worked on it for over four years. During these four years, over time, it's like every time we see some growth it's compared to the previous stage. In 2016, I was like, holy crap! We are getting so many users where no longer...it's just like a random project. In 2017, I was like, oh wow! People are actually comparing Vue to Angular and React all the time now.

John Lindquist: In the same sentence...yeah.

Evan You: Right? Over a period of time we reached the next stage. Then the previous stages seemed sort of...it just kept growing and growing, and it's a very long process. To be honest, I never imagined it would grow into what it is today. I'm still pretty grateful because it's the users who actually pushed this thing all along. If we didn't get the initial group of early adopters, I probably wouldn't have worked on it for so long. Every time I was like...oh, there are so many people using this and I felt like I can't have this responsibility to keep this thing going and to make it better and that's what's really been driving it.

John Lindquist: Awesome! Yours is one of the rare success stories of starting with just you, not sponsored by a company or anything like that. Just starting with you, the community helps build it up and it takes off, slowly but surely, and here we are today. Congratulations on your success!

Evan You: Thanks.

John Lindquist: I've always seen Vue as an amazing... you have your conference talk and I think you've given them a few times... labeling it as a progressive framework where you can start with Vue as just a script you drop on a webpage and start building apps and you can bring in a router and you can bring in [inaudible 00:12:53]. It seems like more and more the single file component approach is kind of the blessed path or the...it's my preferred way of altering Vue apps. It seems like more and more that's the way we could and should write our Vue apps. Do you use single file components or Vue components written as single file components as a future browser feature so that they could still have that initial "just drop a script into a page" feel to it?

Evan You: Yeah. In fact, I've wanted to build this version of single file component compiler all along that is able to just load a single file component directly into the browser.

John Lindquist: Yeah.

Evan You: There were a few different models that's pretty close to that. Ractive is pretty close in that aspect and I believe early versions of Ractive also had this capability. The problem with this is before we have fully resolved HTTP2 with all the loading async chunks, the cascading request performance problems. This works really well for prototyping but when you deploy this... loading and compiling everything on the fly model to production, it's just a disaster.

Evan You: So at this point of time, pre-compiling is still kind of a necessity and making it too easy for people to just build things like that, I kind of worry that people will not be willing to actually use the pre-compiling approach because it takes more initial setup. So that's why we actually never did it. I still think it's great that you can prototype easily. That's why Vue still supports directly writing your templates in the browser, dropping a script tag and you can get your work in. I think there's still a lot of problems if you want to use a compile on the fly, sort of, approach directly in the browser today.

Evan You: Hopefully that can be solved at the platform level. There is, in fact, a spec that's being discussed called HTML modules. We know that the HTML imports is being dropped from the web component spec. Browser vendors don't want to do that. There has been discussion around a new spec called HTML modules, which looks very similar to what a single file component would look like. There will be some slight semantic differences but I'm not sure if it will even be implemented in the end. It's very close to what a single file component at the platform level would look like

John Lindquist: Right

Evan You: It's still lower level but we should be theoretically able to build something on top of it that gives you a feel that's very similar to what Vue single file components look like. In fact, Polymer is more or less kind of like that. I personally feel that a bunch of detail design position in Polymer is just kind of different from how Vue looks at how things should be done.

John Lindquist: Yep. That'll be interesting to see how that all plays out.

Evan You: Yeah.

John Lindquist: It seems like the efforts are there and the desire is always there but no one can agree on anything?

Evan You: Yeah. The difficult part is a feature like that is almost like going to the more opinionated aspect of things.

John Lindquist: Yeah.

Evan You: The reason the web platform has been...first there's so many parties of interest, people with different vendors...different companies...and it's really hard to reach a consensus so most of the time we only reach consensus on really low level stuff. Anything goes super opinionated about how developers should develop an app becomes super hard to land.

John Lindquist: Mm-hmm (affirmative).

Evan You: At the same time, that means we have the opportunity to experiment in user land. That's where frameworks like Vue get to fill the gaps. Another aspect of it is, I think the compilation step is also becoming more and more important. It provides all these opportunities for us to analyze the source file. Even cross analyze the source file. When you have the whole application, you have all the information together at the build stage, you can do a lot of smart things to make your application load faster which is really really hard to do if you load everything on the fly. In that aspect I still think the model of having a source format, having single file components as a source format and then pre-compiling it into...the cool thing is you don't have to compile it into a single JavaScript [inaudible 00:17:54] right? You can [inaudible 00:17:56] compile them into web components. You can compile them into whatever future format the platform supports...

John Lindquist: Right.

Evan You: ...for better performance. That's the cool part about it.

John Lindquist: Yeah. Kudos on the new Vue CLI version 3. I've been using it and it's working great.

Evan You: Thanks.

John Lindquist: It's just as easy to spin up a new app using the Vue CLI as it would be to create a new webpage, drop in the Vue script and then still trying to write code.

Evan You: Yeah. That's where we hope we can make it so....

John Lindquist: Yeah.

Evan You: The whole idea of having a sensible built tool configuration working out of the box is really important. We don't want to scare people away and we want to make sure Vue stays approachable. Even with all the heavy tooling behind the scenes.

John Lindquist: Right. Whoever came up with the idea of "Would you like to save these presets?" Or "Save your selections for future...", that person needs a raise. I don't know if that was you, or what.

Evan You: It was me.

John Lindquist: Okay. [inaudible 00:19:07]

John Lindquist: On the topic of browser features, proxies are relatively new to browsers and you've spoken openly about changing the Reactive system in Vue to using proxies. Can you kind of walk me through? I guess I personally understand proxies and I remember using them back in Action Script 3 and I have actually seen a lot of the Vue proxies and [inaudible 00:19:35]. Can you kind of walk me through what it is about them that made you want to make this change experimenting with it? Take me through that.

Evan You: A bit of background. The way Vue currently tracks reactivity or dependency changes is you give Vue a data object. Vue recursively walks the object in converting all the properties into ES5 getters and setters.

John Lindquist: Mm-hmm (affirmative)

Evan You: This has two limitations, right? We have a bunch of caveats in the current Vue version. For example, because the conversion has to happen in one go, once the conversion is done any newly added properties will not be tracked.

John Lindquist: Right.

Evan You: Unless you explicitly use Vue.set. But then you have to remember that. Also we have limitations on when you directly set the index of an array or you modify the length of an array, there are certain cases...these cases you can probably use brute force and make them work but it'll come at tremendous performance costs and it's just not worth it. When you keep these as a caveat that the developer has to remember from time to time. Proxy allows us to completely get rid of these caveats because Proxy traps can detect newly added properties. They can detect deleted properties. They can detect setting and indice on the array.

Evan You: All of the previous caveats that we have can be solved with proxies. The trap is more powerful than ES5 getters and setters. We don't have to convert a nest egg of data structure into all proxies in one go. We can convert them on demand instead of...

John Lindquist: Interesting.

Evan You: ...having to do it in one go. This allows us to essentially do less work upfront. This should technically and theoretically improve our loading performance for an app with a huge data structure up front because right now you have to convert the whole data structure into Reactive ones but with proxies you essentially only convert the property that you are actually using for your initial screen. The rest of the data structure will be converted as you access them when the app starts to do more work, it becomes interactive.

John Lindquist: Right.

Evan You: These are the two prime reasons where we see a proxy would help a lot. Over time I think Proxy is also one of the things that the browser might be able to optimize more, in my opinion.

John Lindquist: Yeah.

Evan You: Getters and setters is kind of like, I don't know, I can't really...I'm not entirely sure on this but I don't think that JavaScript engines have been trying to optimize getters and setters that much. All the new features in ES2015 are getting more attention in terms of optimization these days. So, that's also one of the considerations.

John Lindquist: Could you see the proxy, like right now data has to be a function that returns an object, could you see a proxy enabling data just to be an object? Is that...

Evan You: Not really. The necessity of having to be a function is, it allows you to both return fresh data and also return shared data. Because [inaudible 00:23:14] a function, you can also return something from outside of the function scope. That allows you to effectively share the same object between multiple instances of the component.

John Lindquist: Yeah.

Evan You: So, if you always declone then it's impossible to do that.

John Lindquist: Right. When I've played with proxies it's some of the weird things you can do, like if you proxy a function and then you can invoke the function but you can also say any time you try and get the instance of a function return it's something completely different. There's just some wild. And it would still be typed as a function?

Evan You: Mm-hmm (affirmative)

John Lindquist: There's just some wild things you can do with proxies that...

Evan You: Yeah. We actually already use proxy to an extent in the current Vue so you've probably run into the warning saying that a property is referenced [inaudible 00:24:05] rendered but it's not present on your instance?

John Lindquist: Okay, yeah.

Evan You: This is actually done using proxies. To do a render, all the expressions are actually evaluated on the render proxy which catches all the property access that does not have a [inaudible 00:24:22] property on the actual instance itself.

John Lindquist: Okay.

Evan You: It also opens up a lot of opportunities for better development experience.

John Lindquist: Yeah. It's funny to me when seeing proxies and just some of the crazy things that have been done. It's cool to see it being used for good rather than evil.

Evan You: Yeah. I think these new API's are really powerful for low level use cases especially for us library authors.

John Lindquist: Right.

Evan You: They're not necessarily the best thing to use for your application code.

John Lindquist: Right.

Evan You: But I think it's still good that we can leverage them inside the framework and it allows us to build more powerful framework.

John Lindquist: Yeah.

Evan You: ...and simplify the code that the developer actually has to write.

John Lindquist: Right. The developer experience for me as a developer stays the same. I'm still just [inaudible 00:25:15] equals hello and just what the proxy manage lever that set trap will do.

Evan You: Yeah.

John Lindquist: That's amazing. I just love the Vue development experience. As much as I love going crazy functional and all that, sometimes I just want to build an app.

Evan You: Yeah. That's right. Yeah. I think there's still a lot of areas we can do even better.

John Lindquist: Okay.

Evan You: We're gonna keep working on that.

John Lindquist: Awesome. I will keep following and keep doing it.

John Lindquist: Alright, so, just to kind of wrap up since we're kind of in today. If you could go back in time to where you were before you first started writing Vue, what sort of advice would you have for past Evan coming into today?

Evan You: Well, that'd be tough. I would probably, you know, I've refactored Vue over time. I've completely rewritten it two times.

John Lindquist: Yeah.

Evan You: So I have tons of advice I'd share with my past self.

John Lindquist: Right.

Evan You: Obviously. One thing I would probably tell myself is when I had just started working on 2.0 is, you probably you should just go TypeScript.

John Lindquist: Interesting. Okay.

Evan You: The thing with [inaudible 00:26:35] was it was easy to introduce to the code base back then, which was mostly JavaScript but it just never decided to become 1.0. Every minor [inaudible 00:26:46] there's just a bunch of things I had to fix in order just to upgrade. It was getting kind of tiring and TypeScript is also doing better in terms of IDE support because this code is so good with TypeScript.

John Lindquist: Yeah. If the company controls the language [inaudible 00:27:07] the experience always.

Evan You: Yeah.

John Lindquist: That's something we've seen with C-Sharp and Visual Studio. JetBrains has a language called Kotlin and they have [inaudible 00:27:17] seeing the same thing with TypeScript and VS code. This is amazing.

Evan You: Yeah.

John Lindquist: Thanks for joining us today. Do you have any closing words of inspiration for anyone listening?

Evan You: Not much. Just work on the things that you are interested in and good things will happen.

John Lindquist: Great. Thanks so much, Evan.

More Podcasts

Browse All