Check out React Remote Conf!

02:31 - Rob Eisenberg Introduction

• Twitter
• GitHub
• Blog

02:55 - Aurelia

• Blog

03:43 - Selling People on Aurelia vs Other Frameworks

11:09 - Using Aurelia Without Directly Engaging with the API

• Web Components

15:10 - Production Usage

18:46 - Specific Uses

23:03 - Durandal

25:26 - Aurelia and Angular 2

30:32 - Convention Over Configuration

34:56 - Web Components

• Content Projection (Transclusion)
• Polymer

41:13 - One-directional Data Flow; Data Binding

• Using a Binding System as Messaging System

46:55 - Routing

49:47 - Animation

52:56 - Code Size

55:06 - Version Support

56:27 - Performance

• Tools

01:00:20 - Aurelia in ES5

01:01:29 - Data Management

• Breeze.js Picks

Crispy Bacon (Joe)A Gentleman’s Guide to Love and Murder (Joe)Jamison Dance: Rethinking All Practices: Building Applications in Elm @ React.js Conf 2016 (Joe)Vessel | Lorn (Jamison)The Moon Rang Like a Bell | Hundred Waters (Jamison)The Top 10 Episodes of JavaScript Jabber (Chuck)Amazon Prime (Chuck)WiiU (Chuck)Sketch (Rob)Zeplin (Rob)servo (Rob)

Transcript

