Ray Shan
31 min read

Vue.js
Modern Web Podcast Transcript

Chinese translation by banq @ 解道JDON

Vue.js is a JavaScript UI framework built to be approachable, versatile and performant. Its creator Evan You and the award winning writer of CSS-Tricks Sarah Drasner join me to discuss the creation of Vue.js, the beginner learning curve, how it handles data and animations, and how it differs from Angular and React.

Show Notes

Panelists

Links

The following is a transcript of the interview from the episode.

Tracy Lee

Hello, you are listening to the Modern Web podcast where we explore next generation frameworks, standards and techniques. I’m Tracy Lee @ladyleet on Twitter and you can find us online at modern-web.org.

Ray Shan 单锐

Sarah, would you like to introduce yourself please?

Sarah Drasner

Sure. My name is Sarah Drasner. I work as a consultant and I speak, and give workshops and stuff. I also write for CSS Tricks. I’m formerly the manager of UX design and engineering at Trulia, which is a part of the Zillow Group. Yeah, I’m excited to be here.

Ray

Welcome. And Evan, would you like to introduce yourself please?

Evan You 尤雨溪

Sure. I’m Evan You and I’m the author of Vue.js. I used to work at Google Creative Lab and Meteor previously. Now I just work on Vue.js full time thanks to all the sponsors and community support, which I’m really appreciative of.

Ray

Great. Great. Well, welcome to the show. First of all, I just wanted to say thank you all for all your contributions to both the open source community and trying to educate the developers on, on various things that you’ve done, Sarah, we all really appreciate the time and the effort that you put into your work.

Sarah

Oh, thanks. I appreciate that.

Ray

So Vue.js, that is the subject of this show since you already Creator Evan, would you like to give us a brief intro of Vue.js and how it all got started?

Evan

Sure. So if you’ve never heard of Vue.js, it’s one of one of those JavaScript frameworks that help you build applications, web applications. Most of the time when we talk about JavaScript framework, we’d assume it, it focused on like the more complex type, like single page application. But Vue kind of tried to cater to a wider range of use cases. The original design was trying to keep it as minimal as possible so that it can be just directly dropped into a page and you can use it just for a simple enhancement to a static page. Or if you want to build more complex applications, you incrementally puts more tools and supporting library into the mix, which gives you a more powerful combination that helps you handle a more complexity. So that’s the whole idea behind the framework. The slogan on the website is called a “progressive framework”. The whole idea is we designed it to, from the ground up to be incrementally adoptable so you can start with something that’s really, really simple, really minimal, and it’s easier to get started that way. You gradually learn more pieces of the framework and learn how to put them together to build something that’s bigger and more ambitious.

Ray

Cool. And when did Vue all start?

Evan

