The Changelog: Software Development, Open Source - Discussing Vue.js and Personal Projects (Interview)

Episode Date: November 28, 2015

Evan You joined the show to talk about Vue.js - his library for building web interfaces. We discussed what Vue.js offers, what makes it different, why developers should trust this project even if it's "just a personal project" that's not backed by an enterprise or a large team.

I'm Evan Yu, and you're listening to The ChangeLog. Welcome back, everyone. This is The ChangeLog, and I'm your host, Adams Dukovic. This is episode 184, and on today's show, Jared and I are joined by Evan Yu, talking about Vue.js. We had four awesome sponsors for this show, Codeship, OpBeat, Braintree, and also Digital Ocean. Our first sponsor is CodeShip. Got an awesome ebook out there totally for free. It's a 21-page deep dive into why containers and Docker are the future. This free ebook is about the rise of the container stack and why Docker and its ecosystem and community play such a big part in it. Now, when you download this e-book, you'll also get access to three other super secret

e-books. So go check this out, resources.codeship.com slash e-books. I'll put the full URL in our show notes, so check that out. And now, on to the show. Hey, everyone. We're back we got an awesome guest with us today evan you is joining us uh jared it's kind of interesting because this uh show kind of kicked off with the very first issue submitted to ping and that was that was evan right yeah that was a long time ago, though. That was like forever ago, basically. So he's our very first ping. What'd he say? He said, can you cover Vue in Chiefs Law Weekly? We did.

And we were happy to do so. Effective move. And recently he wrote us again and said, hey, let's talk about Vue on the podcast, which sometimes is kind of hard to approach people and ask if we can talk about your thing. But he made a compelling argument. He listed multiple reasons why it's interesting. And I said, that actually does sound pretty interesting. Let's do it.

Let's do it. And so, Evan, you created Vue.js. Yep. Before we dive deep into that, obviously, we're going to talk about that quite extensively. It's always interesting to kind of dive a little further into our guests. So tell us a bit about yourself. How do you introduce yourself? What do you do?

Evan Yu Right. So I'm Evan Yu. I currently work at Meteor as a core dev and VJS is my personal project. And before joining Meteor, I was at Google. I worked at Google Creative Lab for a bit over two years. And before that, I went to Parsons, Parsons School for Design. I went to a master's program called MFADT, which is Master of Fine Arts in Design Technology, which is a fun program. Wow. Okay.

So that kind of makes sense why you say design, code, and things in between. Yep. So can you unpack that for us a bit more? Sure. So I started out doing some design on my own. When I was in college, I studied something completely unrelated to what I'm doing right now. But I have always been interested in designing and just trying to build the things that I designed. And it was really fun.

And so a lot of my time was spent playing with Flash and trying to, you know, just crank out things that i think is creative and fun and then that led to sort of the situation where i don't know what i was going to do when i graduated um and then i was like okay i need to find some place where i can combine two of my interests you know design code and that that was um so i looked around and parsons had this type of program which looked pretty fun so i went there and ended up um ended up doing a lot of code experiments on the web and then somehow uh that got me got me the opportunity to work at google creative lab which was also pretty fun had a lot of crazy experimental stuff in there. Yeah, that's... And I started working on Vue when I was at Google Creative Lab and

that's gradually evolving to what it is today, but it started like more than two years ago. It was a really small experiment. Wow, okay. So this is a two-year thing that you've been, I guess that was two years ago when you started working at Google Labs? That's almost three years ago when I started. I started on Vue around two years ago. Okay. Yes. Did any of your crazy experiments at Google Labs

make it out into the wild? So I kind of want to clarify, like the place I worked at is called google creative labs it's like not the x right so google labs is yet another thing which is no longer in existence right uh google x is this high tech like branch and google creative lab is more like um uh half marketing half uh ui prototyping So we do a lot of internal prototypes. We did the UX prototyping for Google Glass. We did a bunch of stuff for the Google iOS search app.

We were also one of the responsible party behind the rebranding in 2015. That was a big deal too, that rebranding. I think it went over well. Everybody likes it. Yeah. It was pretty interesting because we actually have been pushing for it quite a while,

but it actually went out after I have already left Creative Lab. It was pretty fun to see something you touched upon just going live after so long you almost forget about it. Why don't you take us further back, like before Vue, before Google, you know, how did you kind of get into what you're doing? Give us the backstory. Sure. So as I mentioned, I did a lot of Flash when I was still in high school, I believe. I have always been fascinated by those really flashy websites.

Just fancy stuff. And I want to figure out how to make them. I believe my first webpage was built with front page. I basically copied the markup from just a random website I saw and tried to mold it into what I wanted to look like. That was a fun experience, but at that time, I have no idea what's underneath. I can't read the markup. I can't really read. I didn't even know what those script tags did. Right, right. And later on, I started playing with Flash, because it just felt a bit more visual than FrontPage, you know?

And at that time, it was still using, I believe, ActionScript 2 or something? Okay. It was a really primitive scripting language. All the things I could do with it was just like play, pause go to this frame, go to that frame doing small animations and then Adobe released ActionScript 3

which was more like a real programming language so I had to sort of step up the game and actually learn proper how to write code but it was nothing like a real like computer science background thing it's more like i want to build something so i had to learn how to do it process i mostly picked up all the programming stuff by myself gotta ask you

because i it's not often we have somebody who loves Flash or at least came from that. I guess we all kind of came from that era, but I can't say myself I've done a lot with it. But if I say too advanced, what does that mean to you? Oh, yeah, I remember that studio. They have all these crazy websites. Yeah, I think I had one of their versions, like version two or something. I remember they built multiple versions of their website. Every time it's like a completely different layout, different intro animations. Yeah.

Yeah, those were crazy times. The art was so amazing, right? That's what always fascinated me about what was Flash in that era. It was like there's a very particular font, you know, all these like pixel fonts and, you know, and this,

this artistic style to it. Like it had a cool thing going for it. I kind of miss a little bit of that. What about you? I do. Yeah. I think it's especially to advanced stock because they're the best. Like there's nobody better than that.

Yeah. They're, they're probably like one of a kind in doing this type of Flash-based animations. I believe I even have a copy of a source file of one of their sites. It's basically reverse-engineered or something so that I can look into it

and copy some of the tweens and some keyframes out of it to use it in my own projects yeah wow that's crazy man so roots go back to flash and even to advance that's really cool I I'm I'm impressed I I don't know many people who know of them and when you do you know they love them because they're really the best way to do it. Too advanced mean nothing to me, Adam. So I was starting to look at 2 Live Crew stuff once you said that. So I'm kind of off on a tangent over here. That means more to me than too advanced.

