Discussing Vue.js and Personal Projects

I'm Evan Yu and you're listening to The Change Lock. Welcome back everyone. This is The Change Lock and I'm your host, Adam Stikoviak. This is episode 184 and on today's show, you're joined by Evan Yu, talking about view.js.

We had four awesome sponsors for this show, Co-Chip, upbeat, brain tree, and also digital ocean. Our first sponsor is Co-Chip. Got an awesome e-book out there. Totally for free.

It's a 21 page deep dive into why containers and Docker are the future. This free book is about the rise of the container stack and why Docker and its ecosystem and community place 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. Go check this out.

Resource.coach.com. I'll put the full URL in our show notes, so check that out and now onto the show. When we're back, we got an awesome guest with us today. Evan Yu is joining us.

Jared, it's kind of interesting because this show kind of kicked off with the very first issue submitted to Ping and that was Evan. Right. Yeah. That was a long time ago though.

That was like forever ago. Basically. He's our very first Ping. What do you say?

He said, can you cover view in that she's all we did. We were happy to do so. I think recently he wrote us a game and said, hey, let's talk about you on the podcast, which is sometimes 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. I said, that actually does sound pretty interesting. Let's do it. Let's do it.

Evan Yu, you created view.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? Right.

So I'm Evan Yu. I currently work at Meteor as a Core Dev and VJS is my personal project. Before joining Meteor, I was at Google. I worked at Google Creative Lab for over two years.

And before that, I went to Parsons, Parsons School for Design. I went to a masters program called MFA DD, which is Master of Fine Arts in Design Technology, which is a phone 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 started something completely unrelated to what I'm doing right now. 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 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. 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 was, so I looked around and Parsons had this type of program, which looked pretty fun.

And ended up doing a lot of code experiments on the web. And then somehow that's 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 view 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. Okay. So this is a two year thing that you've been, I guess, that was two years ago when you started Google Labs?

That's almost two, three years ago when I started. I started on view around two years ago. Okay. Did you know 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 Lab. It's like not the text. Okay. Right.

So Google Labs is yet another thing which is no longer in existence. Right. Google Access is this high-tech like branch and Google Creative Lab is more like marketing half UI prototyping. So we do a lot of internal prototypes.

We did the UX prototyping for Google Labs. We did a bunch of stuff for the Google iOS search app. We were also, we were one of the responsible party behind the Google, the rebranding in 2015. How was the big deal to that rebranding this?

So, I mean, I think it went over well. Everybody likes it. Yeah. It was pretty interesting because we actually had been pushing for it quite a while, but it actually went out after I have already left Creative Lab.

So it was pretty fun to see something you touched upon, you know, just going live after so long. You almost forget about it. Why don't you take us further back? Like before, before Google, you know, how did you kind of get into what you're doing?

Give us the back story. Sure. So as I mentioned, I did a lot of a flash when I was still in high school, I believe. I've always been fascinated by those, you know, really flashy websites, just fancy stuff.

And I want to figure out how to make them. I believe my first web page was built with front page. I basically copied the markup from just the random website I saw and tried to mow it into what I wanted to look like. That was a fun experience.

But at that time, I have no idea what's underneath. Like, I can't read the markup. I can't really read. I didn't even know what those script tags did.

Right. Right. So and later on, I started playing with Flash because it just felt a bit more visual than the front page, you know, and I thought it was still using the action script to something. 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 action script three, 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 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. I got to ask because it's not for me to have somebody who loves Flash or at least came from that.

I guess we all kind of came from the 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 a one of their versions, like version two or something.

I remember they built multiple versions of their website. Every time it's a completely different layout, different intro animations. Yeah. That was a crazy time.

The art was so amazing. That's what always fascinated me about what was Flash in that era. There's a very particular font, all these pixel fonts and this artistic style to it. It had a cool thing going for it.

I kind of miss a little bit of that. What about you? I do. I think it's especially too advanced now because they're the best.

There's nobody better than that. Yeah. They're probably one of a kind of 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 advanced. That's really cool. I'm impressed. 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. To advanced mean to nothing to me, Adam. I was starting to look at two live crew stuff once you stood that. I'm kind of off on tangent over here.