JOE:  Yeah, you sound super sexy in [inaudible][laughter] ROB:  That's what my wife says, I think. CHUCK:  Hey everybody and welcome to episode 203 of the JavaScript Jabber Show. This week on our panel we have Joe Eames. JOE:  Hey everybody. CHUCK:  Jamison Dance. JAMISON:  Hello, friends. CHUCK:  Dave Smith. DAVE:  Hi. CHUCK:  I'm Charles Max Wood from DevChat.tv. Quick shout-out about React Remote Conf coming up in about two months. We also have a special guest this week and that's Rob Eisenberg. ROB:  Hey. CHUCK:  Do you want to introduce yourself real quick? ROB:  Sure. My name is Rob Eisenberg. I'm a JavaScript client guy. [Chuckles] I'm the lead architect for Aurelia. I've also worked on a number of other frontend frameworks. Durandal, Caliburn.Micro, Caliburn, on a bunch of different platforms. So, that is my passion. And I love working with developers and helping them to build frontend. CHUCK:  Cool. Do you want to tell us, give us the elevator pitch for Aurelia? ROB:  Sure. Aurelia's a next generation JavaScript framework for building apps across mobile, tablet, desktop, the browser of course. Anywhere where web technology reigns supreme. And we're all about simplicity, conventions, really keeping your JavaScript code pure and clean. Aurelia's very focused on standards compliance and just to help you to be real productive and enjoy the developer experience while you're building apps. CHUCK:  Yeah, you said it's a next generation app and I was thinking, “The web. The final frontier.” ROB:  That's right. [Laughs] CHUCK:  “These are the voyages of the framework Aurelia.” [Chuckles] ROB:  Got to have a Star Trek reference. CHUCK:  That's right. JOE:  [Chuckles] JAMISON:  So, I feel like we kind of live in a world where there are only three frameworks for most people. DAVE:  Oh, I was going to say two. [Chuckles] JAMISON:  And right now that's Angular and React and Ember. How do you as someone outside of the large three that dominate the market share, how do you sell people on Aurelia? Are you trying to take people from these other frameworks where you say, “These are problems you encounter in other frameworks”? Are you aiming at people that coming from maybe jQuery or from non-JavaScript backgrounds? What's the selling point for people from these different backgrounds? ROB:  Yeah. It's a little bit of everything, to be honest. There are a lot of people that haven't really made the leap so to speak into building rich JavaScript frontend apps yet. So, something like Aurelia makes a lot of sense for them. It's really easy to learn. If they don't have any preconceived notions especially about how these things go together it actually maps very nicely to a lot of native app development concepts. So, they see a lot of things that are familiar to them. So, that's one group of people. And again, one of the things that are kind of a selling point I guess across all groups is just the simplicity of development with it. You basically, you create a JavaScript class, you create a view, and that's your component. There's no configuration. There's no special APIs to call. That's just a very simple way of putting things together. And of course we also try and address a number of issues that other platforms suffer from. So, we do talk about that. We have to be careful about that because people will get upset. [Chuckles] JAMISON:  Yeah, yeah. CHUCK:  Are you attacking people's babies? ROB:  When you call the baby ugly, they get a little upset about that. But the truth of the matter is that as time passes, we learn things as a community. We learn things as individuals. We find ways to do things better. And we need to pay attention to those. And I really, I [try] to take some lessons from a lot of things that have happened in the past and make evolutionary movements forward in terms of fixing different kinds of things and improving different things. So, we try and make developer and designer collaboration really easily buy just staying close to web standards and having a strict separation between views and view models, which is part of our component design. We try and have a very extensible, very modular system so that there's way to plug in all over the place and customize things. We try and follow a very declarative model. We try and stay out of your way as a framework. So, you don't have to learn a ton of APIs just to get things done. So, that makes the framework just more learnable and more easy to read, easy to bring new people in. But I think there are a lot of evolutionary things that we're doing that appeal to people coming from, that have experience with Ember or Angular or React that look at it and go, “Okay, wow. This makes sense. That's really simple.” And they can see how they can put these pieces together. Hopefully that answers your question. There are so many different perspectives and people with different backgrounds out there. But I think that there's something of interest of course in Aurelia no matter what perspective you're coming from. So, we're trying to talk about a lot of different things. JAMISON:  Yeah. Yeah, I'm just… it seems like a pretty uphill climb in the current climate to sell a new web framework, or a new JavaScript client-side MVC. ROB:  I think it's been amazingly successful. If you look at some of our statistics, our Gitter chat room has over 3,000 developers in it that makes it the seventh largest Gitter room in the world. It has about 223,000 messages which is the second most active Gitter room in the world. We have over 300 contributors to the open source project. That's not including our core team. That's 100 more contributors than Angular 2 has. That's about half of what Ember and React have and we've only been announced for about one year, compared to the three to six years that those other frameworks have had. So, you can see that what is happening with Aurelia is actually a rather rapid growth. So, yes it is a challenge but I think when people are seeing it and they're trying it out and they're catching the vision for what we're building and see the directing of where we're going, it's making a lot of sense to them. And a lot of people are getting involved and starting to build things. So, I think if you look at the life of the project, like I said we only announced the alpha in February of last year and we're still in the beta right now, the amount of growth and traction that has happened in that very short period of time is rather phenomenal, especially when you do compare it to some of these other frameworks that have been around for multiple years, or that have big marketing or branding, if you will, powers behind them. CHUCK:  So then, I'm curious. What is the draw with Aurelia? I definitely see the challenges with displacing some incumbents. But at the same time, you're also going to get people, new people coming in and looking at frameworks and going, “This is the one I want to use,” or coming over from React or Angular or Ember saying, “I like this particular bit of things better than something else.” So, what is that selling point? What is that thing that people are coming and seeing and going, “Yeah, this is the thing I want”? ROB:  So, the first thing people see and it becomes immediately obvious when you use Aurelia is the absence of the framework inside of your application code. So with Aurelia, we try to make the framework be more ambient in the sense that it's doing the work for you behind the scenes. But when you're writing your app, you just store plain JavaScript. So, Aurelia is really the only framework that I know today where you literally can build entire applications without importing the library anywhere into your JavaScript code. Now in reality, you do import our APIs and use them in more complex scenarios. But the point is the framework really stays out of your way. So, you can model your application through just pure JavaScript classes. And you don't see the framework intruding into your code. And that just lets developers focus on their app more and makes their own code easier to read and understand. Again, it makes it easier to learn things. They don't have to worry about a bunch of APIs. It makes things more extensible. It increases the lifetime of your code, because as frameworks and technologies change over time, the less that the framework intrudes into your app code, it means the longer the life of your app code. It's going to survive changes in other technologies easier. It means that we can rev our framework more even across major versions without incurring a lot of upgrade work on the part of developers. Again, because they're not engaging our APIs directly as much as with other frameworks. So, I think developers see this and they go, “Wow, this is about the best it could be,” in that sense that I just wrote a plain JavaScript class. I didn't import some Aurelia library. I didn't call some special API. It's just a class with properties and methods. And then there's an HTML view that renders that out. And it's just really simple and clean. And I think that's the first thing that probably catches most people and they go, “Oh, this makes sense and I like this, because I really don't want to have to learn a million Angular API calls to create some directive. I should just be able to create a class and it should just work.” And that's what Aurelia does. So, that's the first thing I think that catches people. And that's I think something that's very unique to Aurelia that I haven't seen really anywhere else. JOE:  Would you… DAVE:   Could you go… JOE:  Sorry, go ahead. DAVE:  Could you go a little bit more into detail on how exactly you can use Aurelia without actually directly engaging with the API to use your terms? What does that look like hands on? ROB:  Yeah, so imagine that you just create a class called app and it has two properties. I'll just give it a property message and give it a method called I don't know, speak or something. And it shows an alert that displays that message. Now it's just a normal class. You're not importing some Aurelia APIs or anything like that. But it has state and it has properties and it has methods. And then you create a view which is a web components HTML template. And you create some HTML that's going to render that class. And so, the methods and properties of the class are available to you to bind to in the view. So, that's the only place that you see “Aurelia APIs”. It's a very simple binding [inaudible] in the HTML. Your JavaScript remains clean and pure as just a plain class. So, that's how you would put together say a simple component. Now, you can build, break your app down of course into components and components of components and components of components of components. And you can compose them together. And you can choose how you want to compose them. You can compose them through JavaScript, through standard object composition techniques, and Aurelia can render that out. Because it just renders the state of the objects. Or you can compose them through the view as well by using a custom element called compose we have, which you can point at any class and it will render that class using its view. So, you can use these different techniques of composition. But it's actually possible to build whole apps without ever, like I said, without ever using any Aurelia APIs in JavaScript. You can keep your JavaScript really clean and pure. In practice, you usually use some of our APIs for a few things at least, just because it's more practical to architect things in certain ways. But you have a much cleaner JavaScript codebase which is free from intrusion of the library APIs themselves. DAVE:  So, if I'm understanding correctly, you're saying the JavaScript itself won't necessarily inherit from or call into any Aurelia-specific APIs but the HTML will, right? But it also uses web components language somehow. Can you explain how that works? Where does Aurelia start and web components stop and so on? ROB:  Yeah. So, when you create an Aurelia component, it has two parts to it. It has the JavaScript part and the HTML part. The HTML part is just an HTML fragment that resides inside of an HTML template. And that's a web component. Part of the web components spec is the HTML template element. So, we leverage web component technology for that. What Aurelia does is it understands that components are constructed in a certain way. It knows that every component has this JavaScript class. It knows that it has this corresponding view. And therefore it knows how to instantiate the class. It knows how to compile or parse the template. It knows how to bind them together and render that. So, it does all that work if you will, behind the scenes. We use various other web components technologies. You can use shadow DOM if you want. And we have a fallback if the browser doesn't support shadow DOM. We don't use HTML imports. That's not really happening right now. And we have an option to use web components custom elements if you want. But we use our own custom element code internally because it's way, way, way more efficient for a lot of scenarios. So, we use a couple of the web component specs where applicable and we make other ones optional. But really again, it's just about trying to make it easy to develop. So, developers can really just think about, “What is my code? What is the state that's interesting to display here? What is the behavior here?” and not having to worry about lots of configuration or metadata or API calls just to set up a component. You don't inherit from anything. You don't have to configure anything. You just create a class and then you create your view. JOE:  So, I'm a little curious about the production usage so far of Aurelia. What kind of projects are you seeing people put together in production? And in addition to the projects, what kind of people are you seeing adopting Aurelia for production use? Like big enterprise, smaller businesses, line of business type stuff. What do you see? ROB:  Right. So first, let me just preface by saying I can't give any company names because [chuckles] I have to be real careful about that. Various companies' marketing departments don't approve of me using their name in certain context. But… JOE:  If you whisper it in pig Latin, it's actually okay. [Laughter] ROB:  I could tell you that there are various large companies which you would recognize the names are using it for a number of things. We're seeing it used across a lot of different companies. It's being used in healthcare. It's being used in insurance. It's being used in manufacturing. It's being used in, certainly it's being used in line of business. It's being used in the financial industry. We're seeing it used for more design-oriented things also and media-oriented apps. I'm trying to think. What are some other examples? It's just about everything, to be honest. Transportation industry, government… JOE:  So, by no means is it going into a niche in those respects. ROB:  No, no. It's a general purpose application. JOE:  Both team size or products, project itself. ROB:  It works really well for very large-scale projects. It works really well for small projects. It's great. One of the things that Aurelia is very good at is facilitating team collaboration. In fact there's a really cool Pluralsight course coming out that one of our core team members did, which is how to use Aurelia to facilitate team productivity. And there are just certain things about the way the framework is put together that it helps a group of people work together really well. So, you can have a very large-scale team, have multiple teams working on highly composited apps, or you can have just a single person, that they are the owner or developer [chuckles] marketer of their company and they're developing their own product. We have the full breadth of scenarios at companies building with Aurelia now. JOE:  So, one of the things that you will sometimes hear different framework apologists talk about is, “Hey,” and I think I often see this in blog posts where somebody put a blog post that says, “Choose between these five frameworks.” And then when they get down to it, they try to break it down to, “If you're doing this type of application, you should use this framework. If you're doing this type, you should use this framework.” I personally have never adopted that sort of attitude. I've never thought that that was really a viable way to choose a framework, was based on the kind of app. Now there are certainly some kinds of app that just don't make sense for certain frameworks. DAVE:  I don't know, Joe. If you're building an Angular app, you should probably use Angular. [Laughter] CHUCK:  I can give you an example, though. Some of the things that I've heard are for example, Ember has some really nice data management bits to it where you're pulling data off of the server and you're keeping track of all that stuff. React manages state flow and data flow really nicely. Ember is usually used to manage transformations on the DOM and things like that really neatly. And the flip side of this is that the TodoMVC I've heard proponents of… [Chuckles] CHUCK:  pretty much everything except Backbone say, “Yeah, well it doesn't show off the really powerful features of the framework.” So, are there specific… DAVE:  [Chuckles] Yeah, surprise, surprise. CHUCK:  Aspects of Aurelia that lend themselves really nicely to specific classes of problems? ROB:  Sure. One thing that Aurelia does very well is what I would call dynamic composition of user interfaces. So, imagine that you're building a dashboard app and depending on what user is logging in, they're going to have their own custom configuration of widgets that are displayed on their dashboard. Which widgets they have selected and how they're configured. And so, when you render that screen out you want to render these widgets based off of the data. And with other frameworks usually you have to write a lot of imperative code to do that. It's a bit complicated. With Aurelia it's super simple, because we have this notion of UI composition whereby you can basically just repeat over this list of widget configurations and just render each one. And even if they're different types of objects or different types of widgets, we can polymorphically render them. So, for each type of object we can automatically render a different component, and so on and so forth. I once actually built a system, this is actually with Durandal, but this concept comes from Durandal into Aurelia, I once built a system that was a graphical scripting engine whereby we completely render the entire abstract syntax tree of the language as a set of hierarchical components. And it was done with this one simple composition capability. It required exactly two lines of HTML to do. And the system was fully extensible so that as I expanded the scripting language over time, I simply created new AST nodes and new views, one for each of them. And it just worked. So, it was very, it was a good architecture that illustrated the use of the open/close principle so that the system could be basically infinitely extended without ever having to change any of the existing code. And that's kind of the thing that you get by using compositional patterns. And Aurelia is very, very, very good at this. So, you can… we talk about these components and [inaudible] foo custom element and bar custom element in this screen and that screen. But the other thing that Aurelia can do is dynamically combine and render any combination of class, view, and model object. And it can combine them in certain ways and it can do it completely based on data at runtime. And as those values change over the course of the program that we'll recompose and re-render only the parts of the screen that change based off of the changing of that data. So, if you've got a really, if you've got an app that you're building that's very driven structurally and visually by the content of the data itself, then Aurelia makes it very, very easy to build that kind of an app. And like you mentioned, pretty much all the major frameworks, they do most things pretty well. But that's something that Aurelia does exceptionally well. And I hadn't really seen anything quite like it among the other major frameworks. You could do that with React pretty easily I think just because you would use traditional JavaScript polymorphism to do that kind of thing, to render your React components that way. I haven't seen what I'm talking about in any of the frameworks like Aurelia that have more declarative data binding systems like in Ember or in Angular or something like that. DAVE:  Yeah. It seems like you're saying you can, at runtime you can mix and match what templates should be rendered with what component. ROB:  Absolutely. DAVE:  And it seems like in Angular, and I don't know about Ember, but that stuff is all defined more statically. [Inaudible] ROB:  Yeah, so with Aurelia we have conventions because 80% of the time you do, do it a particular way. But you can override the conventions and you can use these other compositional mechanisms that let you mix and match anything. And again, it can be completely based off of data and it can change as the data changes over the life of the app. And it's really easy to do that. I'm very passionate about that feature because I worked a lot over the years with companies building apps where this particular feature just ended up making something take five minutes instead of five days or five weeks, even in some cases. So, it's very, very powerful. And that's a core capability of Aurelia that I think people end up selecting it for, that dynamic UI composition. JOE:  Interesting. CHUCK:  So, you mentioned Durandal. Is Aurelia Durandal 2 or is it totally different or mostly different? ROB:  So, yeah Durandal… there is actually a 2.0 of Durandal. So, Durandal had two major versions and it's still quite successful today. It's one of those I think less-known frameworks. But everywhere I go, every city, every country, people are coming up to me telling me what about they built with it. It's actually a lot behind the scenes in big companies and in governments and in insurance and healthcare and other places. So, it's not the kind of thing that you would see out in the limelight. But it's used all over the place. And really, what happened with Durandal 2 is there came a point where I realized that to really take things to the next level, it needed to be re-imagined in terms of ECMAScript 2015, in terms of web components and some other things like this. And Durandal is really built as a thin layer over RequireJS, jQuery and Knockout. And some of those dependencies are actually causing some limitations on Durandal itself. And so, we realized that we needed to remove those third-party dependencies, build a new modern data binding engine, base modularization on ECMAScript 2015 modules, get rid of the jQuery abstraction which was not necessary in modern browsers. And so, you can think of Aurelia as a re-imagining of Durandal. There are a lot of similarities for anyone that used Durandal in the past that will recognize that our router is basically configured the same way, our navigation and routing life cycle has the same names for all the callbacks. Durandal had this composition capability. Aurelia has it. It's nicer in Aurelia. The methodology for creating components and building apps is the same with Aurelia as it was in Durandal. So, there's a lot, a lot of similarities so that people that have Durandal codebases can very easily migrate to Aurelia. And we have members of our core team that were highly active Durandal members that actually migrated rather serious apps to Aurelia really early last year with great success. So, you could think of it as, it's not Durandal 2.0. It's like a Durandal 5.0. It's a really re-imagining, kind of jumping ahead, but really in the same vein, the same concepts evolved in terms of more modern technology. JOE:  While we're on the topic, I would like to hear about the similarities between Aurelia and Angular 2. I know from history you spent some time on the Angular 2 team. Then you left and you went and started Aurelia. So, what similarities does Aurelia and Angular 2, and I actually have a little bit of experience since I wrote a blog post about a little simple app to write in Angular 2 and you wrote a derivative blog post on that showing how to build it in Aurelia, showing that, “Hey, there's actually a ton less ceremony and stuff when do you the same thing in Aurelia.” So, I'm kind of curious as to what the similarities might be. ROB:  Right, well the similarities are from an architectural perspective I'm looking at components. Both frameworks use the same separated presentation pattern. So, things like MVC, MVP, MVVM, all these patterns that are under the umbrella of separated presentation, each framework picks one of those and has their own twist on it. And really, both Angular 2 and Aurelia use something that would be called the view model pattern, or the presentation model pattern, or you may have heard the model view view-model pattern. And this is something that arose really in heavily data binding based platforms. And this pattern is where essentially you have some class or object that models the state and behavior and where you have a view that renders that state. In effect the class becomes a model for the view. And so, both Aurelia and Angular 2 have that same basic architectural concept when it comes to building components. And incidentally that's actually the same design pattern that Durandal uses and it's the same design pattern that some of my other platforms use going back to about 2005. I first started using that particular presentation pattern on Windows Presentation Foundation which was a highly declarative data binding based platform that Microsoft released. They released it in 2006. I was an early adopter. And that's when that term view-model or model view view-model started to originate. It was in that community. And of course it's used, it was used in Flash and Flex and it was used in Silverlight. And it was started to be used on the web as well. So, that's a big similarity in terms of the architectural way that components are put together. Where they differ then is in the details of how you do constructing these view/view-model pairs if you will. As you mentioned, you had written this post that showed how to do it with Angular 2 and basically what I did is I cut out a whole bunch of code and said, “And this is how you do it with Aurelia.” Because Aurelia is very, favors convention over configuration. So, you would just create a class and create a view in Aurelia whereas in Angular 2 you would have to have a lot more metadata to describe how those pieces fit together. Other similarities. They're both component-oriented architectures. That's very common in a lot of the frameworks. React is obviously a component-oriented architecture. Ember is component-oriented. Sort of all the modern frameworks follow that pattern in general. Like I said, depending on each framework has a different presentation pattern maybe that they use to build their components. So, those are the big similarities. When I worked on the Angular 2 team I did the first implementation of their new router. And I know that that has changed probably quite a bit since I left the team. But that router actually was based on Durandal's router, believe it or not. And Aurelia's router is based on Durandal's router. So, interestingly the routers for both frameworks have a common heritage in Durandal. So, there are some similarities there. Although there are again variations in terms of, they've gone a different direction and we've gone a different direction. Let me think. What are some other similarities? Those are a couple of the big similarities. Obviously with both frameworks we're really focusing on modern JavaScript, so ECMAScript 2015 and beyond and/or TypeScript. Aurelia is written, we build our code with Babel whereas Angular is actually built with TypeScript. But in both cases they both support either direction that you want to go in writing your own code. So, that's a big similarity. I'm trying to think. What are some other similarities? There are a lot of differences and it's all in the details of things. I personally think that they add up enough that there's a compelling reason to choose Aurelia. Obviously I thought there was enough… JOE:  Obviously. ROB:  There was enough or else I wouldn't have built it. But I think that an Angular 2 developer, if they wanted to build something with Aurelia would be able to learn Aurelia very quickly. Conceptually they would see a number of similarities. I think they would find it easier obviously, I think. I think they would probably write less code. I think they'd have a cleaner solution, and on and on. I could say all kinds of things like that. But I think that they would see some common ground there. But you would also see this I think even with Ember. Something like React of course is very different. But Ember and Angular and Aurelia have a very similar way of thinking about the problem. And I think that if you're coming from one of those backgrounds you would see a number of similarities. CHUCK:  I have to ask. You mentioned convention over configuration and I found that in systems that adopt convention over configuration like Rails and Ember, it's very easy if you're working along the… not the conventions, the assumptions that they make when they create the conventions. But when you need to go outside of them, sometimes it's fine and it's easy to work outside of the convention and sometimes the framework gets in the way a little bit. How easy is it to work around the conventions in Aurelia? ROB:  It's pretty easy actually, because the conventions are layered on top of an infrastructure that you can tap directly into. So, the conventions are basically just like shortcuts for doing things which you could always do manually. And so, at any point in time for anything, you can take control and say, “Well, I want to do it this other way.” As an example, when you build a component in Aurelia you build this class. And say you put it in your app.js module and then you'll have your view and the app HTML file. And the framework just knows that those two pieces go together and that's how it works. But you could say, “Well, for component app actually I want to use bob HTML as a view.” And so, you can say, “Well for this instance I want to override the convention and specify that the view that renders this component is over here.” But it actually goes beyond that because in Aurelia we have this notion of view strategy which is that for every component there is a strategy that determines how to render that view. So, rather than even just pointing it at some other template you can actually implement this view strategy class and you can write custom code that can go load the view from anywhere you want, compile the view in any way you want, and it can be all asynchronous and completely deliver this factory if you will that creates views for this component on the fly. So, there's this layered architecture around components. But at the top for the 80% use case, you don't see that. It just follows the simple convention. But you can drop down lower and lower and lower to different levels to take more and more control. Like I said, with Aurelia down to the point of controlling how and where templates are loaded from on a per component basis, having your own parsing and compilation logic if you don't want to use HTML, if you want to use something else, or if you want to imperatively construct a view in code entirely and hand it back. You can do anything you want at that level. But the conventions are all built on top of that. In fact we have, talking about these view strategies for components, we have something called the conventional view strategy. And that's the implementation of view strategy which a component gets if the component does not specify a view strategy. So, that's the kind of technique that's used throughout Aurelia where as it looks for configuration. Basically if it doesn't find it, then it falls back to some convention, which we think is a very reasonable pattern for developing say the 80% use case. But you can always override that with anything you want. I found… CHUCK:  That makes sense. ROB:  Yeah. CHUCK:  Sounds good. ROB:  I found, because I do a lot of consulting, that's basically what my job has been for the last 10 years is been consulting with all sorts of different companies and it's been primarily in frontend engineering. And the thing is that every company, every product, just has something unique about it. And there's something that you didn't plan for explicitly in the way that the conventions work or explicitly in what's out of the box with the framework. They have to do something unique usually. And so, you want to make sure that they can. You don't ever want to box them in so that they hit some hard barrier that they can't pass through, that they have to then go all the way back to, in worst case throughout the framework and rebuild things, or go so low-level that it's as if the framework isn't giving them any benefits at all. So, you have to layer these abstractions very carefully so that developers can take that control when they need to but also think about based off of… in this case based off of a wide range of experiences that I have and that our team have had, we can determine what's 80% of the time roughly, what are people going to need to do? We can make that super, super easy. And that makes things easy to learn again, as well. Just less to learn. They just write simple code and then on an as needed basis they decide to override things or drop down to do crazy things if they want. Speechless, I know. [Laughter] ROB:  You all are about to just… DAVE:  I just… JAMISON:  So… ROB:  run out there and you're going to build something awesome with Aurelia. JAMISON:  I wanted to talk a little bit about web components. You've mentioned Aurelia's integration with web components a little bit. And I was just reading through the docs on your site, too. Is it required to use web components or does it just work well if you want to use them with Aurelia? ROB:  Yeah, so there's a couple of different ways to look at this. First off, by default our templating engine… so remember that… let me back up. Remember that ‘web components’ is actually a collection of specifications. So, there's typically HTML template element, custom element, shadow DOM, and HTML import although HTML import is kind of in parenthesis if you will because it's extremely contentious right now. So, our templating engine by default assumes that you're writing your views using HTML template element. So, it just uses that particular specification directly. And that's just how you do things. You can override that and do different things if you want. Most people won't because there's not really a tremendous need or benefit even from really doing that. So, that's one spec that we use directly in the core. You can also specify on a per component basis that you want a component to render into shadow DOM instead of into the light DOM. And so, we will use that feature of web components if you tell us to. And we have a fallback for it it's not implemented in the browser. And we also enable all the features of shadow DOM even if you just want to create a light DOM based component. So, we do content projection as kind of the main thing that we enable there. JAMISON:  What's content projection? I'm not familiar with that. ROB:  Oh, so for the Angular… DAVE:  [Inaudible] transclusion. ROB:  For the Angular people out there, it's transclusion, basically. But in web component speak it's content projection. So, imagine you have my custom element and my custom element is a name tag. Let's just call it name tag custom element. And when it renders itself it's going to render as this section with a header that says “Hello, my name is,” and then there's going to be at the bottom there's going to be a footer. And then somewhere on the middle it wants to render the person's name but that's not part of the component. When you use my name tag custom element you want to in the content of the HTML place the name and then have that projected into that content slot in the web component's view. So, that's called content projection. It's pretty similar… DAVE:  In React it's 'this dot props dot children' right? Effectively the same concept. ROB:  I would… that probably sounds like it's right. I'm not a React expert so I couldn't tell you for sure. I know that in Angular speak it's transclusion. DAVE:  Yeah. ROB:  In web component speak it's called content projection. So, we support all that even if you're not using shadow DOM. So, we enable you to optionally use it natively if it's present. But even if it's not present we enable it and we kind of model our component design off of shadow DOM so that when you're working with our components you don't have to think about whether it's there or not. And also you're learning these web component specifications while you're learning Aurelia. And that's one of the interesting things we've heard the community remark as actually a positive aspect of Aurelia which is they felt like the hardest part of learning Aurelia is that they had to get up to speed on ECMAScript 2015 and web components. But that's actually a great thing for them long-term, to learn the real native languages of the web. And we really encourage that. So, those are two of the specs that we use internally. We let you optionally use HTML imports. So, our template loading is done completely through the ES 6 module loader. But we let you plug into that to control how templates are loaded. So, if you want to integrate with something like Polymer, we have a lot of people that are… well, not a lot of people. We have a chunk of people that are using Polymer and Aurelia together. You can tell our templating engine to use web component HTML import technology to load its templates. And that works really nicely when integrating with Polymer. So, that's an optional plugin. And then for custom elements we work with any web component. So, you can bring in third-party web components and things just work. And there are some configurations you can do to set up things if a particular element isn't quite working the way you want. You can tell the framework a bit more about it and make it work. But we also support the notion of exporting Aurelia's custom elements as web component custom elements. And that's an optional plugin you can drop in for say somebody that wants to basically do the same thing as what Polymer does. They want to build web components and maybe create this web component library for other people to use but they want to have a framework to help them do it. So, they can drop this plugin in and it will export Aurelia's custom elements as web components spec elements which can then be used inside of any other framework. So, you could then take Aurelia for example and use it inside of a Polymer app. Or you could, assuming Angular 2 is supporting web components, you could use an Aurelia web component inside of an Angular 2 app. So, there's a lot of different angles that we try to integrate and work with web components by specifically using the specs, by modeling things after the specs, and enabling optional usage by integrating with some of the specs to facilitate working with other frameworks, and by having these optional plugins that allow us to export components to these standards as well. Hopefully that makes sense. DAVE:  Cool. JAMISON:  No, that does. I feel like that's one of the better stories of web components that I've heard from a technology perspective. I feel like oftentimes it's just this magic work. It's like the big data of the frontend. [Laughter] JAMISON:  You just say 'web components' and then it must be good. But that makes sense. It sounds like it makes the framework better to use the underlying technologies. ROB:  Trying, we're trying. I'm really big on standards. My personal experience working with native technologies in the past, I've been burned a number of times. So, I've just become by virtue of that, I think I've just really had my eyes open to the goodness of the open web and really trying to play well with specifications and with the broader community and building frameworks and libraries and tools that facilitate and help other developers to work that way. So, that's really important to us. JOE:  Now, I asked this question when you were on Adventures in Angular or at least a version of this but I'd like to talk about it again. We're seeing a large movement I think in the MVC frameworks that are going on today towards this concept of one-way data flows and single-state trees. Can you talk about that in respect with Aurelia and maybe your opinions and thoughts about it? ROB:  Yeah. In short, I think one-directional data flow is awesome. I think that's a good characteristic to have of a system. I don't know that it's something that you can always have 100% of the time for every app you build, especially very complicated apps. But I think it's a good quality and I think it's something to aim for. To that end, Aurelia's data binding system by default is one-directional meaning that data flows from your view model, your JavaScript state into your view and not the other direction with the exception of form elements which usually you need to synchronize with. So those flow in two directions. That's actually part of the convention. So, talking about how conventions work in different ways in Aurelia. Data binding in Aurelia has this notion of conventions which is that data binding is always one-way except form elements which are two-way. That's something you can actually override on a case by case basis making any binding one-way, two-way, or one-time. And you can actually plug in additional behaviors and do all kinds of crazy interesting things. So, Aurelia supports this notion of unidirectional data flow by making its default convention for all normal bindings basically to be one-directional. But it also supports developers practically knowing that there are cases particularly in the local collaboration inside of a component where two-way data binding that's isolated makes a lot of sense and makes a lot of things simpler. But it discourages developers from doing the sort of things that were problematic with data binding systems historically, both in Angular and Ember. Which I think that those teams that, the Angular and the Ember team would both agree with me and would want people to stay away from these types of things. And the types of things people used to do were basically using the binding system as a messaging system, which it should not be used as. So, this is a way… JOE:  Can you go into more detail about that? That's a really interesting thing that you said. It's one of those concepts I'd like to [inaudible]. ROB:  Yeah, so… JOE:  Can it be explained? ROB:  Yeah. A binding system under the covers is working basically on some sort of eventing, quasi-eventing system. When this thing changed, notify this other thing, and then it does something. Now, that's shockingly like a pub/sub model, or an event aggregator, these kinds of patterns. But it's not traceable and it's not visible the way an explicit publish/subscribe architecture would be. You take something like Flux from the React world, and this is a very explicit architecture around actions and messaging and the way that works, and people can see it and understand how the flow of things worked and how the application's supposed to work. Now if you try to, you can actually accomplish the same thing through data binding by simply binding properties to properties. Then when that property changes it triggers something else and changes some other property. And so, it's possible technically to achieve the same thing but it's a disaster architecturally because the visibility of what is happening in the system is just, is completely hidden. There's no way to trace that. There's no way a developer looking at a particular component can see what is actually happening there. They can't see the side effects of things. So, when you use data binding it's not bad inherently in itself but it can be abused in that sort of way that causes tremendous problems. And of course that causes a lot of issues with Angular 1 because when it was used that way, the digest cycle had to keep running over and over and over again. And then that resulted in performance issues as well. But you want to use a data binding system on a very local way. That is to say within a component the view and the view-model are connected and that is the only state synchronization that's happening. You're not binding to binding to binding to binding to pass some message in some weird location way up the tree that nobody could ever discern from looking at your code. If you really have something that is messaging-oriented you want to use a publish/subscribe architecture of some sort, event aggregator or something like Flux if that makes sense for you. But you don't want to try to achieve those same types of things through a binding system. It's just disastrous. And depending on what framework you're doing it with, it could be disastrous in multiple ways. So really, it's about picking the right tool or the right approach for the problem at hand and not trying to solve messaging issues with data binding. So yeah, those things are good for certain contexts and you want to be careful about how you're using them. I've seen some crazy things. JOE:  Great explanation. Great explanation. ROB:  I've seen some really, really crazy things over the years. So [laughs]. DAVE:  Yeah. ROB:  You just, you have to be careful about that. Data binding, I'm a huge fan of data binding. Obviously it's in Aurelia and I've been doing it for over 10 years now across different platforms. So, I find it indispensable for productivity and just eliminating boilerplate. But you have to use it within the set of constraints that it was designed for. If you try and use it for these other things, you're just asking to have a disaster. Use an event aggregator or some sort of publish/subscribe architecture or those other things, absolutely. DAVE:  Should we talk about… JAMISON:  Dave, I know you had. Oh, I know you had a couple other questions, Dave. I want to make sure you got a chance to ask them. DAVE:  Yeah, should we talk about routing? Can you tell us what Aurelia does for that? ROB:  Yeah. So, Aurelia has a router plugin. So, Aurelia actually is very componentized. Even its core is a set of small modules that come together. And the router is an additional plugin you can drop in. It's one that most people use but you don't have to use it. And it's a typical router at the surface level. It tracks the history changes and basically it maps those patterns to modules, ECMAScript 2015 modules. And which basically equate to components in Aurelia. So, what happens is if you match the customer route then you can say that that maps to the customer module. And we'll use the ES6 module loader to grab the customer module. And that exports a class, just the plain class. And that's the behavior and the state for your screen. And so, then we'll load that. We'll load its view by convention usually. And we'll render them and we'll display that in the screen. There are a lot of cool things about Aurelia's router. We have hierarchical routers. So, if that component that you just navigated to, it can have its own router internally which routes relative to the parent. And it will then render components internally inside of it. So, you can have these hierarchies of routers if you want, which is really very useful when you have large-scale applications where you have teams that are working on different parts of an application together but where they want to stay out of each other's turf if you will. So, they want to have their own router that they configure. And so, you can let say a whole team, you can just say, “Here's your router. Configure it. Build your whole, build this whole section of the app as if it's living in isolation.” because in the end it's actually just a component but it's a very rich component that maybe has sub-routers and sub-screens and things. And then you can drop it into the larger app and it will just plug into that root app level router. So, we have these optional hierarchies of routers. We have very explicit state transitions. The router internally has an asynchronous pipeline very much like what you might find in server-side routing. And you can plug steps into it and remove steps from it. And it just controls how the state transitions from screen to screen and you can cancel a navigation and you can asynchronously load data during navigation and do all kinds of interesting stuff. It's really, it's quite powerful. Pretty easy to configure and it follows the same sorts of conventions that the rest of Aurelia does. So, in Aurelia when you're creating an app or a component or a screen that's going to be navigated to or a modal dialog box or a pop-up or any of these kinds of things, it's just a component. It's just a plain class and a view. And the router works with those same primitives. JAMISON:  Does that transition stuff allow you to hook in for animations and things like that as well? ROB:  Absolutely, yeah. So Aurelia, the templating engine has an animation abstraction. And any time it modifies the structure of the DOM we have this internal abstraction called a view slot that represents some location in the DOM where things are going to be added or removed or inserted and so on and so forth. And so, the router when it loads up a component it just talks to this view slot and says, “Alright, add this component into this location.” And the view slot automatically talks to our animator and gives the animator the opportunity to animate this adding or removing or inserting of the component. By default there's no animation but you can plug in different animation libraries that implement our animator interface. And it will just work with everything that manipulates DOM structure. So, we have a CSS animator out of the box that's an optional plugin. We also have a Velocity-based animator that you can drop in. You don't change any of your code anywhere. You just install the plugin and configure the animation. And it works. It works with routing. It works with composition. It works with repeaters that add or remove things from items. The same abstraction is used everywhere. So, you can do animation in that way. JAMISON:  That's cool. I'm really glad to hear that the animation stuff is built into the framework. That seems like that's a thing that a lot of frameworks just didn't think about and then it's a hard problem to solve after the fact. ROB:  It is. That's from some learning with Durandal. With Durandal, we kind of hacked it on a little bit later. And it proved to never be quite ideal. So with Aurelia, we wanted this abstraction to be a core abstraction in the templating engine, in the core. But we wanted to give flexibility to people because there are some amazing animation libraries. We didn't want to be responsible for having to build the most cutting edge amazing animation library out there. We wanted somebody that loved using GreenSock or Velocity or TinyAnimate to just be able to drop it in and have it work seamlessly with our templating engine. So, we had that notion of that animator abstraction as something we learned a lesson from in the past. And we really wanted it in there from the beginning with Aurelia. DAVE:  Outside of routing, does Aurelia have support for animation? ROB:  Yeah, yeah. So, that animator plugs into this view slot abstraction. And anytime anything gets added to the DOM it gets added to a view slot. So, the repeater for example when you repeat over an array and it renders a view for each item in the array, it's pushing items into the view slot. If you have an if binding that conditionally renders or doesn't render something, when it does render it into the DOM it's pushing it into a view slot. When you display a modal dialog it's pushing it into a view slot. When you compose the application root, it's pushing it into a view slot. So, anywhere in the app where there are structural changes that are made to the DOM by any component that goes through a view slot. And the view slot talks to the animator. So, any of those things can be animated. DAVE:  I have kind of some housekeeping questions, like really basic things that maybe have quick answers but I think are interesting to people nonetheless. ROB:  Sure. DAVE:  Can you tell us a little bit about code size? It sounds like it's a plugin architecture so it's not like a kitchen sink all in one, but tell us how much code we'll have to add to our user's download to use Aurelia. ROB:  Yeah. So, this is actually a really fun question because we just had a release today where we knocked about 50 or 60K off of the library size. DAVE:  Nice. ROB:  So, the core of Aurelia now I think is sitting at about 200 and… like I said this just changed today and I haven't gone and bundled and minified everything to get the exact number for the final count as of today's release. I mean literally, like a couple of hours ago. I think it's sitting about 220K minified for the core. And you can add another 40K to that which will include CSS animation and HTTP client in the router. That's roughly the same size as Polymer although it's got more features than Polymer, because Polymer out of the box doesn't come with the router or animation or HTTP. It's about, that makes it about 150 to 200K smaller than Ember and it's about a third of the size of Angular 2. Angular 2 is quite large. So, in terms of modern frameworks the only thing smaller than it is React. And of course React's more of a rendering library and less of an all in one framework if you will. Angular 1 is also smaller but I'm kind of, no offense to anybody, I'm kind of thinking of Angular 1 as a previous generation framework. So, it's among the smallest of the modern full frameworks. It's highly modular. So, there are a lot of things you can pull out and change or add things on, depending on what you want to do. So, we really embraced ECMAScript 2015 modules and thought very carefully about the architecture of the framework as a whole so that we could have these discrete pieces that could evolve independently of the other pieces and be maintained by different developers and just independently versioned and released. And yet collaborate together as part of a larger framework if you will that people could use as a one-stop shop if they want for building apps. DAVE:  Cool. My second nuts and bolts question is what are your minimum supported browser versions? Especially Internet Explorer. ROB:  IE 9, yeah. Usually when people ask versions, they only care about IE 9. [Laughs] DAVE:  Yeah, yeah. So true. CHUCK:  Mmhmm. ROB:  Yeah, so we support IE 9 and above. DAVE:  And what's the minimum version of Opera Mini? ROB:  Oh. DAVE:  I'm just kidding. I'm just kidding. [Laughter] ROB:  Actually we were recently just this week doing some work on Opera. So, we didn't officially support it but we're working on that. JAMISON:  There's one Opera Mini engineer listening with a single tear just running down his cheek. [Laughter] JAMISON:  Like my [inaudible] ROB:  We had a request from somebody that used… JAMISON:  is a joke. [Chuckles] ROB:  We had a request from somebody that used the Pale Moon browser. DAVE:  Oh. ROB:  Which I had never heard of. DAVE:  I've never heard of it. ROB:  Yeah, so he said, “I found a bug.” DAVE:  Yeah. [Laughs] ROB:  [Inaudible]. I said we'll look into it. DAVE:  Oh man, I recently learned about… ROB:  Obviously… DAVE:  Oh, go ahead. ROB:  I was just saying we obviously want to support as much we can, but… DAVE:  Sure. I recently found out our app at work has some bugs with AOL browser, which apparently is a thing. There have been several incarnations of it. JOE:  Wow. DAVE:  Yeah, it's a thing. People still use that. JAMISON:  Maybe it's hipsters using vintage browsers to get back to the roots of the web. [Laughter] JAMISON:  I still use Mosaic… DAVE:  Mosaic. JAMISON:  because that's how it was supposed to be done. DAVE:  That's how our overlords at the University of Illinois wanted it to be. JAMISON:  Yeah. [Laughter] DAVE:  My last question for you is about performance. What kind of work have you put into it and how does it stack up? And I know this is not like an easy question to answer in one sentences, but tell us a little bit about performance culture let's say on the Aurelia team. ROB:  Yeah. CHUCK:  You're supposed to say, “Dave, it's fast.” ROB:  It is. It's awesome. DAVE:  It's faster than your framework. ROB:  It is. [Laughter] ROB:  No, we actually… I come from… I kind of have this belief of not needing to do the optimization work too early. So, in the beginning of Aurelia we focused a lot on getting the right abstractions in place, getting the right developer experience, all those kinds of things. Along the ways making lots of notes about, “Okay, this is some place we can do performance work. Here's a place we can do performance work.” About November of last year is when we actually started the very serious performance work. And believe it or not within about six weeks, maybe less, we had tuned our performance to the degree that if you look at the DBMonster demo for example, this is one of these classic list rendering demos that was put forth to show React performance, we were rendering about twice as fast as React. It renders in that demo at roughly the same speed… it depends on what browser of course and everything else, but I've seen it 10 to 15% faster than Angular 2. I've seen other people say that Angular 2 is faster. Again, it really depends. But they're basically right there, neck and neck for the DBMonster benchmark. That's just an independent benchmark on performance. So basically, Aurelia is right there at the top in terms of performance. Then you've got render time. That's something we're constantly working on. It's probably down to a couple of hundred milliseconds now to render. Most of our rendering, initial render time issues have come from technologies not ours. Actually, we found this insane bug in Edge's promise implementation that if you replaced Edge's promise with Bluebird, it would go from taking 20 seconds to load down to taking 200 milliseconds. JAMISON:  Wow. ROB:  So, we have actually discovered a number of performance issues in other technology which we've gone back to those projects and alerted them and tried to contribute. The Edge team to their credit is of course in development right now fixing that issue. So, it's a very serious known issue with their promise implementation. It's actually a regression from Internet Explorer, believe it or not. A massive regression. But so, we're constantly doing work on time to initial render. And that's really improved quite a lot there as well. So performance-wise, I think we're right there at the top with the best of the best there. DAVE:  And what kind of tools do you give developers who are building apps in Aurelia to diagnose and improve the performance of their own apps? ROB:  Yeah, so we have our own benchmarking tool which is open source. It's the stuff that we use to benchmark all of our, the framework itself. And so, that's actually completely open source. It's actually written with Aurelia. It gives graphs of different performance runs over time, both visually and metric numbers, different things like that. So, we make that available to anyone that wants to use that tool and write their own benchmarks to test things out. We have some Chrome debug tools but those are not really performance-oriented. They're more debug-oriented, inspecting the state of things like that. And we're constantly brainstorming about improving tooling. I think that's something that we hope to do a lot of work on in the next year, really building up some rich tooling around Aurelia. But you can use the same benchmarking stuff that we use. It's just under the Aurelia org on GitHub. It's the benchmark repo. [Chuckles] So, you can totally pull that down and write your own stuff and test your own app. CHUCK:  One other thing that I wanted to ask. It actually came out of a question that Dave posted in the chat. You mentioned that you can write Aurelia in ES 6 or ES 2015. And you can also write it in TypeScript. Can you write it in ES 5? ROB:  You can, actually. We have, if you go to… actually we don't show how to do that in the documentation now that I think about it. But you can. We basically, you would write classes in ES 5 the way you would have written them in ES 5, prototype based constructor function-y stuff. And Aurelia just interprets that the same way. And if you want to use decorators which we use for some things, we have an API that lets you use them in ES 5 that doesn't require any special syntax. So, we've tried to think very carefully about making sure… our optimal experience is really ES next, basically is what I would call it. But we've thought very carefully through all the APIs to make sure that there are decent ways to do them with ECMAScript 5. Though we try and we really strongly encourage people to adopt modern JavaScript. But it is absolutely accounted for. CHUCK:  One last question that I have is, I looked at Aurelia a bit and I don't remember seeing anything in the way of data management. So, reaching out to the server you get JSON back. I know that Ember does some inflation into actual JavaScript objects that do stuff. But Angular doesn't really do that. A lot of these other frameworks don't really do that. Does Aurelia provide something like that? Or do you expect other people to provide that layer? ROB:  For the moment we basically only provide an HTTP client. CHUCK:  Okay. ROB:  And we have tried to help people basically to use some of the other libraries that are out there that are good at this sort of thing and shown them how to get a really nice experience using them with Aurelia. One that's really popular is BreezeJS. And one of our core contributors has used that a whole lot. And he's got some really cool demos out there using Breeze with a traditional Northwind database and Materialize CSS where he builds the whole line of business app and shows how to use it. So we basically, right now what we want to do is have a really strong frontend framework but we want to enable people to bring to the table the libraries that they like best for certain things. Like what's your favorite validation library? What's your favorite data library? What's your favorite animation library? Bring those to the table and we've designed Aurelia to integrate really well with all these things. So, we're not trying to tackle that data problem right now. It's a big problem to solve on its own. And we feel that there's been some good work out there already. And we're trying to point people to that and show them how to use that. CHUCK:  Alright, well I think you ran us all out of questions. ROB:  Awesome. Now, the only thing that's left is for all of you to build Aurelia apps. CHUCK:  [Chuckles] ROB:  And then send them to me. [Laughs] CHUCK:  Alright. Well, let's get to the picks while we're waiting on that. [Laughter] CHUCK:  Joe, do you have some picks for us? JOE:  Sure, I do. So, my first pick is going to be crispy bacon. In between asking questions I was eating a whole batch of crispy bacon and it was delicious. ROB:  Oh, man. JAMISON:  No. What are…? CHUCK:  Does that mean that your second pick is greasy keyboard? [Laughter] JOE:  It's crispy, Chuck. So, it's not greasy. That's the point. JAMISON:  What are the units on a batch? Is a batch like a kilo? Or… [Chuckles] CHUCK:  Slices? JAMISON:  Yeah. JOE:  I measure in micrograms. That's several billion micrograms. [Laughter] JAMISON:  Okay. JOE:  Yes, so… CHUCK:  Inches added to the waist? JOE:  You need to go out right now and eat a batch of crispy bacon. Now you may or may not understand what a batch is. That's up to you to figure it out. But nonetheless, batch of crispy bacon is the assignment here. JAMISON:  A batch is… JOE:  It's delicious. JAMISON:  What you feel in your heart. JOE:  [Chuckles] Right. CHUCK:  Now dear listener, you have two homeworks. You have to write an Aurelia app and you have to get some crispy bacon. JOE:  Crispy bacon, right. Or… ROB:  Best together. JOE:  Secondary, if it's not a batch it can be a plethora. Either one is acceptable. [Chuckles] My second pick is going to be a play, a musical that I saw about a year ago. And I'm going to be seeing it tomorrow night. It's called 'A Gentleman's Guide to Love and Murder'. One of the funniest plays, musicals I've seen. I saw it in Broadway and it's traveling there in Utah at this time. I'm really excited to go see it. Absolutely hilarious. I highly recommend it if you happen to like plays and musicals. It was a great one. And my final pick, this is going to be my favorite pick by far, and that is Jamison Dance's React Conference talk. It was absolutely amazing. I thoroughly enjoyed listening to it. And I was a little bit proud to be from Utah watching Jamison just kill it on stage over at React Conf. He talked about Elm and a justification for why you should learn Elm and the things that are great about Elm. And I think he did an amazing job and in my opinion the best half-hour talk you can see on Elm that is available yet as of this date. So, go watch it. There'll be a link in the show notes. Or go over, you can go to React Conf's site and find Jamison and watch his talk. It was absolutely great. JAMISON:  You hear this? That's the sound of me blushing, Joe. [Laughter] JAMISON:  Thank you. CHUCK:  Alright. Jamison the Elm expert, what are your picks? JAMISON:  Please never call me that again. [Laughter] JAMISON:  I don't want people to get a false impression of how smart I am. My picks are two picks. They're both albums that I found this week. One is called 'Vessel' by Lorn. Lorn is one of my favorite electronic bands. And they put out a new album on Bandcamp a couple of months ago that I just found out about yesterday. So, it's really good. Kind of mellow like dubstep-ish but not dubstep music. And the next pick is an album called 'The Moon Rang like a Bell' by Hundred Waters. And it's very different from Lorn but it's also good. Those are my two picks. It's what I've been listening to this week. CHUCK:  Alright. I've got a couple of picks here. The first one is I just barely put up… if you go to JavaScriptJabber.com you can get the top 10 episodes of the JavaScript Jabber Show. Just put your email address in the form that pops up and you'll get them in your inbox over a couple of weeks. And I'm super excited to have that up. Hopefully it helps some people. If you haven't been listening for long or you're just getting started or if you want to see what was popular with folks who are listening to the show you can go do that. I totally blanked on my other pick. My other pick is Amazon Prime. It's just a super convenient way to get stuff shipped here. And I really like it. Finally the last pick. This is the one I was trying to remember. My wife bought me a Wii U and it's way fun. It has Mario Kart 8 on it which is also way fun. She got me a few other games. I haven't played them yet so I'll probably pick them later. But yeah, Wii U is really awesome. Rob, what are your picks? ROB:  My first pick is going to be a program called Sketch which is a digital design package. It's actually gotten a lot of traction recently. It's especially good for doing web design and app design. It's probably one of the biggest things to start encroaching on Illustrator's territory in the last year or so. And a lot of UI/UX guys really like using it. And it's a cool tool. Second pick is in a similar vein and it's an app called Zeplin. And Zeplin is this online tool that's all about designer and developer collaboration. So, how do you build these amazing application experiences? How do you get developers and designers to work together? And Zeplin is a pretty cool service, software option for that. And then my third pick is going to be Mozilla's Servo. I heard you guys say you had a show related to Rust recently. So, if you haven't checked out Servo, it's really cool. It's basically a parallel browser engine that's written in Rust. And it also has an experimental web renderer that renders everything in hardware on the graphics card. And I saw some amazing demos of performance from this thing. There was a Rust meetup I think where they demoed some of it. And they were showing, basically saying literally every website on the web they could render upwards of at least several hundred frames a second with this renderer. And there was literally nothing that really bogged it down that was happening today. Looking at performance of, graphics performance near or better than native apps. So [chuckles] really exciting stuff written in Rust. And just, it continues to help me stay excited about web technology and where that's going in the future. So, definitely check that out. CHUCK:  Alright. And if people want to go check out Aurelia or find out more about what you're working on, what do they do? ROB:  Aurelia.io is where our project's at. You can also stay up to date on news related to the project at blog.durandal.io. And I'm on Twitter at EisenbergEffect. Those are probably the best places. CHUCK:  Alright. Well, thank you for coming Rob. We'll go ahead and wrap up the show and we'll catch you all next week.