Although tooadvanced.com right now is just like a completely black page. So maybe it's because I don't have Flash and they're still rocking it all. I mean, it's like seriously just complete blackness in a modern. I don't doubt it. I must have Flash installed. I don't know why. I'm popping in Chrome because that's just Safari, which. Oh, yeah.

I'm in Chrome. So in Chrome it works fine. I'm not sure if they still. Wait, it's 2Advanced, right? Yeah, the number 2. Yeah, 2Advanced.com, like the number 2. Oh, yeah, these guys are old school. It's still loading like up to 90 with a counter on how much it's loaded that's a completely flash website

yeah it's still pre-oflash wow that's amazing i don't want to go too deep into that but i mean i never we've never had anybody on the show that knew of too advanced so i had to drop that question for you to see if you were familiar with them. I'm surprised I'm the first one. Copyright 2011. So I'm wondering if they've moved on. They probably have moved on. Well, I think the web has moved on. I think you're right.

Right? They're in the dust. So I guess we can move on as well to Vue, which is kind of the onus for the conversation here. Vue.js, now that's V-U-E for those listening, not V-I-E-W, which is probably what you'd assume

is a, I'm not going to call it yet another client-side framework. I was going to make jokes about it's been a few weeks since we've had a JS framework on the show, Adam, but it actually has been longer. It's been all the way back to 160 in June was ampersand. And then previous to that, if you count React, I guess, which isn't, we know that's actually a Vue layer, 149.

So, you know, once every three or four months, usually, we bring upavascript front-end tooling and it's about time so let's talk about view it seems like it's kind of the silent assassin that i hadn't personally heard of but is growing in popularity and seems to have quite a bit of merit um you said you started it when you're at google creative Labs. Why did you start it originally? Okay, so primary reason was I was looking for something that's specifically good for what I was doing. We did a lot of UI prototyping, and those projects usually involve a lot of interactive content,

interactive UI, but at the same time, we had to do it really fast because the design changed really often. We crank out ideas very, very fast. So the pace kind of demands a solution that just makes some of the common UI tasks easy, but also don't overwhelming, overwhelmingly complex, right? We were using Angular for some of the projects and we just felt I really like the data binding parts. It makes your UI more declarative, but at the same time, Angular

is complex. It introduces a lot of concepts that I simply didn't need at all. And I felt there ought to be something simpler, but provide the same benefits of a data-driven view. So, and also it was partly also because I was curious on how Angular implemented it. It was somewhat a research project where I want to, you know, just dig into under the hood and see what is going on, how did they do it, and sort of figure out what I can do. Maybe I can build something like that too. Yeah, so it's half experiment, half out of the need

to use something for the projects I was working on. And if you had to describe it in a landscape of the current set of frameworks, so just throw out Angular, Ember, React with Redux, and such things, Aurelia, Ampersand, which kind of is, you know, you can lay those out sort of in a continuum of, like, lightweight to heavyweight and, like, batteries included to more library-based,

where would Vue fit into that landscape? It's probably closest to React in that aspect. So it's more like Vue.js Core is the V in the MV star system. It's strictly just a Vue layer. It concerns itself with you grab some state, you declare a view, and you render something onto the page. That's the job it does. But at the same time, it started out as just a core library and it intends to stay that way. It's really just a drop-in type of thing. In that aspect, it's even a bit simpler to get started within React because with React, you sort of need to do some JSX transpilation to get off the ground. But with Vue, it's literally just grab it off the CDN and you can just get up and going. And then when you reach a... So Vue core packs a bunch of things. First is data binding, then there is the component system and it includes some transition

effect helper to make it easier to build dynamic stuff. But out of that, it doesn't really include routing. It doesn't include any sort of opinionated data layer. It doesn't concern itself with how you bundle or structure your app. It stays out of your way if you simply want to use it as a view layer. But similar to the React ecosystem, there's React Router, there's Redux. So Vue.js sort of provides you with an optional Vue router. It has a set of opinionated build setup. If you use Browserify and Webpack, then you can use some transforms to write your Vue components

in a very web component-like format, which in a single file sort of encapsulate the style, the template, and the script for your component. So it kind of grows out to a more opinionated framework-like experience if you are into that, but it's totally optional.

So what's the sweet spot? I mean, for you, when you're building something on view you're using all the components are you using view just for the view layer um how is it supposed to be used right so i think the beauty of it is it it doesn't really force you into one specific way of using it um the point being uh a lot of people recently in the Laravel community are picking up Vue, and for a lot of them, their primary experience is building fully backend rendered apps. Most of their stuff is rendered by the server side and just spit out to the front end,

but they want to have interactivity. They want to have sort of like a mini SPA on each page. And full-blown frameworks like Angular or Ember doesn't really fit into that need well. It feels like such an overkill when you just want to add simple reactivity to a server-side render page. So a lot of them just use Vue for that specific purpose, right? You just grab it from the CDN and you can just get going.

But maybe when you build the next app, you want to grow the client-side presence, or maybe it's just a different app that demands a different UX, which an SPA was suited better, then they can, you know, grab the additional parts and they can still use Vue, but they can build an app that's more single page oriented, more fully structured as a client-side app. So the same core principle applies in both situations, which I think is the power of this type of how the framework presents itself. You can pick what you need to achieve what you want. Very cool. And it seems like you just reached 1.0 here recently. In preparation for this, you sent us a link to an excellent post called Vue.js,

a reintroduction, which highlights some of what Vue offers and compares and contrasts it with the frameworks that we've been talking about. You have one, two, three, four, five major points there. I think what we'd like to do is take a quick break here from a sponsor. And then on the other side of the break, what we'll do is kind of talk through those bullet points, use them as kind of waypoints that we can use to dive into other conversations about Vue in detail. Sound good? Yeah. All right. Let's do that. We'll be right back. Guess what, everyone?

Opbeat is announcing their Node.js beta right here, right now, exclusively to our listeners. Opbeat combines performance metrics, release tracking, and error logging into a single, simple service. And with all of your data in the same place, they're able to do smart things with it and help you make wiser choices. Opbeat integrates with your code base through Git and makes monitoring and debugging your production apps much faster.

It's free for an unlimited number of users and until now has only been available for Django and Flask. But now they're launching a private beta for Node.js and sharing it with our listeners first. So go check it out and sign up for the beta. Head to opbeat.com slash changelog. That's O-P-B-E-A-T dot com slash changelog. All right, we are back speaking with Evan Yu