It’s actually a long story. I started working on it - the first commit was late 2013 when I was still working at Google Creative Lab. And, but at that time it was totally a random experiment. Um, I was working on a lot of a quick UI prototype at that time and some of them we used Angular in it and uh, it just feels too cumbersome. Angular was too cumbersome for those specific users. It just had brought in a lot of things that we didn’t actually need, I thought. But there was some things I actually really liked about it, like the data binding, uh, the way that you update the state and things just, you don’t need to worry about imperatively manipulating the DOM anymore. So that part is really good. So I figured why is it possible to kind of extract these valuable parts, but, you know, expose it in a package that’s more minimal, that’s easier to drop into any use case that I want to it. So that’s the initial ideas. I started working on it and it didn’t, it wasn’t even named Vue at that time. It was basically a small, a crappy version of Angular. And experimented with how the reactivity would work. So Angular use dirty checking. But I was thinking things, most of my stuff only needs to work in Chrome. I was like, okay, I can use ES5 features. I don’t need to support IE8. So I kind of use the different approaches defining getters and setters on data objects. And it turns out it worked pretty well. It remained a small personal project for awhile and uh, eventually I opened sourced it in February 2014. That was the first initial public launch and I sent a post to Hacker News, and it got upvoted to the front page luckily. It stay there for a few hours and I think it got me like 60 or so stars in the first week, which I was super excited about at that time. Someone was actually paying attention to this little project that I made. It remains a personal project for a very long time, but steadily there were users using it. There were - I also made new versions. It was kind of like a, um, served as some place where I experiment with all these ideas or improvements that I want to make. So for example, when I read other people’s code or when I look at a new upcoming framework and I see these good ideas or good coding practices. I may not have the chance to actually apply them to the actual day job that I was doing, but I can try to apply them into Vue. So it was kind of like this place where I was able to just hone all these new ideas or skills that I’ve learned and try to create this thing that I’m constantly polishing it to kind of, you know, you get the idea. So that kind of continued for maybe a year or two. Close to version 0.12, I did a complete rewrite. That was the first complete rewrite that sort of, um, improved the code structures, build pipelines and all that. That’s when it started to get more attention. In 2014 or 15, I think in 2015, the Laravel community started to, pick it up. I think Taylor Otwell was trying out React and he didn’t like it. And then he found out Vue, and he was like, oh, this is what I’m looking for. That’s when the Laravel community started paying attention to Vue. Jeffrey Way of Laracasts made a whole series on how to use Vue and it kind of sparked a lot of interest in the framework. That’s kind of the moment when I kind of started to feel, oh, there is more potential in this thing, because Laravel is a huge community. The influx of new users, just because of that, was kind of mind blowing to me at that time. I started working on it more and released version 1.0 in late 2015. That was the, I guess a big design wrap up where we kind of consolidate on a bunch of things and basically the project was no longer experimental. It was something that we considered pretty good, pretty stable, people can use it in production. Then it went upward from there. We did 2.0, that was last year. 2.0 was another complete rewrite and introduced a bunch of new capability. We now use the virtual DOM, we support server side rendering, even native rendering. After 2.0, the growth rate was kind of, it just kept growing. I’m honestly pretty surprised at how fast it’s been growing because, um, I remember back in early 2016, there was a post in the Chinese developer community discussing what framework will “win” 2016 or 17. And at that time there was one guy that I know, he wrote a post saying, I, I predict that Vue will be sort of on the, like on the same level with Angular and React by the end of 2016. And I replied, no, I don’t think so. I don’t think that’s possible. Yeah, I was -

Sarah

[Laughs]

Ray

[Laughs] Well, look at where you’re at now.

Evan

So, yeah, it was honestly a pretty crazy ride. Uh, I am a, I never expected it to be, to be this popular today to be honest. Yeah.

Sarah

Yeah. I think I saw a post today that was like, at the time, you know, Vue has three quarters the amount of stars as React but hasn’t been around as long, and then that it has double the amount that of Angular. I was like that kind of makes sense to me, in terms of tracking popularity of frameworks. GitHub stars of course is a little bit different from adoption and the size of the community. But, it does kind of track excitement around frameworks.

Ray

Frankly, even Miško Hevery, the father of Angular, even he said that he never imagined Angular will be as popular as it is now. I think when the technology is good, when there are a lot of good ideas, it’s a lot more likely that people will gravitate towards a project, right? And I definitely want to echo what you were saying about using defineProperty and getter and setters. I think a lot of people don’t really think that JavaScript is capable of doing that, but it’s very common in class-based systems, for example, in the Apple ecosystem with Objective C and Cocoa. We actually use that heavily for data binding as well for a framework that I worked on called Montage. And just to give the listeners who might not be familiar with that pattern - if you have a controller, that control was, say pagination of a list, instead of saying next page or previous page, you can actually just set the page number. In the setter you can have the logic to actually paginate. So it’s actually a lot more intuitive to use that component. You don’t have to say, give me the next page. You can just say I want page four or I want page ten. So yeah, I definitely liked that as well.

Evan

Uh huh. Getters and Setters definitely opened up some really interesting meta programming capabilities. But also came with some limitations that we are exploring right now, that could potentially be completely overcome with ES6 proxies. Unfortunately that might bring some very small breaking change to the API. It’s an idea that we’d been brewing. I already have a branch that’s like somewhat working, and I think it’s really a matter of browser support at this point. So whenever all major browsers support proxies out of the box, we’re just going to probably drop that.

Ray

Yeah. The other interesting thing I thought that you mentioned is the difference between Angular and React and Vue. The philosophical difference of a very much of a battery included - all batteries included - framework versus something a lot more lightweight like Vue, I think it draws a very different audience, and they attract a lot of people. Uh, I guess including Sarah, right? So Sarah, you’ve been a fairly newcomer to Vue. What are some of the reasons that drew you to Vue.js?