That means more to be than two advanced, although two advanced.com right now was just like a completely black page. So maybe it's because I don't have flash and they're still rock at all. I mean, it's like, seriously, just complete the blackness in a matter. I almost have flash installed.

I don't know why in Chrome. Is that just Safari, which? Oh, yeah. I'm in Chrome.

It's incredible works fine. I'm not sure if they still wait. It's too advanced, right? The number two.

Yeah, two. It's not. The number two. I can't either.

Also, I'm like up to 90 with a counter on how much is loaded. It's like a flash website. Yeah, it's still pretty a flash. Wow.

That's amazing. I mean, I never we've never had anybody on the show that knew of two advanced. So I had to drop that question for you to see if you were familiar with 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. It's something right.

Right. They're in the dust. So I guess we can move on as well to view, which is kind of the honest conversation here. View JS down.

That's VUE for those listening, not VIEW, 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, you know, it's been a few weeks since you've had a JS framework on the show, Adam, but it's actually been longer. It's been all the way back to 160 June was ampersand. I'm previous to that.

If you count react, I guess, which isn't, we know that's actually a view layer 149. So you know, once every three or four months, usually we bring up JavaScript 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.

You said you started it when you were at Google creative labs. Why did you start it originally? Okay, so primary reason was I was looking for something that 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 and use 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 liked the data buying 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 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 that just throw out Angular, Ember, React with Redux, and such things are really ampersand.

Which kind of is, you know, you can leave those out sort of in a continuum of lightweight and heavy weight and batteries included to more library-based, where would you fit into that landscape? It's probably closest to reacting that aspect. So it's more like, if you just core is the V in the MV-star system, it's strictly just a view 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, so 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 with React because with React, you sort of need to do some JSX translation to get off the ground.

But with you, it's literally just grab it off the CDN and you can just get up and going. And then when you reach a view core packs a bunch of things, versus 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 viewer. Similar to the React ecosystem, there's React Router, there's Redux. So, VJS would provide you with an optional view router. It has a set of opinionated build setups.

If you use browserify and Webpack, then you can use some transforms to write your view components in a very web component-like format, which in a single file, you 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're into that, but you can, 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?

How is it supposed to be used? Right. So I think the beauty of it is it doesn't really force you into one specific way of using it. The point being, a lot of people recently in the Laravel community are picking up view, 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 it's such an overkill when you just want to add simple reactivity to a server side rendered page. So a lot of them just use view for that specific purpose, right? You just grab it from the CDN and you can just get going. But when you 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 would suit it better, then they can grab the additional parts and they can still use view.

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 part 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 send us a link to an excellent post called Vue.js, a reintroduction, which highlights some of what Vue offers and compares and contrasts with the frameworks 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, we'll just 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 No.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 codebase through Git and makes monitoring and debugging your production apps much faster. It's free from unlimited number of users and until now has only been available for Django and Flask. But now they're launching a private beta for No.js and sharing it with our listeners first.

So go check it out and sign up for the beta. Head to opbeat.com slash change log. That's opbeat.com slash change log. All right.

We are back speaking with Evan you 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 keeping the state in 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.js 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 V.js converts plain JavaScript objects using some ES5 feature cut object to define 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 a property A and you use V.js as the templating system to bind a state on our star stack to the property. And so once you do that, the view and the data is essentially linked. 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 some other framework that uses the 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 uses this plain JavaScript objects in text. So it's, for example, in Knockout, you have to create KO.observables.

In Ember, you have to create Ember objects. But in Vue, it's just plain JavaScript objects. Like you can do an ADX call, you get some JSON, you parse it into plain objects and you shove it into a view instance and the view updates. So like you said, a lot of these frameworks require you to use Ember.create object or something to use their specific object which have observability built into them.

And you have to use getters in certain ways in some cases. I assumed you were using object.observer some sort of a new feature, but you're using Define property which is available in every major browser, right? Yeah, it's available down to IE9. So view doesn't support IE8 in the log, but anything above IE9 is fully supported.

I don't think that's problematic. I saw just the day that Microsoft, as of January, is deprecating all the way back to IE10. So 8, 9, and 10 will be officially unsupported, which is nice. Good stuff.

It is. Keep moving it forward. So are there any drawbacks to this method? It seems like if it was just used to find 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 on shimable 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 IE8, then this is totally feasible.

