JS Remote Conf will be held from Thursday, January 14th - Saturday, January 16th! Sign up today!

 

01:59 - Evan You Introduction 

02:34 - Vue.js vs Competitors and Motivators Behind the Framework

07:18 - Use Cases

10:06 - Overlapping Elements and The Component System

11:21 - Pulling in Data

12:50 - DOM Manipulation

13:38 - Ease of Getting Started

15:33 - Directives

16:18 - Adoption

19:50 - The Future of Vue.js

21:59 - What is Vue.js Not Good At?

23:07 - Testing

24:06 - Vue, Angular, and React: Reactivity and Performance

29:06 - Tradeoffs

30:54 - Edgecases

32:14 - webpack

33:46 - Bundling

35:38 - Benchmarks

 

More on Vue.js

On YouTube
187 JSJ Vue.js with Evan You

Picks

Daredevil (Dave)
AlgoRythmics (Aimee)
Relative Finder (Chuck)
FamilySearch (Chuck)
Hard Graft (Evan)
Piano Phase (Evan)

Special Guest: Evan You.

 

Hey everybody and welcome to episode 187 of the JavaScript Jabber Show. This week on our panel we have Aimee Knight.

Hello.

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.

Hello, everyone.

Do you want to introduce yourself?

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.

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!

No?

I wish we had them. [Chuckles]

We do have stickers.

Ah. So, they're totally okay with you writing a competitor.

Well, it's not strictly a competitor.

Oh, come on. I'm creating drama here.