Sarah

Well, I’ve been working with React pretty heavily for a little while. People always want me to pick one when they asked that question, you knows, it’s like, which do you like better? I definitely still work with both. I’m on a React project right now. I, um, something that really drew me into Vue and that I think is really elegant is its flexibility. People tend to think that simple means that you can’t do a lot, but I think that Vue is incredibly powerful and just as powerful, like in terms of creating a general store and doing all of the state manipulation. But the simplicity makes it very easy to read. It makes it very easy to read and understand like how to work with it. I think as a maintainer, you can jump into somebody’s code and understand like immediately what’s going on, which for me means a lot, especially as a consultant, you know, I can get thrown into code bases that I’m not very familiar with. Having differences just like small, you know, small things like having differences between computed and methods and filters. Like really immediately communicate what intent is for each of those things. So I guess the really powerful thing to me about it is that the simplicity is in the way that the code is written and communicated. It’s as if somebody is saying a sentence that clearly communicates really, really vital information that you need, you know. You don’t want them to like, I’m maybe doing this right now. You don’t want so many that ramble on for something that can be very succinct. That’s something that really attracts me to Vue. Just from working with it right out of the bat, that was something that I really enjoyed about it. Aside in like - another small thing that I will tack onto that is that I work with animations and SVG a lot, and I think that the way that the DOM works and the way that animations work in Vue is particularly - like having worked with it and some other different frameworks, that piece is particularly elegant to me. I don’t feel like it’s, you know, I’m never like fighting with it. It’s like always working with me and I think that there are some pieces and other frameworks that haven’t quite got there yet that Vue has handled pretty well.

Evan

Well, I’m really happy to hear that. So I kind of want to, like mentioned because when I was working at Google Creative Lab, we did a lot of the prototypes that we did involve a lot of fancy a animations and transition effect and all that. Um, a lot of time I spent there was trying to recreate some of the, um, After Effects animations that my coworkers need with just replicate them with pure web technologies. So it has always been really important to me to create an API that allows people to still be able to create these, you know, a very richly interactive animation while still being able to think, you know, relatively declarative fashion. So you want to build these animations. A lot of times we have to do something very imperative to get those complex animations done. But I’ve been trying pretty hard to find a pattern that allows you to do all that while retaining this state driven mindset where you’re doing animation.

Sarah

Yeah, it does do that really well. Something that I think is really impressive about it is that like, you know, you can kind of tell a lot about a framework in some ways by the way they handled animation, because it’s kind of similar if not the same thing as the way that it handles asynchronous work. I mean animations in a lot of ways is like how you handle and manipulate the DOM, but you have to deal with the aspect of time. It’s like another dimension of complexity. It always seems like animation should be fluff, but it’s actually fairly complex sometimes, especially if you’re working with observables and watchers and things like that. So you can kind of get a sense of how deeply you can manipulate and watch and look at things changing over time or loading data. I mean, of course there’s always like different ways of doing that. And especially like Vuex has really, really nice ways of handling asynchronous data as well. What I guess I’m trying to say is that animations tend to be overlooked as fluffy ad-ons.

Evan

Yeah.

Sarah

But in terms of DOM manipulation, especially in the virtual DOM, animations are a fairly complex feature. And so the way that they work in there is like kind of reflective to me of some of the ways that the whole thing is put together.

Ray

Yeah, I definitely think that’s very important as well. And I think it has a lot to do with your education and background, Evan.

Evan

[Laughs] Yeah.

Ray

I think, for Angular, when it first started, it didn’t have any facilities for animation. But ngAnimate later became a very crucial piece of both Angular 1 and Angular 2. And I feel like in the React community, I feel like that’s something that React still can improve upon, because the animation facilities that come with React probably will be pulled out of it and work worked on separately, and it hasn’t really improved for quite a while. And there was something really cool called React Motion, which is more physics based. But it also hasn’t seen a lot of activity. I do think that as applications get more complex and the users demand for UI and UX increase in the future, that is definitely going to be a big piece that anyone would look in any framework.

Evan