So there is some. So it's a technical, very technical comparison with, say, an Angular's mechanism, which is dirty checking or React's mechanism, which is virtual. I would categorize the two into the pool-based mechanisms and the push-based mechanism. So all 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 or update the interview.

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 on watchers to do the dirty checking and in React, you render a new virtual DOM tree and dip it with the O1. 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, 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. In React, you have to call setState. If you directly mutate your state, there's no way for React and Angular to know it has changed.

The comparison is that push-based mechanism has better runtime performance, but it has a slightly higher 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. You have to be, 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 get updated.

But in a pull-based system, because it's somewhat brute force, obviously there's a lot of optimization 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 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 doing checking is hard to optimize, but virtual DOM is somewhat more optimizable because how in React you can implement a per component method called shared component update to sort of short-circuit some of the virtual DOM diffing, but it's still a manual process. So would you say that view is neither push nor pull then? It is in the push-camp. I might have, no, I just realized I might have gone into too much technical details.

No, that's good. Go deep, please. Sure. So what about, so you're working with plain JavaScript objects.

Obviously your 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 general advice is prefer to, because all the reactive parts in your app, especially in a view-day app, that represents the state of your application. 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 JSON request. When you get some data from your server, the response wouldn't contain functions.

So most of the case you kind of want to think of these reactive objects as things you would want to persist into the server, or things that basically describe what your app state is like, instead of putting arbitrary objects in it. So view 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 and up-based the view, and if you update it in the view, it updates the model, correct?

Yeah. So view 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 really happens under the hood is the user has triggered some input events.

So the event triggers view to modifying the state, which is the object. And because that object is modified, it triggers the view to re-render, right? 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 sugar to make it easier to write. Sure. Aren't there times when your event triggers wouldn't necessarily want to re-render, though? Right.

So in that case, you'd simply use event listeners instead of two-way binds. So view gives you the options in that case? Yes. So two-way data binding, I realize that you don't love the term, but people are used to that term.

So with that particular aspect of view, Ember famously had two-way data binding, this back and forth push and pull as a flagship feature early on. And then they realize it's not actually always useful. And so let's allow people to turn it off and on. It's cool that view allows that kind of flexibility.

But when it's on and you're using it, and when you have that feature on, are there performance implications that you found with view? 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, this type of two-way data binding is what, like say when you're typing into a field and the model updates and something else that's also bound to that property also updates. So this form-based two-way data binding in my opinion is just in test 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 view is doing too.

The default, the way you pass data from a parent component to a child component view 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 the 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 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 view, which is components. Maybe a little bit different than the component you just mentioned or perhaps the same.

Can you describe? I believe this is akin to Angular's directives or Ember. I guess they renamed theirs. They think they were views at one point.

They're components. All these terms. Can you describe components in the view? Sure.

I believe most of the major frameworks right now have converged on components. Angular 2 is built around components. Ember is all about components now. React has started with components.

So I think more or less we have, like the whole ecosystem have sort of agreed that the component is a really good abstraction of the building user interfaces. And most of the UI can be represented as a tree of nested components. 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 self-contained and reusable.

So when you build it and you want to use it elsewhere, you 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 a view, it's still pretty simple because when a lot of people first start with view, the only thing they know is they can create a view instance.

A view instance is essentially an object that binds a raw data object to a piece of DOM. So these type 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 view 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. Essentially, it's like a class, but not exactly a class, but something like that. So when you create a component, you view it called view.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. 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, anyway you want. So the view component development experience is very similar to that.

But on top of that, you provide use the mechanism necessary to communicate between the components. For example, you can use the props 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 parent that it needs to do something. So this sort of event, triggering parent actions using events to compose the child and parent, because the child is only responsible for a dispatching 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 you also implement something that's very closely modeled after the web component spec. There is a mechanism called slots, which is previously content. So they recently, the Smackgafter switched the content API to the slot API, and view 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, right? So what should we render? We need to somehow find a way to weave these runtime elements inside of it with its own template so that's what slot does.

It allows you to sort of 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 second issue is how do children notify their parents something has changed without directly coupled to the parent? 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 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 view 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 polyfills or not? And you don't need to worry about it having a few 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 already 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 a new response to break at this point.