[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.

So, Vue.js works with Angular, Ember, and friends?

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.

Aha.

So, Meteor is full-stack which means...

Right

So, you can use other front-end frameworks inside Meteor if you want to.

So, what's the difference?

Between Meteor and the other frameworks?

No, between Vue and say Angular or Ember.

So, I did write a blog post about this. So, the gist of it is the most unique thing about Vue is probably its reactivity system where it takes a very different approach from other major frameworks. So, in case people don't know, Angular uses dirty-checking, React uses a virtual DOM. So, Vue uses a similar data-binding system to Angular. However, it converts all your plain JavaScript objects into reactive ones. So, once you set up a Vue.js instance, your plain JavaScript objects become reactive. So, you just manipulate them any way you want and your view updates accordingly.

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. [Laughter]

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?

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.

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?

So, here's the interesting thing. So, Vue started out as, out of my frustration with the learning curve issue of Angular. So, I deliberately designed it to be very beginner-friendly. Like the API is really, really simple. Like if you just look at the Getting Started guide, anyone experienced with JavaScript should be able to just pick it up within one hour or two.

Yup. I'll plus one that, too, from a beginner's perspective. It was extremely easy to follow.

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, that's the same case for Vue, right? The core library itself doesn't concern with all the higher level decisions. However if you want to, you can apply those things and combined with the right tools, you can use Vue to build complex, large applications. So, over time I have been basically building a lot of supporting libraries for Vue. So, Vue.js itself, if you just pull it directly from a CDN, you can just drop it onto an existing page and just add some interactivity to the page. But if you go the other, basically go the hard way, you start with Webpack, you start with a specific loader I wrote for Vue called vue-loader. You will basically get the benefits of being able to write a component in a single file that encapsulates the style, the template, the JavaScript logic, and at the same time you can still use pre-processors and you get hot reloading and all that.

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.

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.

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.

Mmhmm.

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.

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?

Yeah, definitely. So actually, the beauty of this reactivity system is because everything is just plain objects. So, it's basically trivial to integrate it with any third-party data source. So, say you have an API call and you got back some JSON object, you just set it on the instance and you're done. So, any API that returns plain objects can just be directly shoved into a view instance and it becomes reactive. It's really that simple. So, this means we can do just direct HTTP calls, Ajax calls. You can use it with a RESTful resource library. We do have the vue-resource plugin that's contributed by the community. And if you want to, you can use it with Firebase. You can use it with Meteor. Essentially everything, anything you want to plug into as long as it gives you plain JavaScript objects, it'll work.

So, does it sync it back the other way? Or are you responsible for that?

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.

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?

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.

Right. But that manipulation, is that all done custom? Or are you...?

Yeah, that's custom.

Okay.

We talked a lot about how much you focused on trying to make this easy for people to jump on board with. One thing, I've done a lot with Angular. I've done a small amount with React. And also in teaching other juniors Angular. I feel like it is very easy as a junior to get sucked into the DSL, or some of the specifics of Angular without really understanding JavaScript itself.

Mmhmm, right.

So, I feel like that is one strength of React. Do you think that Vue also offers that strength then? That it'll make you a stronger JavaScript developer because you're having to understand more JavaScript and less of the framework.

I would say it's definitely better than the Angular case, because Angular tries to force you to think of everything in terms of how the framework dictates you to do. So, Vue tries to be as unopinionated as possible. So, there is one opinionated part where the reactive data in your view instances should just be plain objects. But other than that, yeah it's mostly plain JavaScript. So, a typical Vue.js app even at large-scale is composed of all these small components.

declaratively describe what this component does. Like, what's its initial data state? What methods can it have? What template does it have? I would say there's definitely some more framework-y parts in Vue than React because React essentially is all JavaScript. But Vue tries to get out of your way as much as possible. So, I would definitely say being a better developer will make you a better Vue developer.

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?

Yeah.

And do you build those directly into your same, when you new up a new Vue? Or do you attack that a little differently?

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.

So, you've been working on Vue for a while. Who else is using it?

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.

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?

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...

I did see that. That's awesome. [Chuckles]

Right.

I think when I looked the other day, it might have been 11. [Chuckles]

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.

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?

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.

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.”

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.

Mmhmm.

And the Angular team probably has ambition in that area, too. Because all these frameworks, they're trying to turn themselves into paradigms. They are trying to dominate all the UI development on all clients. And that's what I see the React team is trying to do. They are trying to turn React into this dominant paradigm for developing all UIs for all clients. And Vue is not trying to do that. It's trying to provide you with this very pragmatic solution for the web. If you are familiar with JavaScript, HTML, and CSS, then you can pick up Vue and get productive in a day. So, that's the goal. That's about enabling people to do things quick and fast. It's not about reinventing something that's totally revolutionary and just overthrow everything that's in this instance.

What about testing? How does it stack up when you're testing it?

So, the easy answer is because every Vue.js is eventually compiled down to a CommonJS module, anything that can test a CommonJS module can be used to test a Vue component. And because of Vue's, basically the way Vue is designed, we try to make it very, very... your Vue model will end up really, really DRY. And it's almost entirely about manipulating some plain objects. So, that makes it super easy to test. For example, when you have a component that handles your user action, you don't really have any sort of DOM manipulation in your JavaScript code. It's all about pushing an object into an array or just setting a property. So, these things are super easy to test and assert. So, Vue doesn't really provide any sort of tooling or infrastructure for you to do that, but anyone experienced with basic JavaScript unit testing should be able to just do that.

Cool. So, I have a question. This is Dave, by the way. Sorry I'm late.

Hello.

Just happy to be here. [Chuckles] Nice to meet you, Evan.

Nice to meet you.

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?

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.

Yeah.

Like you can sometimes use one-time bindings or things like that. But if you just do have so many things on the page, you basically have an app that's really hard to optimize. So, the difference with Vue is we have a real dependency-tracking based reactivity system. And it's all hidden under this plain JavaScript syntax. So, we convert your data object's properties into getters and setters using the Object define property method. And after we do that...

Oh, interesting.

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...

Okay. That is really cool, by the way.

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...

Mmhmm.

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.

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?

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.

Yeah, yeah, basically, yeah.

Right, right?

Mmhmm.

So, say you have a huge React app and you change a single field and you set state on a very highlevel component...

Mmhmm.

That means that, that component and all its child components, that whole subcomponent tree needs to be re-rendered and diffed again.

Not re-rendered, but well yeah, regenerate the virtual DOM, right?

Right. Like a virtual DOM re-render.

Yeah.

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.

Right, right.

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.

Okay, that's really clever. And so, the trade-off there is that you can't support IE8, right?

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.

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...

Right.

Stuff all set up on all your data objects.

Exactly.

Very interesting. So, are there any edge cases where a developer could inadvertently change their data model without Vue knowing?

Yes. So, there are some limitations of JavaScript the language. So, one of the issues is assuming an ECMAScript 5 environment, we cannot detect addition and deletion of properties. So, it's possible with Object.observe, but it's being [chuckles] [curtailed] from the spec, unfortunately. So yeah, so the limitation when you add a property, you will not be able to pick it up. However, it actually forces the developer to, the recommended approach when you're declaring data in your view is sort of like how you would declare get initial state in a React component. You would have to declare all the properties you want to be reactive upfront. And it becomes a schema of your component instance.

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.

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?

Yeah. So, if you go to the site, you will see that with Webpack, and I have a Webpack loader called vue-loader. So, what this vue-loader enables you to do is to write a Vue component as a, in a single file that encapsulates the template, the styling, and the JavaScript logic all in the same file. And it's actually, it actually looks very similar to how you would write a Web Component. Like you have an HTML page that has the style, the template, and the JavaScript logic. It feels really similar to Web Components. However, the good part about going this non-standard way is that we actually get to leverage the full power of Webpack for each part of our component.

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.

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?

Mmhmm.

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?

It does bundle them together. So, I'm not sure what you mean by not being able to follow the dependency tree, because when you use a Vue component, you basically use the standard module interface. You can require another component. If you use ES 2015, you just import/export.

It's all like JavaScript modules.

But in the template itself...

Oh, I see.

I can use components but I don't declare that I'm using them anywhere, right?

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.

Cool, I see now.

Right. So, you...

So, that's like Angular 2 style, right?

Yeah, except Vue doesn't really force you to use dependency injection.

Oh, right, right. Cool, so what kind of benchmarking have you done to compare performance of Vue to other frameworks, or have you?

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...

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.

Of course, yeah.

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...

Yeah.

Of like...

From Ryan Florence's talk, right?

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.

Super interesting.

Yeah. Alright then, before we get to the picks I just want to acknowledge our silver sponsors.

errors cost you money. You lose customers or resources and time to them. Wouldn't it be nice if someone told you when and how they happen so you could fix them before they cost you big-time? You may have this on your backend application code, but what about your frontend JavaScript? It's time to check out TrackJS. It tracks errors and usage and helps you find bugs before your customers even report them. Go check them out at TrackJS.com/JSJabber.]

Dave, do you want to start us off with picks?

Oh. Let us see here. You caught me by surprise. I didn't know we did picks. [Laughter]

Surprise!

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.

Alright. Aimee, what are your picks?

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.

Like in his movie. [Laughter]

I used to just also sing the song 'I Believe I Can Fly'.

[sings] I believe I can fly.

[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.

Oh, I love that.

I love it.

So, it is absolutely awesome. It's entertaining and it's also educational.

You have to watch it on fast forward though, because it's so long.

[Laughs] Yeah, well I guess it would depend on which algorithm you're watching. [Laughs] But [inaudible]...

That's a good point. [Laughter]

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.

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. [Chuckles]

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?

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.

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?

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.

Alright. Well, we'll go ahead and wrap up the show and we'll catch you all next week.