Yeah. This is one of the reasons few ships with transition and animation supports pre-bundled. I’ve considered making it an add-on, but after using it for a while, I just feel like support for like basic transitions when you change, toggle a piece of state is so crucial if you want to build anything that’s pleasant to the user. So I just decided to keep it in core or all the time. Yeah.

Sarah

Yeah. And I think that that transition’s component is actually simple enough to work with that it’s not, there’s no big hurdle for I think for like there’s no, like a giant learning curve. You have the CSS hooks, you have the, you know, JavaScript hooks, so you kind of have some flexibility over which one you want to work with. And then you have these really nice sugary add-ons of the in-out modes, which I think are like one of my personal favorite things about Vue because I think, you know, any time you animate anything, you eventually get into a thing of like some things appearing, something else is disappearing. What happens when those two things are occurring in the DOM? In a lot of other frameworks just kind of like throw up their hands and they’re like, you figure it out.

Evan

[Laughs]

Ray

[Laughs]

Sarah

What I love about Vue and, I think again like this isn’t just the in-out modes. The in-out modes are really nice because it actually allows you to just plug into, you know, really, really simple commands that allow you to pick how you want that to work. But that is reflected again and again over like conditional rendering in just like the stuff that I feel like as developers we’re constantly rebuilding in every single app that we ever work in.

Evan

Yeah.

Sarah

I’ve definitely always needed a for loop for the state of the thing. And like, just having a v-for is like really, you know, and I know Angular has things like that. But the thing that Vue does really well for me is it picks all of the best parts that I really liked about the other frameworks and it puts them all in one place. So I kind of don’t have to choose which is nice.

Ray

While keeping simple, I think that’s actually really crucial. Hopefully we don’t see a lot of like 10,000 line classes [laughs] in Vue.

Sarah

Right. [Laughs]

Evan

[Laughs] Yeah. It’s a, it’s a very, very delicate balance in determining the scope of the framework. So I think I’m constantly fighting a battle of like keeping it simple versus pulling more things into the framework. Sometimes users would make feature requests and I would reject it because I feel like, um, it could be easily done in userland. Sometimes I would add this feature because I feel like it’s crucial, but it just takes none trivial efforts at anyone to do it. And if you can - different users are going to replicate the same thing over and over again, then maybe we should provide a default way to do that. But everything is kind of case by case. You kind of have to think really hard about every one you add to the framework to make sure you don’t bloat it. At the same time you make them happy by finding something that’s already there.

Sarah

Yeah, I mean that’s kind of interesting, especially if you look at like how many different ways there are to do this to do something, you know, based on use cases. I feel like you’ve added a lot of flexibility in terms of the Vue instance. There’s so many ways of creating a Vue instance or creating a component, so that remains really flexible. But then, you know, making a cut off seems like it would be tough decisions sometimes because there are a million different use cases on the -

Evan

[Laughs] Yeah.

Ray

Cool. Let’s talk a little bit about data handling. I feel like over the past couple of years, the way people think about data handled has changed quite a bit. Especially after Redux came out and introduce people to a lot of the concepts. How - for beginner - how would you introduce data handling in Vue?

Evan

So in Vue I usually think of it as a 2 tier problem, similar to when you introduce people to Redux, Dan has said Flux is like glasses, you know it when you need it, but maybe you don’t even need it at all.

Sarah

Yeah. [Laughs]

Evan