On the other side, we'll talk about modularity, animations, and stability. Be right back. Braintree is all about making developer lives simpler with code for easy online payments. If you're searching for a simple payment solution, check out Braintree for mobile developers out there.

The Braintree D.0 SDK makes it easy to offer multiple payment types, start accepting PayPal, Apple Pay, Bitcoin, Benmo, traditional credit cards, and whatever's next, all with a single integration. And do a simple secure payments that you can integrate in minutes and developers have 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, you have them a call and they'll handle integration for you and walk you through it. Braintree supports Android, iOS, and JavaScript clients. They have SDKs and several 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, be free. Go to braintreepainis.com slash change log. All right. We are back.

Let's talk about modularity. Once you have your components, Evan, how do you want to limit 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 common.js, AMD, or ES 2015 modules. There are a lot of ways to do it, but the preferred way with UJS is use either Webpack or browserify. So that indicates we want to write our components as common.js modules.

But thanks to the transforms in these ecosystems, so you can use either Babel, Babel loader, or BablyFi, but both uses Babel to transpile your ES6 or ES 2015 code into plain JavaScript. So you can use ES6 modules too. And when you use Webpack or browserify, there are two specific tools. With Webpack, it's called Viewloader.

With the browserify, it's called Vueify. These two do the same thing. They allow you to write your view components in a view-specific format. It's called a single file component.

As I would call it, it's very similar to a component too. 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. I think back when we built applications with Angular or some other client 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.

I came to the conclusion, you shouldn't do that. They should be grouped based on what they are about. You have a template, you have a script file, you have a JavaScript, but they are all related to the same feature or functionality in your app. For example, this button that you're building.

The button has its template, it has its logic, it has its styles. Why should it 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. I think it makes it easier for you to think in terms of components and to the components. Web components is a step in that direction and obviously a source of inspiration. I think React 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 idea is the same. Every component is its own file and it makes things much easier to think about and to organize. And the good thing, so people may ask, why do you invent another component format? Why don't you just use Web components?

The answer is because a few components are transpowered using Webpack, you get to leverage the full power of Webpack. So you can use pre-processors inside your view components. So if you want to use SAS less or stylus for your style, you can do that. Or if you want to write jate templates for your view components.

Yes, you can do that. Or if you want to use coffee script for all your scripts. Yes, by all means. So that's the beauty of it.

You have the same format for your components, but you also have the freedom to use all the pre-processors that you like inside of it. And in the end, because what Vularitr does is it strikes out each part of your component, you can type them through the appropriate loaders that should be used. For example, if you write SAS and your component, it will pipe it through the SAS loader to process it. And eventually it assembles all the parts back together into a common-gen S module.

Then these modules eventually get sponded together to become your app. And I think that makes it just, so when you use view components, you don't have to throw away all the tooling that you're familiar with. You can leverage all the community contributions in the SAS community or in the last community. Or you can use the favorite language that you like.

So you're still doing it the battle ways, as Jared said. And when you run Vularitr, it's dubbing it into a single file. It's processing as you said through the SAS file through different compilers. You're still running the old way.

No, this all happens in memory. It's like Webpack is responsible 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 offer your components, and Webpack is responsible for assembling it together into a final bundle. Yeah, actually. And these comments and the file, is that what allows the delimiter system to happen to make that possible? Those comments are totally optional.

The way you indicate your preprocessor, if you scroll down, you'll see you provide the land attribute on your template or style blocks to indicate the language you use. Gotcha. Yeah. Yes.

And in addition to that, if you doesn't really use Shadow DOM because it's not a stable feature yet, but if you 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. That's really just providing a special view syntax highlighting file.

I have a view.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. Gotcha. So you're supporting the one for Sublime Text that essentially a .view file, you can mix CSS, whatever you want to choose, JavaScript and HTML, J, whatever you choose for front of languages. You can do that with view and you maintain that yourself.

Exactly. 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. Pretty awesome.

Because otherwise, you're maintaining six languages across a single syntax. That's how you're doing HTML, right? You can't even add JavaScript and CSSing HTML. Same thing.

So in fact, the view syntax highlighting file is a modified version of HTML syntax highlighting file. All it does is detecting the special language attributes in order to pulling a different syntax rules for that block. That's interesting. You get to get the tried and true syntax, but you're not creating something new.