about his awesome JS framework, Vue.js. Evan, you got five points here in this blog post, which we will definitely link up in the show notes. Point one is reactivity, in which you say that keeping the state and the view in sync is hard, or is it? You begin to describe the reactivity in Vue.js. Can you take us through that?

Sure. So reactivity in Vue.S is one of the most unique things that I haven't seen a similar implementation in any other framework, I believe. So the core of it is VJS converts plain JavaScript objects using some ES5 features called Object Defined Property and makes all these properties reactive. So when you retrieve a property or when you mutate a property, Vue.js knows under the hood, and so it's able to track the dependencies and be able to reactively perform DOM manipulations for you. So let's say when you have an object with the property A and you use VJS's templating system to bind, say, a mustache tag to the property.

And so once you do that, the view and your data is essentially linked. And whenever you change the data, the view just updates and it just becomes fully automatic. So instead of mutating some data and calling a re-render, you just change the data.

So there's no need to call re-render anytime. And in comparison, there's no need to call rerender any time. And in comparison, there's some other frameworks that uses a similar model-based mechanism where you have reactive model objects and you bind to your view and you can mutate them. But the thing is none of them actually use this plain JavaScript object syntax. So it's, for example, in Knockout, you have to create ko.observables. And in Ember, you have to create Ember objects. But in Vue, it's just plain JavaScript objects.

Like you can do an AJAX call, you get some JSON, you parse it into plain objects, and you shove it into a Vue instance and the Vue updates. So like you said, a lot of these frameworks require you to use like

ember.createObject or something and to use their specific objects which have observability built into them. Right. And you have to use getters and setters in certain ways in some cases. I assumed you were using object.observe or some sort of new feature, but you're using define property,

which is available in like every major browser, right? Yeah, it's available down to IE9. So Vue doesn't support IE8 and below, but anything above IE9 is fully supported. I don't think that's problematic i saw just uh today that microsoft as of like january is deprecating all the way back to ie10 so 8 9 and 10 will be officially unsupported which is nice um good stuff it is keep moving it forward um so hmm are there any drawbacks to this method?

It seems like if it was, you know, just used define property, it seems like the Ember team would have been using this feature. It seems like, you know, in Knockout, they would have been just using define property because plain old objects is easier. It is more straightforward. How do you accomplish this? Right.

I believe one of the reasons other frameworks don't pick it is either it has to support IE8 because object-defined property is a feature that is unshimable in IE8. There's no way to shim it

if the engine doesn't support it. So if you are to support IE8, then this mechanism is just out of the question. But if you are willing to drop support for IE8, then this is totally feasible. So there is some... So it's a technical, very technical comparison

with, say, an Angular's a, um, anglers mechanism, which is dirty checking or a reacts mechanism, which is virtual DOM different. Um, I would categorize the two into the, the pool based mechanisms and the push based mechanism. So all of the, um,

like knockout or Ember or view are sort of in the, in the push camp, because when the, like, Knockout or Ember or Vue are sort of in the push camp because when the change happens, the reactive model will push the changes to the Vue to automatically trigger updates in the Vue. And in comparison, Angular and React both are pool-based systems. Essentially, you need to give the system a signal saying, hey, something might have changed. And now you need to...

So in Angular, you need to iterate over all the watchers to do the dirty checking. And in React, you render a new virtual DOM tree and diff it with the old one. But these things don't happen automatically. You sort of have to give the system a signal. And in Angular, it's somewhat baked into event handlers. So Angular does it for you.

But when you are, say, in Angular 1, when you are in a timeout, you have to manually call scope digest or scope apply in order to tell Angular something has changed. And in React react you have to call set state uh if you directly mutate your state there's no way for react and angular to know it has changed the the comparison is that um push based mechanism have better runtime performance but it has a slightly higher uh initialization cost because you have to set up all the observation objects,

the watchers, the dependency tracking. You have to do all of that at boot up. The system has to warm up and be ready for any future changes. But once that's set up, all the hot updates are really fast and efficient because if you change one single property, then only the views that's interested in that property would get notified and and get updated but in a pool-based system because it's somewhat brute force obviously there's a lot of optimization in there but the essence of it is we don't really know what has changed we just know something has changed so we have to you know either go through all the watchers

or go through the whole virtual DOM tree to figure out what exactly has changed. So you do a lot of extra work when something has changed in order to update the view. So let's say you have a huge app and you are changing only a small piece of state. The push-based implementations will probably take a bit longer to start up, but subsequent changes would be more efficient.

But a pull-based system could start up relatively faster, but its hot updates would have performance implications. And it depends on how the implementation works and how optimizable it is. So dirty checking is hard to optimize, but virtual DOM is somewhat more optimizable because how in React you can implement a per-component method called shootComponentUpdate to sort of short-circuit some of the virtual DOM diffing, but it's still a manual process.

So would you say that Vue is neither push nor pull then? It is in the push camp. Okay. Yeah, I might have, no, I just realized I might have gone into too much technical details. No, that's good. Okay. Go deep, that's good. Okay. Go deep, please. Sure.

So what about, so you're working with plain JavaScript objects. Obviously you have properties and properties can be functions. Can you then observe functions? So if you want to, yes, you can. You can put functions in your state but the the general advice is uh prefer to because all the reactive parts in your app uh essentially especially in a vjs app that represents the state of your application right um and it's good if your state is playing objects that's serializable and persistable. Because functions are not really serializable.

You wouldn't put functions in your, say, a JSON request. When you get some data from your server, the response wouldn't contain functions. Sure. So most of the case, you kind of want to think of these reactive objects as things you would want to persist to the server or things that basically describe what your app state is like instead of putting arbitrary objects in it. So Vue is a little bit opinionated in that aspect because we want to use these reactive objects as the underlying source of truth to drive the view. So you want to keep it abstract, keep it clean and simple.

So this offers two-way data binding in the sense of if you update it in the model, it updates the view. And if you update it in the view, it updates the model, correct? Yeah. So Vue implements two-way data binding but in my opinion two-way data binding is kind of a word that's misunderstood by a lot because two-way data binding in its essence is just syntax sugar what what really happens under the hood is the user has triggered some input. So the event triggers view to modify the state, which is the object. And because that object is modified, it triggers the view to re-render. So in fact, what's happening is still sort of like event triggering model update, model update triggering