So that’s the same thing to Vue, like there is this sort of like, um, based experience of just everything is super simple, like you have an object, you give it to a Vue instance, it becomes reactive. Whenever you mutate it, things just update. And this is actually really helpful when you are building prototypes or trying to get - doing a proof of concept. Because - it aligns with how we think about stuff. When we want to change something in the interface, there’s some corresponding states that should have changed. I know it’s getting - immutability and functional programming is getting much more popular today, but eventually if you think about the way Redux handles data like action and returning new copies of immutable data, it’s still just a fancy way of making something changed. So in that case, I think Vue is just trying to stick to the most intuitive way most of us would - especially people who don’t have like a heavy investment in functional programming would naturally think how things would work. And I think that helps a lot. And it also has to do with how Vue is very often used in these simple enhancement cases where a introducing too much of the functional stuff might actually get in the way in some cases. So there’s that. In this case Vue is actually very similar to MobX where we have these immutable objects which are reactive, and when you mutate them, the system just knows things that have changed and we’ll just do the right thing for you. And when you - so this paradigm works pretty well for small to medium skill project. When you scale up, the thing about Redux and all the Flux related patterns is they are invented to deal with scale. They’re invented to handle the cases where you have very complex states changes, and you might also want to collaborate on a team with multiple developers. In such cases, being explicit about what could potentially change, and being able to track what has actually changed when you’re debugging things become more important. But this is not intrinsically mutually exclusive with mutability. So that’s kind of the problem Vuex tries to tackle. Vuex is obviously heavily inspired by Flux and Redux, but it is, is essentially a specialized version of Flux that plays well with mutability and Vue’s reactivity system. So after all, I said, to me, I just feel like Flux, and even Redux, is more like a pattern of managing state rather than a specific implementation. Right? That’s why there are so many different implementations of Flux. Because overall, like the common goal that we’ll want to achieve is to make state changes predictable, maintainable and making the intentions of your code easier to be understood by another developer. I think if we can retain these characteristics, then it doesn’t really matter if your state is being directly mutated or you’re just returning a new copy of it. So one real benefits of returning immutable data copies is that you can - you naturally get snapshots of every state change. In Vuex, turns out stringifying a piece of state is fast enough in most cases. Unless you are doing like full snapshots undo / redo. Most of the cases it’s just fast enough to take a snapshot of the state that you want to track. And eventually another reason why the React community values immutability is because it makes it easier to optimize React component rendering. Because when you use immutable data, your shouldComponentUpdate becomes trivial to right, you can just use PureComponents. But in Vue there is no such problem, because when you use mutable reactive state, the system already knows which components should be rendered. So there’s no problem - the shouldComponentUpdate problem doesn’t really exist, which makes the argument for immutable data, again, less of a necessity. So that’s kind of the whole whole paradigm difference. Overall, the final development experience is actually pretty similar when you Vuex and Redux, because the only difference really is how you change the state. And Vuex is more straightforward, like you just mutate things, and it’s aligned better with how you would work with Vue without Vuex. So that’s the whole point. For the way, I think it’s also interesting how something like Rx observables come into play in this, because I find that the core idea about Flux is users will send out actions, and these actions are actually somewhat like raw intentions. There is a large chunk of work that the developer is still responsible for is to transform these intentions into actual state mutation or our state changes. So that process, when combined with asynchronous operations, becomes super complex. I think that’s kind of the place where Rx would fit nicely into. So when you have the whole picture of users dispatching an action, somehow it gets transformed by Rx into some final estate mutations that you want to see happen, and the system just automatically maps those mutations in terms of Vue updates. So this is a very high level picture of how I look at the problem. But I don’t think we have arrived at like a perfect solution yet. I still think like there are some unnecessary verbosity involved when you use all these flux patterns. I think there will be something that’s going to make it even easier. I think that somehow has to do with the limitation because we’re working inside JavaScript. Things might get a bit easier when you work outside of it, like you use a real functional language like Elm or Reason. That’s kind of out of the scope of Vue because Vue eventually is still a JavaScript framework.

Ray

What has your experience been like working with the data layer in Vue?

Sarah

Um, yeah, I think actually the reason why people keep re-quoting that quote that Evan quoted about the glasses is because it’s very true. I think it’s, it’s one of those things where you kind of know when you’re at the point where you need something, like Vuex or Redux or something like that. For me, a lot of times that has the most to do with one of two things, either I have a lot of siblings that need to speak to each other and I’m starting to have to toss state around in a way that makes it harder to reason about harder to read if you’re looking back at the code, and makes the code just like a little bit more messy. So that’s definitely a time when I would move over. And then another time is when I need to work with asynchronous data, that tends to be - like if I have to load a large sum of data and it has to go into a whole lot of different places that almost immediately calls for kind of Vuex or Redux kind of implementation. I think it’s actually like kind of amazing. Sometimes I marvel. I think I had like tweets where I marvel at how small Redux is for how intelligent it is. And again it comes back to my appreciation for simple code, not over engineered code. I think sometimes people like to flex their muscles and like, “oh look at all of this stuff I wrote and like, oh man, it’s really hard to understand, I must be really smart.” But I kind of like the opposite. I think it’s very, very challenging to write code that not only communicates to the browser but also communicates to the people who are going to read it. And it is again, just like what Evan is talking about in terms of picking the features that are for the most amount of use cases and not making things bloated. I think the way that you write things, you can write it so terse and be so proud of yourself for like the smallest amount of lines of code, but that’s not really legible for other people who are maintaining it. On the other hand, you can write it in this like really verbose way, where you did - you like passing state, like a hover state through three components - cool. You know, I think I’ve seen both use cases, and the answer for me is usually somewhere in between. I would never say that there’s a silver bullet for data handling. It usually comes with the complexity of what ever the situation is. So I steer clear of defining anything, but the web is a gray area and you use it when you need it.