And you're living an attribute to sort of toggle back and forth between languages. Yeah. Jared, your favorite word is over 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 a hot model replacement API, and then when you add it to 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.

So obviously, this has to go back to React Hot reloading that's popularized by Dan Abramoff. So he's double at React Conf Europe showing all the time travel, hot reloading of, I think he was the original author of the React Hot Loader, and then he went on doing all those hot reloading related work, which is super inspiring. And that's what kind of tricking me to investigate. Is it possible to make a view component hot reloadable?

And sure as 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, then 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 SAS recently, a lot of partners around that is libsas and it being faster to compile.

So if you've got a big CSS tag, for example, then you might be delayed on the actual compilers of SAS. The good part is Webpack basically handles it for you. Webpack uses a lot of advanced optimizations, incremental rebuilding, and it catches each module it compiles. So say when you are editing a single view component, only that component will get recompiled.

All the other components are unaffected. And usually when we talk about SAS being slow to compile, it's because we are recompiling all the styles for the entire app on every watch. That is obviously going to be slow. But if you're only compiling a small SAS file, it's always going to be fast enough.

And if you're writing that much SAS inside a single component, you probably should reconsider. Wise words, wise words. Shameless plug, we're going to end on in a couple of weeks. It's true.

And Abramov. Yeah. So stating for that. It's a game for that.

Flux. Oh, Josh, should we skip animations and writing? We're kind of getting short on time and jump rate sustainability. Maybe you can give a one minute version of what you're talking about in routing and animations.

Evan, what do you think? I can probably skip animation and just talk about routing. What's the most important thing happening here? Right.

So if you're router is optional, like VJS core doesn't consider itself with routing. If you want routing 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 router to do. You can either use hash mode or HTML5 history mode.

It's a little bit opinionating that it matches 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 views on transition systems to easily apply transition effects. You have fine-grained 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 view 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 digital ocean. If you've tried digital ocean, you know how awesome it is. And here at the Change Vlog, everything we have runs on blazing fast SSD cloud servers from digital ocean.

And I want you to use the code CHINZWALB when you sign up today to get a free month, run a server with 1g of RAM and 30g of SSD drive space, totally for free, on digital ocean, use the code CHINZWALB. Again, that code is CHINZWALB. Use that when you sign up for a new account, head to digitalocean.com to sign up and tell them to change the load sent you. Alright, so we're here with Evan, you know, we're talking about Vue.js and, you know, this is the tailing of this article that's kind of diving into the reintroduction of Vue.js and stability seems to be the, you know, the ending hook here.

And a quote you put in here, Evan was a personal project with a question mark, seriously question mark. So like, I guess maybe people don't think it's stable. What's the situation here? Well, I've seen some discussions where, for example, in a comment where people say, hey, I think Vue.js is nice.

And then there will be that guy who just jumps out and say, oh, it's just a personal project dying a year. That guy. Right? And, you know, people just like knowing a project is backed by a huge enterprise, I have a full team of people working behind it.

That gives them a sense of, I don't know, maybe you just make some feel safe. I agree. It's important to think about how stable the software that you use to build a product upon. But sometimes, you know, whether it's a personal project or not may not be the design factor because we know there are a lot of great personal projects that stand out like backbone or coffee scripts or both personal projects by Jeremy Ashkenes.

And he has like more than one of the cyber projects, right? It's amazing. And so many people use it. I don't get the situation with that because I think Jared helped 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 looking at what we use. And 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 up in source and seeing the light with regards to licensing costs and maintainability in 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.

They, you know, they have money to spend on things like support and just, you know, wanting a company to be there. So I get both sides. You know, even as an individual software developer who's just been in the startup scene for long enough, like, I don't love fly by night things. You know, you think of services you're going to start relying upon.

Like, what if Slack just disappeared now that we're all, you know, loving it? That kind of would suck. You know, that would be a disruption to us. And so there's, it's risk of a verse mint, another word.

Adversement. Yeah. It's just been a versatile risk. And thinking that a single developer project is riskier than something that's back by corporation, which it is.