view to re-render it's actually not that two-way if you think about it it's just syntax trigger to make it easier to write sure aren't there times when your when your event triggers wouldn't necessarily want to re-render though right so in that case you just simply use event listeners instead of two-way bindings so view gives you the options in that case yes so two-way data binding you know i realize that you don't love the term um but people are used to that term so with that particular aspect of view you know ember famously had two-way data binding, this back and forth push and pull, as a kind of a flagship feature early on. And then they realized it's not actually always useful. And so let's allow people to turn it off and on. It's cool that Vue allows that kind

of flexibility. But when it's on and you're using it, when you have that feature on, are there performance implications that you found with Vue? Okay, so I think I want to take a step back and explain two-way data binding a bit more. So when we talk about two-way data binding, there are two types of things people would refer to, but they often confuse one with another the first is strictly the form when you're handling form elements form inputs uh this type of two-way data binding is uh what like say when you are typing into a field and the model updates and something something else that's also bound to that property also updates. So this form-based two-way data binding, in my opinion, is just syntax sugar. There's another type of two-way data binding people talk about is binding a property on this component

to another property on another component and keep the two in sync. And this is the problematic one that a lot of people don't like. That's why React sort of talks about how the data flow should be one way. It should flow from a parent to a child. And that's actually what Vue is doing too. The default, the way you pass data from a parent component to a child component in Vue is also using something called props, and it's also one-way by default. And I think that's correct, because a lot of these two-way binding between components becomes hard to understand and reason about, in that these two properties are not the same thing

they don't have the same identity yet we try to pretend they have and that's the source of the confusion here i believe so i think the better way to do it is if the two properties should in fact be the same property then they should uh in reality be the real same property on the same object. And that object should be the source of truth. And you have two components that observe the same object instead of two components each holding a copy of that property and try to keep them in sync. Does that make sense? It does. It does very well. I think it tees up very well our next bullet point

on your list of things inside Vue, which is components. Maybe a little bit different than the component you just mentioned, or perhaps the same. Can you describe, I believe this would be akin to Angular's directives, or Ember, I guess they renamed theirs, I think they were views at one point, now they're components. All these terms. Can you describe components in Vue.js?

Sure. So I believe most of the major frameworks right now have converged on components, right? Angular 2 is built around components. Ember is all about components.. React has started with components. Right. So, I think they more or less have... We have... The whole ecosystem have sort of agreed that the component is a really good abstraction for building user interfaces. And most of the UI can be represented as a tree of nested components.

And each component would have its own state, have its own view, and should have some sort of logic encapsulated inside of it. And ideally, you want to build components that are self-contained and reusable. So when you build it and you want to use it elsewhere, it should be easy and straightforward to do so. So I think that's what a general definition of components and each framework sort of tackles it in slightly different fashion. And in Vue, it's still pretty simple because when a lot of people first start with Vue, the only thing they know is they can create a Vue instance. A Vue instance is essentially an object that binds a raw data object to a piece of DOM.

So these types of instances, if you think about it, that's a component. If an instance can contain other instances, then we have the component tree we want. So that's exactly what Vue is doing. You define a bunch of options. You define a component by providing a bunch of options. For example, you can provide a template. You can provide a function that returns the initial state of that component, which is very similar to what React does. And you can provide other options such as some methods that component might have. And you can provide computed properties. these, essentially it's like a class, but not exactly a class, but something like that. So when you create a component in Vue, you call Vue.extend, then you're passing all the

options and you get a reusable constructor function. You can use that to create components, but it's imperative. So the recommended way is to register the component with a tag, an HTML tag, a custom element. So that becomes very similar to how web components work, how you define reusable web components, you register them as custom elements, and then you can nest them, compose them any way you want. So the Vue component development experience is very similar to that. But on top of that, Vue provides you the mechanism necessary to communicate between the components.

For example, you can use the prop system to pass data from the parent to the child. And then components are event emitters so they can dispatch events so a parent component can listen to the events on the child so that the child can somewhat notify the parents that it needs to do something so this this sort of event like triggering parent actions using events decouples uh the the child and parent because the child is only responsible for dispatching the event. And what exactly happens afterwards is up to the parent, and only the parent knows how to mutate its own state in reaction to that event. And then Vue also implements something that's very closely modeled after the Web Components spec. There is a mechanism called slots, which is previously content. So they recently, the spec drafters switched the content API to the slot API and Vue implemented that right before 1.0.

So what the slot API does is allow you to compose these custom elements. So when you use a custom element and you put other custom elements inside of it, so that custom element, because it has its own template, what should we render? We need to somehow find a way to weave these runtime elements inside of it with its own template. That's what slot does. It allows you to better compose these components at runtime. It might be a bit hard to explain with words because the slot concept is somewhat hard to explain, I guess. But what it does is make components more composable. That's all it does. So we solve several issues. First is how do we pass data from parent to the child?

And the second issue is how do children notify their parents something has changed without being directly coupled to the parent? And the third question is how do we compose different components at runtime?

So if we can solve these three questions, then we get a pretty good system where it allows us to build up more complex interfaces with these small building blocks. And this is very similar to what, I believe, what the web components people want us to be able to do eventually.

And it's in fact, I believe, very similar to what Polymer is doing. The difference being that Vue is not specifically tied to the spec. It doesn't really rely on the polyfills. So you don't need to worry about, say, does this browser support this feature? Do I need to ship the polyfill or not? And you don't need to worry about it having inferior performance on an older browser simply because it doesn't support certain features.

Well, once you have all those components set up and they're decoupled but nested and they're all ready to be used, what developers like to do is share them with themselves and with their friends. So it looks like you got some of that built in as well with modularity. That'll be our next topic. We do take another sponsor break at this point. Sure.

On the other side, we'll talk about modularity, animations, and stability. Be right back. developers out there the Braintree B.0 SDK makes it easy to offer multiple payment types start accepting PayPal, Apple Pay, Bitcoin, Venmo, traditional credit cards and whatever's next all with a single integration enjoy simple secure payments that you can integrate in minutes and developers they've got you don't worry about taking days to integrate your payments with Braintree it's done in minutes. And if you don't have time, give them a call and they'll handle the integration for you and walk you through it. Braintree supports Android, iOS, and JavaScript clients.

They have SDKs in seven languages,.NET, Node.js, Java, Perl, PHP, Python, and Ruby. And their documentation is comprehensive and it's easy to follow. To learn more and for your first $50,000 in transactions fee-free, go to braintreepayments.com slash changelog. All right, we are back. Let's talk about modularity. Once you have your components, Evan, how do you bundle them up and distribute them? Right.

