CHUCK: I’m Charles Max Wood from DevChat.TV. Quick shout-out about JS Remote Conf. It’s going to be in January, in the middle of it. So, go to JSRemoteConf.com to check it out. We also have a special guest this week and that is Evan You.
EVAN: Hello, everyone.
CHUCK: Do you want to introduce yourself?
EVAN: Sure. My name’s Evan You. So, I’m the author of Vue.js. And I currently work for Meteor as a core developer. So, Vue.js is my personal project. But I also work for Meteor.
CHUCK: Do they have like, I don’t know, action figures? So, they have the Vue.js action figure and the Meteor action figure and pew, pew, pew, pew, pew, pew!
EVAN: I wish we had them.
EVAN: We do have stickers.
CHUCK: Ah. So, they’re totally okay with you writing a competitor.
EVAN: Well, it’s not strictly a competitor.
CHUCK: Oh, come on. I’m creating drama here.
EVAN: [Laughs] We do have a view layer solution called Blaze inside Meteor. But I started working on Vue.js before I joined Meteor. And I’ve just been working on it ever since. But the point is Meteor now supports both Angular, React, and Blaze. And there are community packages that allow you to use Vue.js inside Meteor. So, strictly speaking there’s really no competition there.
CHUCK: So, Vue.js works with Angular, Ember, and friends?
EVAN: So, when I’m saying no competition it means Vue.js has no competition with Meteor, but it sort of competes with Angular and Ember because they’re all front-end frameworks.
EVAN: So, Meteor is full-stack which means…
EVAN: So, you can use other front-end frameworks inside Meteor if you want to.
CHUCK: So, what’s the difference?
EVAN: Between Meteor and the other frameworks?
CHUCK: No, between Vue and say Angular or Ember.
AIMEE: So, I’m really curious. We have all these other frameworks right now. And probably a popular reaction you would get from many people is maybe an eye roll.
AIMEE: But what motivated you to build this? And taking a look, it really reminds me a lot of Angular 2. So, it looks like maybe you’ve taken the good parts from what they’re doing in Angular 2, the good parts of React. But what really motivated you to work on this?
EVAN: Well, I actually started working on this almost two years ago. So, it’s way earlier than Angular 2. It’s just a little bit later than React. And it’s definitely way before React caught on. So, some of the original motivation was, I was using Angular for some of the projects I was working on. So, at that time I was working at Google Creative Lab. So, some of my coworkers were using Angular and we were using Angular for some projects. And I just felt Angular was overly opinionated for certain types of projects. The interesting thing about front-end, the front-end world, is you have projects of [inaudible] scale. You have small, quick dirty ones. You have huge projects that require a lot of structure and you have tens of developers working on. But you have some of those projects like you have only one or two person and you just want to get something out as quickly as possible without having to, like going through all the overhead of a huge, full-stack framework.
So, I felt like there’s some opportunity there where Angular provides this great data-binding productivity boost. However, it also gets in the way sometimes for smaller projects, and often for beginners as well. The learning curve is just not so beginner-friendly I would say. So, I started building some sort of lighter weight alternatives. And in that process I also took a page from some other things, like the main difference between Angular is that it doesn’t try to overload you with all these concepts of scopes, controllers, factories, providers, and all that. In Vue.js everything is just a view instance. So, the Vue instance, if you think of it, is more something like the view model in the MVVM pattern.
So, I would say in terms of scope, it’s really similar to Knockout, both in terms of a very lean view model based approach, and also the reactivity model. But the difference between Vue and Knockout is Vue takes the plain object reactivity route. So, it uses the ES 5 Object define property method to convert your plain objects into, all those properties, convert them into reactive getters and setters. So, when you manipulate those plain objects, your view just updates. And also, Vue was probably one of the earliest frameworks to just embrace the ‘everything is a component’ sort of architecture. It’s very similar to React in that aspect. So, every view instance is a component and you just compose your application as a tree of components.
AIMEE: So, would you say, because what I heard you say and what I’ve heard from some people who have been talking about Vue, would you say that the best use case is for smaller applications? Or do you think people should look at it if they have an application now that might need to scale up in the future?
AIMEE: Yup. I’ll plus one that, too, from a beginner’s perspective. It was extremely easy to follow.
EVAN: Right. So, that’s part of the design goal. I want to provide the benefits of data binding and all the reactivity data-driven view with an API that’s as simple as possible. But on top of that, it doesn’t mean we cannot build complex applications with it. Because in that aspect, it’s similar to React. Because React core itself is just a view layer, right? So, it’s basically, you get some state, you render it into a virtual DOM, and that’s it. The React core doesn’t concern itself with how to structure your application, how to set up your build tools or all that. It’s like community conventions and it’s also why you need Flux to help you structure your applications.
So, it’s more or less like you get to pick how much you want to adopt the Vue approach. If you are just looking for some light features, you can just use those features. But if you want to build a full SPA, you can opt into the more opinionated way of doing a full SPA if you want to.
CHUCK: I was actually going to ask something about this, and that is that… so I see in the Getting Started example and some of these other ones, you just do ‘new Vue’ and then it has certain properties to it that you’re assigning. One thing that I’m wondering is, it shows an element that’s being assigned. Can you have these overlap elements? So, for example if I have an entire app and then inside the app I have something else that I want to add, some other functionality to.
EVAN: Right, right. So, that’s where the component system comes in. So, all the Getting Started guide assumes you are just having a simple, single instance. So, the guide is really written assuming a total beginner background.
EVAN: Once you are familiar with the basics, we move onto the component system where basically everything you’ve been doing in these basic examples can be encapsulated as reusable components. So, once you define and register a component you can use them in other components. Just add some custom element. So, it works more or less the same way like Web Components. Except you don’t need the polyfills.
CHUCK: Gotcha. I do like the syntax there where it’s all self-contained in one object. The other thing that I’m wondering about is, is there a way to pull in data say, from some third-party system, some backend system?
CHUCK: So, does it sync it back the other way? Or are you responsible for that?
EVAN: So, in terms of data persistence you definitely will have to sync it back the other way. So, you need to make the calls to the server to [inaudible] things back. But the thing is, once you manipulate those data, if you want to persist them back to the server it’s as simple as JSON.stringify because it works exactly the same way as a plain object.
CHUCK: The other thing I guess I’m wondering about is, with the DOM manipulation, are you doing that with jQuery or are you doing that with something else?
EVAN: DOM manipulation is purely, it’s sort of like we implement a similar system to Angular where you bind stuff to directives. So, the directive is responsible for mapping any data changes to DOM manipulations. Say, when you have a directive that controls the visibility of an element, you bind that directive to a property on your instance, instance data. So, whenever that property changes, the DOM will basically be manipulated accordingly to reflect the latest stage of your app.
CHUCK: Right. But that manipulation, is that all done custom? Or are you…?
EVAN: Yeah, that’s custom.
EVAN: Mmhmm, right.
CHUCK: So, looking at this it looks like it provides more, you were talking about directives a minute ago. Do you build those directives directly? Can you build your own directives for one?
CHUCK: And do you build those directly into your same, when you new up a new Vue? Or do you attack that a little differently?
EVAN: So, you can define the custom directives both either globally or locally. So, it’s up to you. So, you can register a custom directive as a global one. So, every single instance will have access to it. Or you can, when you declare a new instance or define a component, you can limit a custom directive to that specific component. So, it’s only available to that component.
AIMEE: So, you’ve been working on Vue for a while. Who else is using it?
EVAN: Quite a lot of people, actually. So currently, I know quite a few companies just built their, start-ups actually, built their product on it. So, I’ve got users in Japan, in Russia. It’s pretty interesting how the adoption is quite organic. And the [inaudible] community is currently pretty psyched about Vue because the author of Laravel is using Vue for his project. And Laracasts has been doing a series on Vue.js. So, in terms of companies, there was large-scale usage. For example, Optimizely has been using Vue since the 0.10 days. That was like, really, really early. And Grammarly has been using Vue.js 2. I do have a very incomplete list on GitHub where people sort of just contribute what they’re doing with Vue. So, it’s called awesome-vue.
AIMEE: I guess I could see some people maybe being a little bit nervous about using Vue for a couple of things, like with it still being somewhat new. But then also, when you’re looking at something like Angular or React, you have a lot of people working on the framework. So, is this something that you are able to set aside more time for? Are you going to have help working on it? What would be some things you could say that would convince people that they should go for it and that it’ll be around for a while?
EVAN: Right. So, I actually get asked that question a lot. Like say, there are frameworks that get sponsored. They have full-time teams working behind it. But a lot of times, I’ll rather look at the numbers. So, if you go to the Vue.js repo on GitHub you will see that the number of issues that’s currently open is under 20. And…
AIMEE: I did see that. That’s awesome. [Chuckles]
AIMEE: I think when I looked the other day, it might have been 11. [Chuckles]
EVAN: Right. So basically, most of the bugs, I fixed it within one day or two. And the consistency of how issues are responded to, I think is more meaningful than how many people are actually working on it. Because when you look at the page, just look at how many open and reproducible bugs that’s currently open. So for Vue, there have been more than 1400 issues and the currently open issues are under 20. And there’s basically, I would say there are currently maybe one or two reproducible bugs that are not closed at the moment. And when I wrote the 1.0 release blog, there were literally zero reproducible bugs. And most issues are closed within a day. I have been basically maintaining 100% test coverage on every single commit since the 0.11 rewrite. So, that’s I think more than a year ago.
And I guess it’s more or less up to how users would value what they get out of it. Like for people who prefer this sense of knowing that something is sponsored or something has a full-time person working on it versus knowing, looking at the track record, seeing that things are being consistently attended to, seeing this project is being actively maintained, seeing that bugs are getting closed, I think it’s really up to how you would interpret these, right? So, even with a full-time team you would still see projects that have tons of bugs, that’s not closed, that’s not being actively attended to.
CHUCK: So, where are you hoping to wind up on Vue.js? Have you arrived there with version 1? Or do you have plans for it in the future?
EVAN: So, that’s actually a question I myself am [chuckles], I’m not really sure about it. Because Vue started out as something really small. It’s like an experiment. It accidentally got interest from some early users, so I decided to work on it a bit more. So back then when I released it, it was more or less just an experiment to see if it’s possible to do a fully reactive system using the ES 5 getters and setters. It turns out it worked and it turns out there are actually people using it. And that’s why I still kept working on it all this time. And there are times that I basically just put it aside in thinking, just no really paying much attention to it. But after a while there are always some events that someone discovers Vue, makes them rave about it.
And for example, this latest event was the Laravel community discovering Vue and they get very excited about it. So, this type of event keeps me motivated on working on this. And seeing that people are being, the users being really grateful about something that you worked on is probably the most important factor.
In terms of how the future goes, I think, I want to make Vue one of the legit choices when you are starting a new project. Because I believe, like as I said, the front-end projects, you have all sorts of needs. You have different team environments. You have different stylistic preferences. You have different project requirements. It’s unlikely that there’s one framework that’ll just fit all the use cases. And I believe there has the room for something that is super easy to get started with but also doesn’t limit you to simple applications. And I think Vue basically serves that special role in that it’s easy for you to get into but can basically stay along with you even when you are building large and complex applications.
CHUCK: So, the follow up question here is, what is it not good at? Like if somebody came to you and said, “I want to build something.” You would say, “Oh, no don’t do that.”
EVAN: Right. So, one thing is probably the biggest difference with React in this sense is React has React Native. So, that’s an area that Vue has basically no intention to getting to.
CHUCK: What about testing? How does it stack up when you’re testing it?
DAVE: Cool. So, I have a question. This is Dave, by the way. Sorry I’m late.
DAVE: Just happy to be here. [Chuckles] Nice to meet you, Evan.
EVAN: Nice to meet you.
DAVE: So, I went through the Vue tutorial, which was very interesting. And one of the things that occurred to me as I was going through is I could take an Angular app and do a search and replace, replace ‘ng’ with ‘v’ and pretty much have a Vue app. Was that on purpose or did those two designs emerge separately?
EVAN: So, Vue is definitely inspired by Angular. So, in the parts you missed, we talked earlier about how Vue was born out of the frustration of the learning curve issue and all the extra concepts that I deem unnecessary for front-end development. So definitely, the data-binding part is a direct heritage from Angular. It’s largely inspired by Angular and you will see that a lot of terms are actually the same with Angular 1 like directives and filters. So, the concept is largely the same.
The biggest difference lies in the reactivity model and how opinionated the framework is. So, in Angular the reactivity model is done through dirty-checking, right? So, for every directive you will have a watcher that is bound to an expression. And the way Angular updates your UI is it needs a signal to basically trigger the system to enter the digest cycle. So, it just basically loops through all the watchers on the page, reevaluates every single expression, and if the value of the expression changed, it will update the DOM accordingly. So, this model works.
But the issue is that a lot of people talk about Angular and they say, “I would run into performance problems because I have too many watchers.” So, that’s the issue. Because when you have too many watchers, any single small change on the page would actually trigger all the watchers in its current scope and its child scopes to reevaluate. And it’s really hard to limit how many watchers this digest cycle affects. Because if you really need the reactivity, you can’t really cut them.
DAVE: Oh, interesting.
EVAN: Right. So, after we do that, we basically get a purely dependency-tracking based system that’s really similar to Knockout. So, Knockout uses a very similar reactivity model. But in Knockout, every getter and setter is explicitly a function. You have to create a Knockout observable object, a wrapper function that wraps your value. But in Vue you don’t have to do that. So, this gives you much better [interoperability] in terms of data APIs. But also gives you a purely dependency-based reactivity system. So, when you change, when you have a Vue app…
DAVE: Okay. That is really cool, by the way.
EVAN: Thanks. So, let’s say you have a Vue app with a lot of bindings on the page and you change one single data field, so only the one single binding that’s affected by the change would get notified. And all the other bindings on the page have nothing to do with that change, then they would just do nothing. So, from a performance perspective this makes Vue apps really [simply] optimized because…
EVAN: Really, there’s nothing you need to do. How much data you change means how much part of your app will be re-rendered. It’s just all proportional.
DAVE: That’s super cool. So, it’s almost like the best of both worlds. You get these nice template declarative HTML, but you get the speed of React, like tree [inaudible] all in one, right?
EVAN: Right. So, it probably is different from React in that sense. I would even say it’s… so, I actually do a lot of comparison with React, too. So, in virtual DOM diffing, if you think about it, it’s more or less dirty-checking on the view layer.
DAVE: Yeah, yeah, basically, yeah.
EVAN: Right, right?
EVAN: So, say you have a huge React app and you change a single field and you set state on a very high-level component…
EVAN: That means that, that component and all its child components, that whole subcomponent tree needs to be re-rendered and diffed again.
DAVE: Not re-rendered, but well yeah, regenerate the virtual DOM, right?
EVAN: Right. Like a virtual DOM re-render.
EVAN: And then you need to go through the diff. So, the idiomatic way to improve that is you have to implement ‘should component update’ or use immutable data structures.
DAVE: Right, right.
EVAN: But both of these would introduce a lot of extra work. It’s just something you don’t even need to worry about when you’re using Vue, because even if you change a data field on a very high-level component, it doesn’t really affect anything in your subcomponent tree if those components are not interested in that piece of data.
DAVE: Okay, that’s really clever. And so, the trade-off there is that you can’t support IE8, right?
EVAN: Yes. Another trade-off is, so Vjeux, Christopher of the React team, so he gave a talk earlier about the optimization of animations in React. And that’s actually a talk where he highlights this performance difference in terms of changing a very small piece of state in your huge application. Because in React, if you do that at 60 frames per second, you would actually run into performance issues, even if the virtual DOM re-render is fast. You would still, it’s still not fast enough if you’re doing it 60 times per second. But the trade-off for a data-binding system is we would have to set up all these reactivity system. We have to convert these properties. We have to set up the watchers, the bindings and all those.
So, this is a lot of extra work at startup time. And it does impose a bit more memory usage, constant memory usage. So, it’s a trade-off. But most of the time, the difference is not that significant at the boot up time. And also, when you are using a React app, if you’re regenerating huge virtual DOM trees on every re-render, then it’s also a lot of memory usage and GC time.
DAVE: Oh, yeah, yeah. Yeah, my experiences actually with React with gigantic virtual DOM trees, it’s actually much slower than an equally sized set of dirty-checked scopes. In other words, the tree diff algorithm is pretty intense comparatively, at least for some of the tests I’ve done. But you’re saying with Vue, you bypass all of that with the trade-off being that you have to do some initialization upfront to make sure you got your define, what is it called, define property…
DAVE: Stuff all set up on all your data objects.
DAVE: Very interesting. So, are there any edge cases where a developer could inadvertently change their data model without Vue knowing?
So, this is actually very good practice because from the maintainer’s perspective, when you look at a component later, you instantly see what properties on this component could potentially be reactive. And if you add properties on the fly, it becomes really hard to track down when you edit that property. So, it ends up helping enforcing this best practice. And if you just declare all your properties upfront, you would actually never run into that problem.
DAVE: So, I see that you’ve got some documentation about how to package up Vue apps using Webpack. Would it be okay to talk about that for a minute?
Say you have a style section in your component and you don’t want to use plain CSS, you can actually use whatever pre-processor you want. All you need to do is declare its language in a Vue component and use LESS, SASS, or PostCSS, whatever you want. So, the vue-loader will extract CSS, pipe it through another loader, and reassemble everything together back into a CommonJS module. And your app will just work. And it supports hot reloading using Webpack’s hot module replacement API. So, when you edit the style, you edit the template, it just reloads without reloading your page.
DAVE: Oh, very cool. So, I noticed one of the things as I was going through the guide was that Vue will warn you if you use what looks like a custom tag in your markup but it’s not a registered component with Vue, right?
DAVE: Which I found really cool. But one of the things that I found template systems like Angular 1, Angular 2, and Vue seem to suffer from is that I can’t follow a dependency tree easily, for example like a RequireJS dependency tree that Webpack can normally follow. How does it know exactly which templates need to be included in a bundle when you do that? Or does it bundle them together at all?
DAVE: But in the template itself…
EVAN: Oh, I see.
DAVE: I can use components but I don’t declare that I’m using them anywhere, right?
EVAN: You do. So, in Vue when you register any type of asset, say a component or a custom directive or a transition effect, these are all considered assets. So you can either register them globally using a global Vue method but that’s only for quick and dirty small projects. So, in large projects you will have to pass them into a specific component as its private assets. So, if you look at the example, like when you declare a component you can have an option called component and that’s where you basically declare what other components should be available to this component.
DAVE: Cool, I see now.
EVAN: Right. So, you…
DAVE: So, that’s like Angular 2 style, right?
EVAN: Yeah, except Vue doesn’t really force you to use dependency injection.
DAVE: Oh, right, right. Cool, so what kind of benchmarking have you done to compare performance of Vue to other frameworks, or have you?
EVAN: Yes. So, it’s actually pretty interesting because in the early days of Vue there was this TodoMVC benchmark floating around that was originally written by someone at Apple working on WebKit. So, it was on GitHub. It wasn’t really published anywhere. I just happened to stumble to it. And it was testing the same TodoMVC application using most of the mainstream frameworks. I think it got popularized even more later by the author of Ohm. David Nolan, he had a post on how he built Ohm on top of React and had better performance in that benchmark.
So, I was really curious. I ran a benchmark and it turns out, Vue is really fast. It’s the fastest of them all. And for some reason, it was actually the benchmark itself was more or less flawed because it was synchronously adding, toggling, and deleting a hundred items one by one. And Vue leverages asynchronous updates. So, say when you are manipulating the same array, you’re pushing an item in a loop, you push 100 items, Vue actually only performs one update. Because whenever you trigger some data change in an event loop, Vue won’t instantly update the DOM. Vue will buffer all these data changes until the next tick before actually performing any DOM updates. So, this avoids doing unnecessary work when you are, say, mutating the same array a hundred times in the same event loop because there’s just no point in doing that. And because of that specific benchmark, Vue just is significantly faster in the benchmark. So, I posted it all on the original Vue website and it basically got a bit controversial. Because other framework authors…
DAVE: [Chuckles] I know how you feel. [Laughs]
EVAN: Right. So, the Ember guys were actually pretty angry. Stefan, I’m definitely not trying to badmouth anyone. It was just an interesting conversation where Stefan was looking at my benchmark and saying, “This is not idiomatic Ember code. If you want to get the real number, you should do this and that.” I was like, “Okay. But why don’t I have to do that in Vue to get these numbers?” So, basically it went back and forth. And in the end we more or less agree that the benchmark itself wasn’t a perfect reflection of real-world performance. So, I eventually took it down. But interesting enough, later on Elm actually used that benchmark to showcase its performance. That benchmark even got included in a talk by the author of Clojure, in one of his talks. So, whenever I see that benchmark referenced elsewhere I always kind of feel like, a bit guilty because I sort of contributed to this thing. I want to explain that this benchmark is not a perfect, basically all micro-benchmarks are somewhat misleading.
DAVE: Of course, yeah.
EVAN: And so, another benchmark I did was one of the js-repaint-perfs, when Ember team announced their 2.0 rewrite of the Glimmer engine. So, they released this thing called dbmonster where it’s like re-rendering a page…
EVAN: Of like…
DAVE: From Ryan Florence’s talk, right?
EVAN: Right. So, that sparked a lot of people doing the same benchmark using their own frameworks. So, Vue has that, too. In case you are interested, there is a project called js-repaint-perfs on GitHub. You can search about that. And yeah, Vue is doing pretty well. Actually Vue renders the thing faster than React. And that’s for the case when we are replacing the whole data with brand new data. So, like you have an array of 500 items. Actually, a hundred items with more nested items, right? So, every single re-render, Vue has to reconvert all those objects to become reactive and Vue is still showing faster numbers than React. And Vue actually prefers mutation than full replacement. So, if you optimize even further and just do in-place mutation instead of full replacement, Vue’s number just goes off the roof. It’s like 80 frames per second or something. So yeah, again these are benchmarks so I want to emphasize every benchmark is more or less only testing one specific situation. So, I sort of came to the conclusion that when you’re evaluating the performance of a front-end framework, you have to consider all different scenarios. There is the initial render performance. There is the hot update but only changing a small part of your state. And there’s the full replacement, like you’re just completely shoving a new state tree into your app. So, these are all three very different scenarios. So, Vue is relatively slower at the startup, like when comparing to React. However, it’s significantly more efficient for small updates and is comparatively peformant when you are doing full-state replacement.
DAVE: Super interesting.
CHUCK: Yeah. Alright then, before we get to the picks I just want to acknowledge our silver sponsors.
[This episode is sponsored by Thinkful.com. Thinkful.com is the largest community of students and mentors. They offer one-on-one mentoring, live workshops, and expert career advice. If you’re looking to build a career in frontend, backend, or full-stack development, then go check them out at Thinkful.com.]
CHUCK: Dave, do you want to start us off with picks?
DAVE: Oh. Let us see here. You caught me by surprise. I didn’t know we did picks.
DAVE: Yeah [chuckles]. Yeah, so I have one pick for you today. This is in the entertainment genre. This is a Netflix original series that I’m sure is old news. And I will say that if you don’t enjoy a little bit graphic violence, you probably won’t enjoy this show either. But the show is Daredevil. And it’s continuing in the now very popular theme of superhero TV shows and movies, which I just, I don’t know why but I love them. I think it’s probably because I used to try to fly as a kid and never could. So anyway, Daredevil on Netflix. I enjoyed it even though I had to close my eyes, literally close my eyes for some of the scenes because they were so graphic. But other than that, I really enjoyed the story and the characters were super cool. So, that’s all I have for you today.
CHUCK: Alright. Aimee, what are your picks?
AIMEE: Okay. Dave, I’m happy to know that you also did that, because I was obsessed with Michael Jordan and I also thought that I could fly.
AIMEE: Like in his movie.
AIMEE: I used to just also sing the song ‘I Believe I Can Fly’.
CHUCK: [sings] I believe I can fly.
AIMEE: [Laughs] Anyway, but also speaking of entertainment I also have an entertainment pick but it’s a different sort of entertainment. I feel like this may have been picked way, way, way before I ever listened because I may have heard this on Ruby Rogues at some point a long, long time ago. But I have not heard it picked on JS Jabber since I’ve been listening. But it is this YouTube channel. And they have all these different sorting algorithms that are done by Hungarian dancers.
DAVE: Oh, I love that.
DAVE: I love it.
AIMEE: So, it is absolutely awesome. It’s entertaining and it’s also educational.
DAVE: You have to watch it on fast forward though, because it’s so long.
AIMEE: [Laughs] Yeah, well I guess it would depend on which algorithm you’re watching. [Laughs] But [inaudible]…
DAVE: That’s a good point.
AIMEE: But I say that that’s entertaining but it’s also, if you’re a visual person like I am, it’s actually very beneficial to see. So, that is my pick for this week.
CHUCK: Alright. I’ve got some picks that are a little bit more, I’ve just been playing with this and I’ve been really enjoying it. I’m actually inviting the DevChat.tv community to join this particular pick. And what it is, is it is, it’s called RelativeFinder.org. And it uses the free online database at FamilySearch.org to do its lookups. And if you’re in the same group as other people, you can find out how you’re related to them.
So for example, I joined a group that had my mother-in-law in it and found out that my wife and I are 13th cousins once removed. But it also tells you who, like famous people you’re related to. It has authors and poets, catholic saints and popes, constitution signers, declaration signers, that’s U.S., European royalty, famous Americans, famous Europeans, et cetera, et cetera. So, in here just to name a few, I’m related to Henry David Thoreau, Robert Frost, Samuel Clemens who’s Mark Twain. I have a 10th great-grandmother listed here in the Salem witch trials who turned out to have been executed as a witch.
CHUCK: I have five people from the Mayflower including my 12th great-grandfather. I’m related to Barack Obama. We’re 13th cousins once removed and a whole bunch of other presidents. JFK, George Washington. Anyway, it’s been really fun to just look and see how I’m connected to people that I’ve heard of or people that I know, because there’s a group in here with my neighbors in it. So, I’m related to Richard Nixon and Millard Fillmore. And anyway, it’s been really, really fun. So, if you want to sign up and get in, you have to have an account on FamilySearch.org that is free. And then you can go over to RelativeFinder.org and just sign in and it does an OAuth thing or something to get you in. Oh, I’m also related to Walt Disney, 10th cousin three times removed. So, it’s just really kind of cool to see who I’m related to. Elvis Presley, Charles Lindbergh. Anyway, I’ll stop. But I’m really, really enjoying it.
If you get in and you want to see if you’re related to me or related to other people in the community, I created a group called DEVCHAT and the password is devchat. The group name is all uppercase and the password is all lowercase. But by all means, hop in and then shoot me a tweet or an email or something and tell me how we’re related, because I think that’d be way fun.
Evan, what are your picks?
EVAN: First pick is a leather good brand called Hard Graft. Anyone’s heard of it? It’s a UK brand. It just makes really good leather goods. I got them for a birthday and it’s just so good.
And the other one is an interactive piece called Piano Phase. It’s made by Alexander Chen who is my former boss at Google. And he just does all these crazy music visualizations using web technologies. It’s super cool and you guys should check it out at his website which I’m posting here. Amazing music visualizations.
CHUCK: That sounds like fun. Alright. Well, if people want to know more about Vue.js or about what’s going on with you Evan, what do they do?
EVAN: Just follow Vue.js on Twitter. Join the Gitter chat room or throw the question on the Vue.js forum. It’s all on the website.
CHUCK: Alright. Well, we’ll go ahead and wrap up the show and we’ll catch you all next week.
[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]