But I think as you said in your post here, Evan, you're approved by your track record. And the fact is that you've been maintaining this for multiple years and you've reached a stable 1.0 and you have 100% test coverage and you go through reasons why you are 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 to have that problem. Is that why you put this here at the close of your article? Yeah. Mostly this is sort of out of my, because I've been, I've been seeing people talk about you quite a lot of times.

And this question comes up actually quite often. Like when people ask, is this still going to be a rallying 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 in a few years. If you take a look at 2D, MVC, like they're like the survival rate is not that great, I would say.

Some frameworks are just no longer maintained or things like that. So people in general, I kind of understand why when they are accessing a new JavaScript framework, and especially if it's a personal one, they would think, oh, it has a high chance that it's just not going to be a rallying a year or so. But again, I think it's a common first impression. But when you really want to seriously evaluate a project, it's better to look at the real numbers.

Because everything is public. The issues, the commits, everything that this project has gone through is on GitHub. You can just go there, you can see how many issues are there, how many bugs are open, how fast are they closed or fixed, there are statistics for that. And you can look at the commit lock to see 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 happens.

Right, that's a good point there. Is it, you may think of something, Evan, is there any sort of tool that you know of that you can point in a repo and say a bug issue is opened and closed as quickly with a resolution? Yes, there is a site called issue stats.com, I believe. It's a site where you're just typing the repo and it'll analyze the how fast issues and protocols are merged or closed for that specific repo.

And even have a badge on the VGS readme. So if you go to, yeah, it's called issue stats.com. This is interesting. There it is.

There's no other story. Is this new to you? This is new to me. Very cool.

Brandon right here. Wow. Thanks, Evan. No problem.

I actually learned about this a while ago, I think because Babel, Babel also used this and Sebastian Bao'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 for that turned out.

Not that it's in a super bad way, but you know, it's had some hurdles, most of the story short. With view, obviously, you can point issues or issues stats at this and get some good results back at test coverage, issues, 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 into that. I think it's also worth mentioning.

I think probably, 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 with the responsibility of like ever writing any code or maintaining things yourselves or, you know, that's the beauty. I'm not sure what your licensing is. 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 camera. What else about all MIT says? You can't sue us for anything. You have all the source code of a stable thing, right?

And you're a software developer or your company that writes software, you know, just you can also help out. So, you know, if Evan totally is like, I'm done with you, 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 a new shiny. Like somebody else can just step in and take it over and run from there or if he's doing it in the way you don't like to, you know, that's what the four buttons were.

So I think it is risk averse, but it's also perhaps a little bit of laziness or something. Just going to put out there. Somebody, I wish I had a research just 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'd recently listened to the show and they're 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 button that showed us and that's a good paraphrase. Actually, right here it is. It's Nicholas Young listening to the change of the latest episode on Metabase and realizing I couldn't build businesses without open source.

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 at the same time, get responsibility to give back and not just freeload, you know, and he's right. Today he 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 enjoy it, you know, sometimes I get down and carry him a little bit. Right.

Point points. Point points. That means that you do have stability. You've proven that and just for the record, are you going to give up on view here after the call's over or are you going to keep working on it?

I guess the latter. All right. That sounds good. So we touch quickly.

I know we're like getting close on our time for like nine minutes left, but it'll be remiss if we didn't at least touch on the interesting things happening with the Laraville community. Uh huh. Yeah. So just a couple of points that you made that we'd like to highlight is that Laraville has been picking up view at a very fast pace.

It's got, you know, 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 set about view on Hacker News. So what's your secret? Um, but for instance, wow, the docs look great for being 99% of 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. 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 sign of my left. That's probably a much harder question than I expected. Um, I don't know.

It's very specifically tied to view because it's been my baby. So I care about it and I don't want to, you know, just make it as good as presentable as possible. Like the point being, um, 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 saying, hey, like, thank you for making this great project. So that really makes me happy. And that kind of keeps him motivated and, you know, keep working on you, making it better. But writing better docs so people can, you know, have an easier time working with it.

I think all of these sort of ends up showing like it's a project built with, with care of 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 don't really plan on, you know, doing long term investment into it.

Or they just simply don't think they want to, you know, go that far to, to make it something that, um, that would attract more people or maybe they just don't care, but I do care. So I am willing to, you know, write a 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 paid it front end work before to find it enjoyable. I think that's, that's just great.