So currently, I think the mainstream way of organizing and building your web projects is using modules, right? Everyone uses modules today. So it's either CommonJS, AMD, or ES2015 modules. There are a lot of ways to do it, but the preferred way with VJS is you use either Webpack or Browserify. So that indicates we want to write our components as CommonJS modules. But thanks to the transforms in these ecosystems, so you can use either Babel, Babel Loader or Bablify, but both uses Babel to transpile your ES6 or ES2015 code into plain JavaScript. So you can use ES6 modules too.

And Vue also, when you use Vue with Webpack or Browserify, there are two Vue-specific tools. With Webpack, it's called ViewLoader. With Browserify, it's called Vueify. So these two do the same thing. They allow you to write your Vue components in a Vue-specific format. It's called a single file component. As I would call it, it's very similar to Web Components 2. Essentially, in the same file,

you have a style block, you have a template block, and you have a script block. So you have the three parts that's necessary that makes up your component. Because I think back when we built applications with Angular or some other Clonset frameworks, it's very common for us to group, to structure our files based on the extension. You put all the HTML templates in the same folder. Then you put all the style files in the same folder. Then you put all the JavaScript in the same folder.

But in the end, I came to the conclusion. Yeah, I came to the conclusion you shouldn't do that, right? They should be grouped based on what they are about, right? You have a template, you have a script um, you have a template, you have a script file, you have a JavaScript that, but they are all related to the same, uh, feature or functionality in your app. For example, um, this, this button that you're building, right? The button has its template has its logic has its styles.

Why should they be separate? They should just be in the same file. So you have this single file that represents your button component and you can just put it around. I think that's powerful and I think it makes it easier for you to think in terms of components

and develop components. And Web Components is a step in that direction and obviously a source of inspiration and i think react sort of does that too but in the way of shoving everything into javascript you write jsx and styles in javascript so that it's a single file but the the idea is the same right so every component is in its own file and you. It makes these things much easier to think about and to organize. People may ask, why do you invent another component format? Why don't you just use Web Components?

The answer is because Vue components are transpiled using Webpack, you get to leverage the full power of Webpack. So you can use preprocessors inside your Vue components. So if you want to use Sass, Less, or Stylus for your style inside of your component, yes, you can do that. Or if you want to write JTemplates for your Vue components, yes, you can do that. Or if you want to use CoffeeScript for all your scripts, yes, by all means. So that's the beauty of it, right? You have the same format for your components, but you also have the freedom to use all the preprocessors that you like inside of it. And in the end, because what ViewLoader does is essentially it extracts out each part of your

component, pipe them through the appropriate loaders that should be used. For example, if you write Sass in your component, it will pipe it through the Sass loader to process it. And eventually it assembles all the parts back together into a CommonJS module. Then these modules eventually get bundled together to become your app and i think that makes it just um so so when you use view components you don't have to throw away all the tooling that you're familiar with uh you can you can leverage uh all the community contributions in the sass community or in in theass community, or you can use the favorite language that

you like. So you're still doing it the bad old ways, as Jared said, and when you run ViewLoader, it's dumping it into a single file. It's kind of processing, as you said, through the Sass file, through different compilers. Are you still writing it the old way? No. This all happens in memory. It's like Webpack is responsible for doing that.

It's all hidden to you. You don't need to worry about that at all. All you need to do is just author your components and Webpack is responsible for assembling it together into a final bundle. Gotcha. And these comments in the file, is that what allows the delimiter essentially to happen

to make that possible? Those comments are totally optional. The way you indicate your preprocessor, if you scroll down, you will see you provide the len attribute on your template or style blocks to indicate the language you're using. Gotcha. Okay. Yeah. Yes. okay yeah uh yes and in addition to that view doesn't really use shadow dom because it's not a stable feature yet but view provide a mechanism to simulate scoped styles so if you add a scoped attribute to your style block if you will do some extra work on your styles and your templates it rewrites them so that your style is

encapsulated to the current component only it doesn't affect other components you also mentioned syntax highlighting can you break down how i guess that's possible i'm not seeing how i guess you have one single file with many different languages in it and it's still you know right uh that's that's really just providing a special Vue syntax highlighting file. I have a Vue.tm language, which is the syntax highlighting file that's format that's used by Sublime Text. But there are people who have converted to use with Atom to other editors. So you're supporting the one for Sublime Text that essentially a.vue file,

you can mix CSS, Sass, whatever you want to choose, JavaScript and HTML, Jade, whatever you choose for front-end languages. You can do that with Vue and you maintain that yourself. Exactly. Okay. Well, it actually allows... So when you use a syntax highlighting file, you can actually just declare, say, this block,

we should include the syntax for another language. I was just going to ask you that. That's pretty awesome. Because otherwise, you're maintaining like six languages across a single syntax. That's how you do it in HTML, right? Like you can embed JavaScript and CSS in HTML. Same thing. So in fact, the

Vue syntax highlighting file is a modified version of the HTML syntax highlighting file. All it does is detecting the special language attributes in order to pull in different syntax rules for that block. That's interesting. You get to keep the tried and true syntax out there. You're not creating something new. Yeah, exactly.

And you're leaving an attribute to sort of toggle back and forth between languages. Yeah. Jared, your favorite word is something new. Yeah, exactly. And you're living in attributes to sort of toggle back and forth between languages. Yeah. Jared, your favorite word is up next, hot reloadable. What do you think? Yeah. No comment on that. But go ahead and tell us about hot reloadable there, Evan.

Sure. Yeah, so when you use Webpack to build your view components, you will notice that if you build up your Webpack dev server in hot mode, which enables the hot module replacement API, and then when you edit your view component, say you change the template or you change the style, the page doesn't reload, it just swaps whatever has changed onto the page So it even keeps the current state of your application It's so obviously this has to like goes back to React hot reloading that's popularized by then then Abramov

so he his devil at red conf Europe showing all the time travel, hot reloading. I think he's the original author of the React Hotloader, and then he went on doing all those hot reloading-related work, which is super inspiring. And that's what kind of triggered me to investigate, is it possible to make Vue components hot reloadable? And it turns out they are.

It's not as perfect as the React hot reload, because when you reload a component, it will actually reset the state on its child components, but it doesn't affect the state outside of it. But it's still good enough, because a lot of time it's frustrating for you to have to edit a single CSS attribute and have to wait for the app to completely reload. And especially if it's affecting a component that's only visible after a few interactions, it's super frustrating. How do you deal with things like the compilers being slow? I'm thinking like Sass. Recently a lot of hotness around that is lib SAS and it being