Ray

Absolutely. And I can definitely echo what you’re saying. There are a lot of very small libraries which do amazing things, and I actually definitely subscribe to RxJS’ philosophy. I would love to have something like Rx but in a much smaller package. It is quite a heavy payload.

Evan

Yup.

Ray

So one of our cohosts Ben Lesh, who is one of the core maintainers of Rx. I kind of wished that he’s here and give us his take on it. We might have to bring you guys back to having that conversation with him.

Sarah

They’ll like insert him like a footnote, like he’ll just pop up like Clippy or something, “Hi I’m Ben Lesh I have things to say!”

Ray

[Laughs] Yes!

Evan

[Laughs] In a banana suit?

Sarah

[Laughs] Yes, in a banana suit.

Ray

Yes, he can be the Modern Web podcast Clippy. Every time Rx comes up, he just pops up from behind.

Evan

[Laughs] Oh yeah!

Sarah

[Laughs] Probably, you can animate that with the transition component.

Ray

Let’s talk a little bit about the onboarding process. I’m trying to think, if we have like a team of five engineers, and we’re trying to introduce them to Vue, have them consider it as something they will adapt for their big project. How is the onboarding process? How has the onboarding process been for you, Sarah?

Sarah

Actually, I think that this is really where Vue shines as well. I think actually the onboarding processes is very streamlined. It’s funny because people always start off with a hello world, and you kind of have to do like the simplest things. The way I started off, explaining the usefulness of Vue, was actually just going through using v-for, because just even doing that in vanilla JavaScript is less lines of code than it is in Vue. And I think some of the really, really quick bindings that you can do, v-model, and v-bind, and all of the click handlers, and all of those things. Especially for people who already know ES6 and have some familiarity with some of the power that we have available to us. You get to use that stuff right away and right in the DOM. I think that kind of manipulation just for rendering as a front-end is enormous. Excitement goes along way towards learning. I really believe that it’s hard to get excited. It’s like a story - it’s hard to get excited unless somebody picks up, read something really, really interesting right at first. Typically when I’ve helped people onboard with Vue, I’ve gone for some of the stuff that is like low hanging fruit of front-end that is kind of a pain to do either in vanilla JavaScript or some other framework or something and shown how elegant it works in Vue. And that tends to be like the aha moment for, you know, 9 times out of 10 people go, “oh, that’s really interesting”. That makes it a lot easier to explain some of the other principals. There’s a learning curve for everything. It’s just like everybody has a different way of writing. Everything is like a slightly different style. Even though Vue is a really beautiful framework, it takes some time to learn, and so getting people hooked on some of the cool stuff that is available to them really helps.

Evan

Yeah. I think on our part, most of the effort we spent is on the docs. We spend a lot of time refining our documentation. And I want to give a shout out to Chris Fritz, who’s our curator of our docs.

Sarah

Yeah he’s amazing.

Evan

He does an amazing job of just taking care of our documentation and improving stuff. But overall I think we try to - we try to write our docs in a way that we don’t assume too much about the user. Similar to how the framework itself is incrementally adoptable, we try to start the docs from a really small scope. We show you some really basic use cases, and then we go into these small sections where you can just [Inaudible] try it out in your browser. You don’t have to first setup a build tool pipeline, npm install 200 packages just to get started.

Sarah

[Laughs]

Evan