faster to compile. So if you've got a big, you know, CSS stack, for example, then you might be delayed on the actual compiling of SAS. How do you deal with that? The good part is Webpack basically handles it for you. Webpack uses a lot of advanced optimizations, incremental rebuilding, and it caches each module it compiles. So say when you are editing a single view component, only that component will get recompiled. Like all the other components are unaffected. And usually when we talk about SAS being slow to compile is because we are recompiling all the styles for your entire app on every watch that is obviously going to be slow but if you're only compiling a small sass file it's it's always going to be fast enough and if

you're writing that much sass inside a single component you probably should reconsider wise words wise words shameless plug we're having dan on in a couple weeks it's true dan abramov yeah so stay tuned for that for that flux i don't know jerry should we skip animations and writing we're kind of getting short on time and jump rate stability maybe you can give a a one minute version of of what you're talking about in routing and animations. Evan, what do you think? Uh,

I can probably skip animation and just talk about routing. Okay. What's, what's the most important thing happening here? Right. So, um, so view router is optional.

Like VJS core doesn't, doesn't concern itself with routing, but if you want routing to, to build a more single page application, like think then you should use the router and the router essentially does all what you expect a client-side router to do you can either use hash mode or html5 history mode it has it's a little bit opinionating that it maps the routes to components that's basically what react Router and the new Angular Router is doing.

And because these components, when you switch between components, you can leverage Vue's own transition system to easily apply transition effects. You have fine-grade transition control for route switches. You can control whether this switch is allowed or should be rejected. And yeah, it's pretty straightforward. If you want to build a single-page application, then you should definitely use the Vue router. So I think we should, before we dive deep into stability,

we'll take a quick break. We'll also do our closing questions, but we'll come back and talk about stability. So we'll be right back. I have yet to meet a single person who doesn't love DigitalOcean. If you've tried DigitalOcean, you know how awesome it is. And here at the Changelog, everything we have runs on blazing fast SSD cloud servers from DigitalOcean. And I want you to use the code

changelog when you sign up today to get a free month, run a server with one gig of RAM and 30 gigs of SSD drive space totally for free on DigitalOcean. Use the code changelog. Again, that code is changelog. Use that when you sign up for a new account, head to digitalocean.com to sign up and tell them the changelog. Use that when you sign up for a new account. Head to digitalocean.com to sign up and tell them the changelog sent you. Alright, so we're here with Evan Yu. We're talking about Vue.js and this is the tailing of this article that's kind of diving into the reintroduction of Vue.js and stability seems to be the ending hook here. And, and a quote you put in here,

Evan was a personal project with a question mark, seriously, question mark. So like, I, I, I guess maybe people don't think it's a stable. What was, what's the situation here? Well, um, I've, uh, I've, I've seen some discussions where, uh, in, for example, you, in a comment thread where people say, hey, I think VJS is nice. And then there will be that guy who jumps out and say, oh, it's just a personal project, dying a year. That guy. Right? Yep. guy. Right? And, you know, some people just like knowing a project is backed by a huge enterprise of

a full team of people working behind it. That gives them a sense of, I don't know, maybe just makes them feel safe. I don't know. I agree. It's important to think about how stable the the software you that you use to build your product upon but um sometimes you know whether it's a personal project or not may not be the deciding factor because we know there are a lot of great personal projects that stands out like backbone or coffee script are both personal projects by jeremy ashkenaz and And he has more than one of these cyber projects. It's amazing.

And so many people use it. I don't get the situation with that because I think, Jared, help me out here if you agree, but I think it's over the last few years that's become a thing where people feel more comfortable with frameworks that are backed by, as you said, some sort of enterprise. But, you know, open source began as all personal hobbies to a degree.

And a lot of the open source that we use daily, you know, Linux, for example, was a personal project. And look how many people use that. And I mean, that's the impetus of what open source is. I don't get that statement. Right. It's business risk. I mean, more and more businesses are coming to open source and seeing the light with regards to licensing costs and maintainability and these things. And, you know, they're all about risk assessment, right?

Like, what's our risk here? And they find that open source actually reduces risk because you do have access to the source code for instance but they're coming from a place where they're used to proprietary software right um they you know they have money to spend on things like support and just you know wanting a company to be there um so i get both i get it from both sides you know as even as an individual software developer um who's just been in the startup scene for long enough, I don't love fly-by-night things. You think of services you're going to start relying upon. What if Slack just disappeared now that we're all loving it?

That kind of would suck. That would be a disruption to us. And so it's risk aversement, I don't know the word. Adversement. Yeah, it's just being averse to risk and thinking that a single developer project is riskier than something that's backed by a corporation, which it is.

But I think, as you said in your post here, Evan, you're proving by your track record. Um, and the fact is that you've been maintaining this for multiple years and you've reached a stable 1.0 and you have a hundred percent test coverage and you go through reasons why you are, uh,

somebody that's providing stability in their project. Yeah. And I think that's admirable. I think that would win over a lot of people that have that problem yeah is that why you've put this here at the close of your article yeah mostly this is sort of out of my because I've been I mean seeing people talk about view quite a lot of times and this question comes up actually quite often like when people ask is this still going to be

around in a year or so maybe it's because of the bat name the javascript ecosystem has gotten because of so many new frameworks coming out and then just disappear uh in a few years um if you take a look at to do mbc like they're like the survival rate is not that great I would say some some frameworks are just no longer maintained or things like that so people in general I kind of understand why when they are assessing a new JavaScript framework and especially if it's a personal one they would think oh like it has a high chance that this just not going to be around in a year or so. Right. But again, I think it's a common first impression.

Sure. But when you really want to seriously evaluate a project, it's better to look at the real numbers, right? Because everything is public. The issues, the the um everything that this this project has gone through is on github you can just go there you can see how how many issues are there how many bugs are open uh how fast are they uh are they closed or fixed uh there are statistics for that um and you can look at the commit commit to see how often how active this project is

you can look at the tests, see if it's robust see the source code and see if the author cares about the quality of their projects these are real useful information for you to decide whether this project is reliable

and rather than resort to this is backed by an enterprise, people sort of bet on that, bet on Angular 1 because of that. But you see what happened. Right. That's a good point there. You made me think of something, Evan. Is there any sort of tool that you know of that you can point at a repo and say, a bug issue is opened and closed this quickly with a resolution? Yes, there is a site called issuestats.com, I believe.

It's a site where you're just typing the repo name. It'll analyze how fast issues and pull requests are merged or closed for that specific repo and i even have a badge on the on the vjs readme um so if you go to yeah it's called issue stats.com this is interesting there it is did you know about this jared is this new to you this is this is news to me very Very cool. Brand new right here. Wow. Thanks, Evan.

No problem. Yeah, I actually learned about this a while ago, I think because Babel. Babel also used this. And Sebastian, Babel's author, is very meticulous in closing issues. And I admire him for that. Wow. So, I mean, you mentioned Angular, obviously, Google. And look where him for that. Wow. So, I mean, you'd mentioned Angular, obviously, Google, and look where that turned out.

Not that it's in a super bad way, but, you know, it's had some hurdles, long story short. With Vue, obviously, you can point issues or issue stats at this and get some good results back at test coverage, issues closing time, or issue stats at this and get some good results back at test coverage issues, closure time, issue closing time. And then also the fact there's no open issues that have reproducible bugs. And that's something to sort of tout, I guess, if you're, if you're into that.

I think it's also worth mentioning. And I think probably, you know, I think we all know this and I think many of our listeners know this, but when it comes to like, you know, is this a personal project? Will this be around, you know, years from now? Is that you're adopting somebody else's software when you're using open source, right? And that doesn't completely free you of the responsibility of like ever writing any code or maintaining things yourselves. You know, that's the beauty. I'm not sure what your licensing is. I'm probably pretty liberally open source.

Evan, what's your license? It's MIT. It's MIT. So as liberal as you can get, right? Do whatever you want with it. You know, here's the copyright and I can't remember what else. It's about all MIT says. You can't sue us for anything.

You have all the source code of a stable thing and you're a software developer or you're a company that writes software you know you can also help out that's a great point

if Evan is like I'm done with Vue I'm sick of it I'm going to start this other new thing as software developers do tend to you know want to chase the new shiny like somebody else can just step in and take it over and run it from there or if he's doing it in a way you don't like to you know that's what the fork button's for so i think it is risk averse but it's also perhaps a little bit of laziness or something. Just going to put it out there.

Somebody, I wish I had researched this before I opened my mouth, but hopefully I can type fast or click fast one of the two. Somebody just tweeted recently either to us or something like that. They recently listened to this show and they were like, after listening to this, I can't believe that something about how we build stuff, build businesses on top of open source. I'm going to find the tweet and put it in the show notes. And that's a good paraphrase. Actually, right here it is.

It's Nicholas Young listening to the changelogs, the latest episode on Metabase and realizing I couldn't build businesses without open source. And I think, Jared, to your point of laziness is that, or laziness is that, you know, businesses are actually out there, obviously, to create revenue and do good things for the world. But at the same time, you have a responsibility to give back and not just freeload,

you know, and he's right. Today, you probably couldn't build a single business without leveraging some piece of open source. And that doesn't mean just, you know, stand on Evan's shoulders and, and you know, enjoy it. You know, sometimes you gotta get down and carry them a little bit. Right. Good points. Good points. Good points. That being said, you do have stability. That's, that's, you've proven that. And just for the record, are you, are you going to give up on Vue here after the call for the record are you are you gonna give up on view here

uh after the call's over or are you gonna keep working on it i guess the latter all right that sounds good so we touch quickly i know we're we're like getting close on our time here we got like nine minutes left but uh it would be remiss if we didn't at least touch on the interesting things happening with Vue in the Laravel community. Yeah, so just a couple of points that you made that we'd like to highlight is that Laravel has been picking up Vue at a very fast pace. It's got, I think, over 9,000 stars on GitHub, so you're definitely getting some traction there. And you were recently on Hacker News, and you got actually nice things said about view on hacker news um so what's your secret um but for instance wow the docs look great for being 99 a one-man job this is incredible i'm very impressed if i was an employer i would hire you there you go so got some good things going

for you uh so what's the question like for you. So, what's the question? Like, what's the secret? Yeah, what's the secret to getting good comments on Hacker News? That's a side, no less. That's probably a much harder question than I expected. I don't know. I guess it's very specifically tied to Vue because it's been my baby, so I care about it. And I kind of want to just make it as good,

as presentable as possible. The point being, I have a project that people use and people like. So that's really great, right? Like I get a lot of thanks from people say, hey, like, thank you for making this great project. So that really makes me happy. And that kind of keeps me motivated and, you know,

keep working on you, making it better, writing better docs so people can, you know, keep working on view, uh, making it better, uh, writing better docs so people can, you know, have an easier time working with it. I think all of these sort of, um, sort of ends up showing like it's, it's a project built with, um, with care for its users, I guess. So, um, if you, I guess a lot of times some people build really cool projects, but, um, but they sort of just, you know, treat it as a, um, as a one-time thing. They think, okay, this is a cool project. I'll share it. But they, they don't really plan on, you know, uh, doing long-term investment into it. Or they just simply don't think they want to go that far

to make it something that would attract more people. Or maybe they just don't care, but I do care. So I'm willing to you know write the docs make the docs look beautiful or provide examples help people out just to make sure people can pick it up and get productive i think enabling a lot of people who've hated front end work before to to find it enjoyable i think that's's just great. Let's take a very specific example of your documentation. You know, we all love to code, but we don't all love to write docs. It's boring. It's hard work. It's difficult to do well.

It's easy to get wrong. It's hard to write as if you don't have the intimate knowledge that you have. You know what I'm saying? The first thing this person says, anonymous Hacker News user, is, wow, the documentation looks great. So like you said, you put a lot of thought into it. You put a lot of care into your documentation. Can you give some hard examples

of things that you did with your documentation that you think have really paid off, like it was worth your effort, so that other people could perhaps put that kind of care into their projects? So before that, before 1.0, the old docs is kind of accumulated over all the process from like back in the days of the initial release all the way up to 0.12. So before the 1.0 release, I did a complete rewrite of the docs,

basically rewriting the whole guide, just trying to take a step back and think about what would a... assuming someone who's never worked with Vue before, someone maybe even just, you know, hardly familiar with JavaScript, and they're just picking up the framework, what would they have to go through to be able to build something with it? I think that's the most important thing. I think a lot of technical documentation, not essentially failing, but they don't really recognize the fact that

a lot of users start reading the documentation without all the context and information you have as the author of the library. So you have to, kind of like when you're designing a product, you have to put yourself in the position of the user in order to write a doc that makes sense for them. So I also really value when people make make when people make suggestions, hey, like this part is confusing, maybe you should add an example here or there. I really like that type of feedback, because it helps me to, you know, the next new user who read the doc will, would don't have to deal with that confusion. So I always take those suggestions really seriously and just put them into the doc um other than that so care basically yeah put yourself in the yeah put