We give you this JSFiddle. You can just - or you can just pull in from a CDN in your HTML file, and you start experimenting and seeing how things are made. And I think that kind of helps people instantly a get what this whole, the core value of the library that it provides. And then, whenever a property we would touch upon things that people would probably at this point they would be thinking about, okay, how do I handle this? Then we would point them to the relative of the relevant section in the doc, dealing specifically about that problem, like build tools and large scale applications and all that. So I think this is - I think docs is probably a very important factor on user adoption. We heard multiple times people are saying it’s good. Funny enough, because there were several books out there about Vue in both U.S. and China, a lot of feedback I heard from people is like, why do you even need to buy the book? Just read the docs is good enough. Sometimes I feel sorry for the book authors.

Sarah

Yeah, I mean the guide is really, really well written. I think you can actually spend an afternoon and go through the guide and actually start to feel like you are getting somewhere, just through reading and doing the examples on your own and stuff like that. Which I think is unique. You know, that’s kind of like the Rolls Royce of docs, because a lot of times you read a bunch of docs and then you’re like, okay, now I need to like have a shot or something, like process all this stuff.

Evan

[Laughs]

Sarah

I don’t - I’ve never felt like that with the Vue docs. I felt like I was kind of like reading a book. You could just keep going and go through everything. So that’s good.

Ray

Cool. Well we’re running short on time, but before we wrap up, I would love to ask: how can other people contribute to Vue? What will help the core team?

Evan

Right now we’re actually spreading a little thin on our projects because we have many of them. But luckily we’re also seeing more and more PRs on fixing stuff. I think probably that’s the same problem for all the popular open source projects is the amount of work that we spend on triaging issues is very time consuming. We already pretty aggressively handle our issue process, but still there would be cases where it would be really helpful if people can help provide better reproductions, help testing the problem on different environments, and even better, submit failing test cases or fixes. I mean pull requests are always welcome. We are also trying to - I’m also thinking of doing a better job of onboarding more contributors because the 2.0 code base could be a little bit intimidating for users who haven’t had experience with working on large scale JavaScript projects. So this has been on my mind for awhile and hopefully we will have something like a contributor handbook that kind of walk you through how - if you wanted to submit a PR to Vue, this is what you should go through. Hopefully that will bring even more contributors. We’re already seeing a growing rate of PRs. I’m very happy about that. I think we can get even more.

Ray

Great.

Sarah

And he has a Patreon. [Laughs]

Evan

Oh yeah! [Laughs]

Ray

[Laughs] We definitely have to keep that one in mind for the show notes.

Sarah

You can give him money. [Laughs]

Evan

Oh, that would be a helpful way to contribute too. Yeah.

Ray

Cool. Great. Well thank you all very much. If people would like to learn more about Vue and learn more about your work, Sarah, how can people find you on the web, Sarah?

Sarah

Oh yeah. I have a Twitter account. I’m @sarah_edo, like the Japanese print. I am coming out with a front-end - I haven’t even told Evan this - I’m going to do a Frontend Masters workshop on Vue coming up in June. And then I’ll do a couple of other Vue workshops. I’m working on some kind of online content for Vue as well, but probably just like mostly I have a lot of CodePens where I play around with Vue and explain things that I’m doing with it. So CodePen is a really good place to find me. So I’m sdras on CodePen.

Ray

Cool. And Evan, how can people find you on the web?

Evan

So my Twitter handle is the spelling of my Chinese name, [Sings] y-o-u-y-u-x-i really hard to remember, but the easier account to remember is just @vuejs, that’s the official Vue.js account. We will be retweeting useful resources and posting new releases, announcements. So if you’re interesting in Vue.js, you should definitely follow that account. We’re also having a conference in Poland later this year and in June. We are actually starting to sell tickets very, very, very soon, so you can find more details at conf.vuejs.org.

Sarah

Yeah. And I’ll be there as well. [Laughs]

Evan

Oh yeah. Sarah is going to be speaking. Yes.

Ray

Very cool. Awesome. Well thank you all very much and thanks everyone for tuning in. If you enjoyed this episode, please rate us on iTunes. It really helps. You can find more Modern Web podcasts and meetups on Twitter @moderndotweb and on the web at modern-web.org. We’ll see you soon on the next episode.

Updated
June • 2019

I'd love to hear what you think about this essay. Your feedback makes my work better. You can chat with me on Twitter and Hacker News .