yourself in the position of uh someone who's never used your library before and don't assume that they know this or that like all these advanced concepts like try to explain things and make sure like i guess it's easier to overlook sometimes when you assume they are they're already familiar with one thing so you just jump right ahead into something that builds upon that concept then your doc quickly becomes harder to follow. Yeah. I think one thing you've done that's really awesome is your examples. So just for that initial, like before I even get to the API documentation, I'm usually looking at examples. Like what can I do and how hard is it to accomplish a few things? And you have a nice page where there's about 10 or so examples on the left-hand side and they're uh varying difficulties and complexity it starts off with like you know a little tree view here you have a markdown editor

which is surprisingly brief uh to implement and then you all the way down to like you should do mbc example um and a hacker news clone and then on the right hand side you have basically an embedded js fiddle which is showing you here's the h the HTML you got to use, here's the JavaScript, here's the CSS. And it's just a nice way to provide an obvious and outright example of like, what do I got to do to accomplish this thing? And that helps me decide like, okay, do I do I or do I not want to spend the time to dig into the API documentation? I think that was really impressive to me and I think probably is something that is worth emulating. Yeah, when I first released VJS,

that was in February 2014, I had a blog post talking about the first week of launching it. And from the Google Analytics, I think over half of the traffic landing on the site directly went to the examples after landing on the homepage. So, yeah, I think that sort of echoes what you just said. How common is it, Jared, that you know of? I mean, I never really paid much. I mean, I guess I pay attention to it. But how often is an examples navigation item at the top level is it always there for most projects like this

were you surprised it was there i mean um no not that there was an example section but i was surprised at when you get there it's a single page that's very easily you know exactly what you're looking at usually examples are kind of like long, right? I don't know, just it's just put together in a way that's like, outright and obvious, which I think stands out. And, you know, it's nice when you're working with JavaScript, for instance, where, you know, it's all web technology. So yes, you can just embed everything that you need to write here into the same page, and then show how it renders, which is awesome. So, you know, he's making good use of js fiddle some projects don't have that um advantage but people have started to get more creative i know animated

gifs are becoming more useful as people showing like here's how my command line tool works right um and those are great for a little you know getting people to see the payoff of why would i invest time into using this thing right away. I think a good example is it's hard to explain hot reloading without a gift. There you go. Some would say that's true. Some would say.

Alright, Evan, it's time to close out the show. I know we've been certainly enjoying this conversation with you. But we can't close the show without asking you who your your programming hero is okay so um yeah there are there are many of them like at different stages of like when you program i think you would have different heroes along the way right um to advance might be an old school one yeah definitely to advance was definitely one of them um and then when i was

at parsons uh zach lieberman was someone i looked to looked looked up to a lot uh in case people don't know zach is uh the author of open frameworks uh it's a c plus c plus plus based creative coding framework. Tons of crazy artwork produced with purely code made with that framework. So if you're into creative arts combined with computer science, something you should check out. And then when I first stepped into JavaScript and all that, the people at DataArts team

Google DataArts team, Aaron Kobling is probably another big hero of mine, he was the team lead of the DataArts team, they did a lot of Chrome experiments, when

Flash was dying it was them showing people hey html5 can be capable of fancy stuff too so um that was pretty pretty important and uh and then when i was just getting started with no js uh tj holloway chuckchuck is really, like, I was just amazed how could a single person be so productive, like, making so many impactful projects in the ecosystem. I see you're a fan of stylists, too, with your Hacker News example. Yep. Yep. Next question is what is on your open source radar so it doesn't necessarily

have to be view related although it could be but if you had a free weekend and you were just gonna pick up some open source and check it out or hack on it what's on your radar um i would probably play with so something i want to but haven't had time to play with um elixir uh and the phoenix framework and uh the the closure script stuff um next would be one of them um yeah i think uh i think currently my interest would I would really be interested to just play outside of the JavaScript ecosystem and just you know because often times we

take good ideas from other languages and ecosystems we learn from each other so I think that's pretty important you said um next right yeah not I'm, um. We'll get that in the show notes for those of you listening. Anything else, Jerry, you want to mention before we close the show?

Nada. Nope. All right. Aaron, how about you? Or Evan, not Aaron. Evan, my bad. Anything on your side you want to close out with? Anything else you want to mention about Vue, your interests, open source?

If you had the ear of the community about open source, what would you share back with them? I don't know. Any advice? Advice? I think, I don't know. I'm probably not senior enough to give advice. Yeah, don't take my words.

Use your codes. Yeah, use my code. There you go. One more thing we'll link out to in the show notes. There is a repo called AwesomeView following the awesome-star meme of repos where all sorts of things related to Vue, including a nice list of people using it, AJAX libraries, those kind of things. So if you're related to Vue, including a nice list of people using it,

Ajax libraries, those kind of things. So if you're interested in Vue, obviously check out the website, check out the awesome docs he's put together, but check out this awesome-vue as well, and you'll have all sorts of inspirational related things. There you go. And with that, that is the close of our show.

We try to keep it... I'm kidding. We're not keeping it commuter-friendly. This is not a the close of our show we uh we try to keep it uh we're i'm kidding we're not keeping it commuter friendly this is not commuter friendly show at all we ditched that idea just that a long time ago you know we used to do shows that were like 30 45 minutes long uh-huh and and people were just like it's it needs to be longer you know like we would get into conversations and end them prematurely and so here you go a 75 minute show at least and uh well yeah that's that's long you can call it commuter friendly in la or something you know we got that two hour commute so you know what i used to take a 75 minute commute when i was uh working a working at google like i live in jersey and i have to do to catch the bus to go into the city

every day. That's like 75 minutes one way. So there you go. You must be a fan of the changelog then. I am. Remember I was the first one to ping? You were and thank you so much for doing that. That was so awesome. We threw it out there and we're like, you know what? This is our open inbox and so for those

listening, you can go to github.com slash the changelog slash ping and go to the issues you'll see a bunch there and if you go to issue number one you'll find evan's original mention of view and that actually hit uh changelog weekly and the issue number for that was issue number 24 which shipped on february 15 2014 So that was a cool issue and Vue made it into there. So if you listen or if you read Channel Weekly, then you got that back in the day.

And we even linked to those examples we talked about earlier in the show. But with that, fellas, we do have a couple sponsors to mention. We got CodeShip, OpBeat, Braintree, and also DigitalOcean. But that is it for the show. Thanks also to the listeners for listening to the show and Evan Yu for sharing so much and being one person making an awesome project, really shine and being a good example of how to do it.

So thanks for coming on the show and let's say goodbye, fellas. Goodbye. Thanks for coming. Thanks for having me.