Check out Freelance Remote Conf and React Remote Conf!

 

02:34 - Rob Eisenberg Introduction

03:23 - Aurelia

04:28 - Conventions and Configurations

19:15 - 2015: “The Year of the Framework”

23:46 - Databinding and Unit Directional Data Flow

27:56 - Advice for Framework Developers

32:52 - Tool Fatigue

43:32 - Change Detection

45:22 - Aurelia Interface

Picks

AngularConnect (Joe)
Why Composer John Williams Knows More About Star Wars Than You Do (Joe)
LEGO Star Wars: The Force Awakens Game (Joe)
Angular 1 and AngularFire (Joe)
The Aurelia Docs (Ward)
OhYeah! ONE Bar (Lukas)
Joe Eames: How Functional Reactive Programming (FRP) is Changing the Face of Web Development (Lukas)
The Auralia Website (Lukas)
RushMyPassport (Chuck)
Mogo Portable Seat (Chuck)
The Malazan Book of the Fallen (Rob)
Scholastic Metaphysics: A Contemporary Introduction by Edward Feser (Rob)
Attack on Titan Vol. 2 by Hajime Isayama (Rob)

Special Guest: Rob Eisenberg.

 

Hey, everybody and welcome to Episode 80 of the Adventures in Angular show. This week on our panel we have Joe Eames.

May the force be with you.

Oh please. [Chuckles]

John Papa.

Hey, everybody.

Lukas Reubbelke.

Hello.

May the "farce" be with you.

I just love hearing Joe cackle quietly after saying that [laughs]. I'm Charles Maxwood from Devechat.tv. I think this episode comes up the week of freelance remote conf so if that's your deal go check it out. Of course there's React Remote Conf in May if you're interested in that. We also have a special guest this week and that is Rob Eisenberg.

Hey!

It's good to have you back, Rob. Do you want to quickly introduce yourself? Because it's been awhile.

Yeah! My name is Rob Eisenberg. I am a "front-end" guy. [Laughs] I've been building frameworks and tools; really focused on front-end development for over 10 years now. It's really my passion trying to help developers build clients. You know, that are elegant. Solve the problems they're trying to solve and also have quality code in the process. So help them down that path of success. And that's what I do. I work at a bunch of different libraries, Caliburn, Micro, Durandal; worked a little bit on Angular 2, worked a bit on Angular material. And now my big thing is Aurelia.

That's why we brought you to talk about. So could you give us a one-minute introduction to Aurelia?

Yeah, sure. Aurelia is basically a next generation platform for building apps on any kind of device. Whether it's phone, tablet, desktop. Whether it's in the browser or out of the browser. It's all based on open-web technologies, and it's a component model-driven architecture with favor conventional reconfiguration. The idea is that the framework should work for you. It should handle that 80% of scenario so well it gets out of your way and you don't even know it's there. So, we really try and help developers to write very clean code that – you don't see the framework in the middle of your code. You just write plain JavaScript and we try to have a very clean, easy-to-read HTML syntax. You put those pieces together according to some very reasonable conventions and you can build really amazing apps. So, we're really excited about what we're doing and the last year has really been a cool experience seeing the community come on-board and see what the people have been building.

So, my first major programming experience was in Ruby on Rails which also conforms or uses conventional reconfiguration. I didn't realize just how powerful that was until I started using some of the other frameworks that don't make any decisions for you. In a lot of cases, you can work around the conventions but it's just nice to not have to think about how this is supposed to go together. It's nice to be able to just say "I need this" so that means "this part of it goes here and this part of it goes there and they plug together this way" and that's all the thinking I have to do. That's really exciting for me to see in Aurelia.

Yeah, I love it. And pretty much everything I've done has been based on that. That was highly inspired by Rails. I was never a Rails developer but my back-end experience was .net and we were building web apps, we're building windows app with .net. When Rails was getting popular I was looking at what they were doing and I was saying "Okay, these ideas are really good. How can they be applied in other places?" So, pretty much all the front-end work that I've done in terms of framework and tools and tried to take some of those initial ideas and imagine them in different contexts. You know, from windows development or phone development or single page app development.

One thing that I do hear about conventional reconfiguration is some people are pretty used to being able to set up an app however they want it set up. So, do you ever find that people get into Aurelia and wind up fighting the framework over certain conventions?

There's a couple of key points in building a convention-based system that I learned over the years. One is that you have to have good diagnostics in convention-based systems. So, for example, you can understand what things are going wrong. And the second is that every convention should be overideable. The framework should be designed in such a way where the conventions themselves are implemented in a pluggable way inside the framework. So, the developers can take control either at the – across the entire app or by case by case basis you opt out of those. Because every application you develop is very different.

I do a lot of consulting, I go into a ton of different companies. And there are similarities but every single situation has something unique about it. Otherwise, of course, they wouldn't build the app. They would just pull it off the shelf for some other vendors so people have to do strange things in almost every app they build. And they have some really good internal reasons for doing that. And you have to let them do that. You have to give them a way to do that without providing pain. But you want that 80-90% of scenarios to be super easy and simple where they don't have to think about things. It's really about how you layer and how you design the framework so that people can plug in and override or control these things.

So, Rob. In case some of our audience is not quite clear on what convention over configuration means particularly in the context of an app, maybe we can illustrate it - talk about it a little bit. Kick it off for saying - for example, I went into your website to Getting Started. By the way, you have lovely documentation.

Thank you.

And I say that is the guy who's been doing some recently.

I know! [Chuckles]

I look at the router and I see it just says "users." There's a little directory to it and it says "users." And, I think that's what it was. I can't remember. Now, what does that mean? What does that – and how does Aurelia understand that and how else does convention show up in Aurelia?

Sure. With respect to the router, you specify module idea, and you might say users, but that's pointing to any six module or TypeScript module. And what's going to happen is that the router, when the route pattern mismatched, is going to find that module. And it just knows by convention that whatever you have exported from that module is the component that should be rendered.

That's just a simple example of convention. What we basically tell people is that you write a component per file and this is a very - per module - a very common way the people are developing any ways. So what we're saying is "let's teach the framework about that." You don't have to tell the framework "this exported class is my component." It knows that this module exports the component and that's one of the router of it so I should expect that. That's a simple example based off that router but we go a bit farther with that. Again, we're trying to have a very reasonable convention.

So if you got this user's components - you know, user's JS file or user's html file - that's going to have your component logic, state and behavior. But we want to render that and that's going to need some kind of templated view. So, what we say is you don't need to tell us where to find that or how to find that. If it's in the user's module then the template is in user's html. And so, we just find that automatically and we instantiate that, compile it, all that work. Data bind them together and then that gets handed back to the router and it renders it. So, that's kind of a simple convention for components. It's just a module per component and then an html file with the same name but different extension and it just works.

So, I didn't have to do an import users or an import anything? Just the fact that I have this module idea that is expressed in the kind of syntax I would use in an import statement will cause it to go and get the user's module and find the one true class in there that I need. And, connect all the dots. Is that what you're saying?

Yeah. Basically, with the router - it sets you the way all components work. So, even if you want a custom element in your html, all you have to do is you require it into your view and then the view engine in Aurelia basically says "Okay they require this module. Let me take a look at it and see what's there." And based off the default convention, it’s just the component. And so it says "Okay, well this is a component. And I know how to find custom elements that the component renders and it just makes that happen.

The idea is that you can do a lot of this without ever having to import anything. So, you can build whole screens and whole features of an app. And you actually don't see Aurelia anywhere. You don't see any import statements, you're just writing plain ES 6 classes.

Now practically in the real world, you actually do bring in some imports because you probably want to use some HTP clients to make requests or something like that. But the idea is that it stays out of your way as much as possible. And there's just a couple of very simple conventions that let it do that for you. So you don't have to get bogged down in remembering APIs or importing things or you don't even write that code or even see it in your code. And that just makes things quicker, faster. It's very easy to learn in that sense.

People usually finds it really intuitive because, again, the conventions are really based off practice. You know, it makes sense to have a component per JS file and a separate html template file. And so, we just say, so we're going to teach the framework about this common practice [crosstalk] and let it do that for you.

So, let me interrupt you a little there. I want to just make sure I got you right. So, I'm inside of a component of some sort and normally if we want to use other features we have to import those features and yes to extra TypeScript because we need to go get those things, we can actually refer to those types. So, if you're using Aurelia with TypeScript how do you avoid all those import statements there just with conventions?

So I think it's important to see components into two parts that there are in Aurelia. There's the TypeScript part, in your case, talking about TypeScript, and then there's the html part. So, from the perspective of the TypeScript part, if you actually wanted to use our APIs like the http client, you would input that just like anything else.

Okay.

But, with that component represents an html element and your mark-up, you don't have to tell the framework that that component is an html element. [Crosstalk] You tried to provide any sort of metadata. The convention, basically, are set of characteristics for identifying what exports mean to the framework. It's the thing you export in a custom element is the custom attribute. Does it plug in to our data binding system in some way? You know we said that what we called a value converter.

There's this different types of resources, we call them [crosstalk].

You created a value converter again?

Yeah. [Laughter]

My Silverlight and [inaudible] are coming back.

It's better than the [inaudible] code.

Oh god. Thank you. [Laughter] That's so awesome.

There's basically – in Aurelia views, there's different kinds of resources you can use to construct your view. There's normal html that you use and everything is represented is that but you can have custom elements and custom match gauge and things that plug in to the binding system.

For example, in Angular you have filters, right? So, that's probably the closest thing to a value converter in Aurelia. So these are things you would use in your view, and you require them into your view, and the framework knows based on its conventions - it looks at the modules and looks at where you're exporting and says "Oh this is a custom element", "Oh this is a custom attribute" or "Oh this is a value converter." So you don't have to configure it to know what that is.

Now, you can always take control. You can always provide metadata, change things, or if you want to be exposed to it because you like that way of programming, you can always do that. But if you follow these simple set of conventions you don't have to configure the framework if you will to understand what those things are.

So can we talk just a little bit about that configuration. You know, like the dark side of convention. What is it like to configure versus go with the conventions?

I still wanted you to say "to convent."

[Laughter] to configure instead of convent?

Yeah. It depends on what you want to do so if you want to change things at the app level - across the whole app - like say for example, instead of components Foo JS and Foo HTML being the conventional two parts of a component. You want to keep all your views in a views folder. So you want Foo JS to map the views [inaudible] Foo JS or Foo HTML right?

Well, there is actually a view locator service in the framework. You can resolve it or you can, basically, override a method to write custom code to tell it how to transform a module ID into its View ID. I was going to say that will across the whole framework. So, if you just want to have your own framework-wide convention, you can do that. You can have whatever logic in there you want to have. But you can also - you know on a per component basis - you would import some decorators. So, we used the ES 2016 proposal for decorators to describe components when you want to deviate from the convention. So, you could - you implement the used view decorator and you would just, on the component, you would say "Well, this component uses view" and you give it a relative path. Now, from the module to the view that it should use or an absolute path, too, and then you’ve configured just that one thing you want to change.

And I imagine there's a lot of art to that, to balancing all of the vertigo of convention here. But, maybe we need to go and configure what's the right way not to make it feel like "Ah, crap!" Now they want to do something to different. I've got to dig deep into the depths of the manuals to figure out how exactly to override this default.

Yeah. I mean. But the thing is I came with the convention-based framework. When you adopt the framework you kind of at least tacitly agree that you like this way of doing things. So, you're not going to probably alter them massively. But the framework is designed to have all this plugability points you can override and it's really a matter of "okay, what makes sense for your team? What makes sense for your application?" Are you worried about new developers coming in and knowing Aurelia's convention of being thrown off by your custom conventions sort – maybe that's not a problem?

Is there some unique aspect to your application and where, even politically within the organization, you just have to do things a certain way but you still kind of want to leverage; you want the framework to still work for you. So, it's those types of scenarios that I think that would drive people to customize broadly. I think what we we’re trying to get people to do is just to stay with the conventions as much as possible just like in the Rails world. You get the most bank from your buck from for following this simple set of conventions.

Again, the conventions aren't insane. You know they're basic simple naming conventions and a little bit organizational convention and that's it. There's not a lot of them. Having too many conventions is a problem. I actually know this from experience. And so, basically the trick is, from my perspective, to find the minimal number of conventions that are easy to pick up and learn and remember that provide the maximum number of productivity and benefit. And that reflect real world patterns of usage.

So, how often do you find that you're changing your conventions based on feedback from the community?

So far, I don't think we made any changes in the last year from a perspective of the conventions. [Crosstalk] A lot of what I learned there is from previous frameworks. So, I had a pretty solid idea of kind of what they would be. [Crosstalk]

I know that they're going through Durandal quite a bit with you, Rob, when in the early days and the other friend that you had. There were a lot of conventions in there and there were some that - I remember you entered tweaking just because it made more sense to give more of the control over that. Is that the kind of stuff that you draw much to learn from or are you going in a different direction?

No, absolutely. I mean all that experience with Durandal I learned some. I learned some, probably most of the audience won't know Caliber and Micro, but you and Ward would know that. There was – Caliber and Micro had more conventions that was kind of like good stuff [crosstalk].

Different platforms but kind of a lesson of "Oh, there's probably too many conventions here." you know? And so I learned that kind of thing. I learned - you know - over the last ten years, I've been basically building very similar types of frameworks and worked with a lot of companies and so you kind of just [inaudible] to experiencing going into these different organizations, seeing the challenges, seeing the what worked and what didn’t work over the years. You kind of evolved that understanding of what are reasonable set up conventions or productivity. And that's why I say, I'll just - I'll try to work over all these experiences and I think that in Aurelia that's just my latest understanding of the best way to do these.

I try, with the framework - part of what we're trying to do is to take our entire development team, all of our experiences, and really encode them, literally, into this library. So then, the community can benefit from that experience more broadly and so part of that learning in conventions - that's how it manifests itself.

So, you've obviously evolved since we've spoken and set us already with a lot of different frameworks - building different frameworks. 2015, I think in many ways was like the year of the framework. Even though, we slightly saw a lot of explosion before, this 2015 has been a huge React really hit the ground running, Angular 2 is announced, ELM has become more popular, Cycle JS is announced; Aurelia - I don't know if you had losses in 2015. It was probably earlier, right? Aurelia's making a bunch of headway in 2015. What was that like for you being involved in building a framework? To be putting out your framework at a time where we're seeing a big explosion in the framework world?

Well, actually it's pretty exciting. I mean - that explosion signifies what's happening in the industry. Timing-wise, with the web platform in general, people realizing its power and capability and flexibility and so then there looking into doing the kinds of things that have been done, for example, on desktop clients more historically they're running into the different issues and the challenges and that probably explains the explosion of framework; it's people trying to address all these issues and everyone's got a different experience, coming from a different cultural - I mean, team cultural perspective and all this.

For me, it was exciting to put out Aurelia because I do feel that when it comes to things like convention and configuration there isn't a lot out there. The only other one that I know that it does that is probably Ember. So, for me, I felt that Aurelia was actually a really important from that perspective alone, a really important addition into what was happening in the web space that we represent this development strategy and everything it kind of been learned through Rails and other framework that adopted this that we basically said "Hey, let us imagine this in the context of a modern front-end framework. And let's see what that looks like.

And so, for us it was exciting because while there was a lot of things going on there was nothing quite like Aurelia. We thought that was an important contribution. You know if anything had an important contribution to make in the space [crosstalk.

You know, it's exciting to see because - I mean, I know some people and - that love Ember; love Ember to death! And the thought of using React – Oh you know "I've tried React and I hate and I tried Angular and I hate it. And I tried this other thing and I hate it." Well, that's fine. Then they can go in and they can use Ember and the people who had a bad experience in all of the frameworks I just named, they can try out Aurelia and see if that works for them.

And so by having some terrific options out there it's just really exciting to see. Even though we do kind of hear another framework, it seems that like every month or every week. You know at the same time there are options and if you're used to a certain paradigm or you have a problem that just doesn't fit in with the frameworks, then you switch!

Absolutely! I mean if you think - if you look at the server side just think how many server side frameworks there are. And there's more always coming, and there's a lot of big ones. You know, there's a lot of very widely used server side frameworks. I think that just reflects the diversity and I think having those options is really important because every business is unique. They need to be able to make the choice that makes the most sense based on their constraints. And I certainly understand the JavaScript fatigue maybe because it's been so condensed in the last year too. But I

do think it's actually a good sign of a healthy ecosystem and the evolution of the web and I think it's nice that we have those options to choose from.

Do you feel like the days of the one dominant framework are over?

I hope so. I mean, I think that it's - No, I think that in all honesty it's actually not very healthy for us.

As web developers, when there is only one dominant framework.

Yeah. Think of all of the years of Java and [inaudible] and how they got back and forth and I believe that they pushed each other.

Yeah. I mean, we want the competition, we want the variety, and we want the innovation that comes from that. We also, when it comes to issues of control, we want to make sure that just like in the web and web browser, we want to make sure that no one vendor kind of controls the direction that things are going. So there's issues on the kind of software freedom there and loose ends. I mean there's all kinds of things that I think that benefit their being multiple strong options in the space.

One of the forces that drove or entered the framework world in this last year or so was this idea about unidirectional data flow and I'm curious about your thoughts about that and how it does or doesn't play within Aurelia. And by the way, in barking this kind of question, I want to say that I'm a unidirectional flow - I don't want to be called a skeptic but I thought, I think it's sort of over. I'll just lay it out there that it's not like you have to love unidirectional data flow or you're stupid. I don't feel that that's true. But anyway, that's why it's an open question for me an open – therefore, and open question I put to you.

Sure. I mean I think that if you build a system that has a unidirectional data flow I would say that that's a positive characteristic. I think it deals with issues of simplicity and understanding. If you have that characteristic in your system it'll probably will be easier to understand.

However, I think we also have to be very realistic about applications and I've read some meeting notes - I don't have the link - but I remember that there was a meeting between the Angular 2 team and the React Team where they talk about reactive programming and unidirectional data flow. Interestingly enough, one of the things that came out of that meeting is that the Angular 2 team and the React Team both agreed that in complex applications there will inevitably be cycles. And so, you cannot actually have unidirectional data flows and very complicated applications or, at least, it becomes so difficult to accomplish that the effort is not worth it.

So, I think it's a positive characteristic. I think that what we need to think about is trying to strive for things like that. And this means keeping things encapsulated, thinking about the side effects of various things that you're doing. And, some of these comes in a response to the way that Angular 1 and Ember 1 was used; the way that databinding systems were used. So, often developers would, not that they were guided that way in particular by the office of those frameworks at all, but they were just trying to solve problems. They would often abuse data binding by using it as a messaging system rather than as a system of local synchronization within a particular component which is really what it's supposed used for and so that abuse of the binding system that frankly they probably just most operators didn't know better, that abuse in that case created these crazy kinds of side effects from data binding, and I think that the unidirectional data flow movement is a bit of a response to that. Because looking at a system that uses data binding in that way can be - it can be extremely difficult to understand a system like that.

The trick is understanding what data binding is good at and use it for that thing and do not use it for other things. Data binding is great for a view in its few model to communicate locally with one another. And the bulk of that should still be unidirectional. In other words, in this case, from the model and into the view. But, two-way data binding is extremely useful for basic forms type scenarios. And it actually gets really painful, I think to do some of these user input type things without something like that. I mean, you can always do it, right? But you end up writing a boiler plate code so it makes those scenarios really easy. But what you don't want to use it for is when you really want an event aggregator or publish subscribe mechanism. In that case, you need to call that out architecturally and be very explicit in those kind of things in your architecture. And, you know, with react one of the things that came along with that is Flux.

Flux is really a pub-sub based concept. So what they did is that they called it out and said, you know, as part of our architecture this is what we're telling you to do with respect to cross component communication. And so, that all goes into the unidirectional data flow thing but I think it's a matter of really understanding our tools using them appropriately and calling out the explicit parts of our architecture. You know like that. And that makes the whole system easier to understand.

So we talked a lot about this explosion of frameworks in 2015 and in 2016. And I really liked what you said, Rob, about that it's a good thing to have this vibrant ecosystem with varying opinions and I think that - for instance in the React and, specifically, Redux – I'm a huge fan of that pattern that I could have taken that idea have applied it to my Angular apps. It's all the better because of that.

And so I think that taking kind of these predominant ideas and we're thinking about them and then applying them to different places is a good thing. If you were to articulate, what would be kind of your big idea for Aurelia that you would encourage maybe the other framework developers to kind of look at and adopt in their frameworks? Would it be conventional or configuration? I would love to hear your thoughts on that.

Yeah. I think convention over reconfiguration is a means to the end. Which the end is the thing that I would encourage framework developers to think how to achieve. And that end is to allow developers to write as clean a vanilla JavaScript as possible in their apps. In other words, to minimize framework intrusion.

One of the things that's really cool in Aurelia is that you can really build a lot of screen sync components and you are just riding a plane, you know, ES 2015 class, with- I mean it's just properties, methods; there's nothing exceptional about it.

I would really just encourage framework office to think how can we help developers to write code in this way because that's better for them as developers. It means, their code base is going to be much more long-lived. That the web standards are going to be around longer than our frameworks, and the closer they keep their components in their business models and everything that they're writing to being more vanilla, the less trouble they’ll have migrating between versions of frameworks. The less trouble they have adapting as the web adapts the longer that code base - the longer life that code base will have. And those are all really good qualities especially when you think about the business impact of doing major rewrites or upgrades of this sort of thing. So the more frameworks kind of get out of the way and enable this Vanilla JavaScript programming model, the better it is for developers and businesses that they work for. And that's something we work really, really hard with in Aurelia. I would love to see a lot more frameworks think carefully how they can be able to enable that.

Do you have the opinion - are you a big fan of what React has done where this it kind of said: work trying to put in as little syntax as possible that has anything to do with React. You're just learning to do JavaScript with React, you're not learning React. So much to do React.

Well, the thing with React is it's kind of a view - takes care a lot of that view piece a lot more. And what's interesting about is, using JSX, I kind of see that this is a very intrusive thing because you have a - well you have is, you know, it's a mixture of JavaScript and HTML variant basically together so those components are very, very tied strongly to the framework.

Now if you build - and I'm not a React developer - but I think that you could interpret this the same way you interpret any view language for any framework, in which case Angular 1 and Angular 2, Aurelia, Ember. Each of us has our view language in certain varying time. So, it's not a point against React in my opinion if you use it as a view part of the equation. And if you decouple your components and put your business logic and other things in other places.

I think it is quite possible that you can have a very nice, Vanilla JS type programming model with React if you put that kind of constraint upon yourselves to really think of the React code as being essentially your HTML code, essentially your view. And you were careful to separate those concerns.

I think frameworks like Cycle is really interesting or Cycle - is that right? Yep. I was watching a video the other day and I was really intrigued by the purity of it from a perspective functioning programming model. If there was a - if there was a functioning pro - functional programming equivalent of Aurelia out there it's probably Cycle. It looked super clean and really straightforward and easy to understand and for the most part it was kind of the Vanilla JavaScript that you're writing. So, I just hope that more frameworks would think about that and take that serious consideration and I think it can also depend on how you use the framework. And so, I would also encourage framework authors to try and guide their communities in such a way that they can get the bulk of their code into this Vanilla JS world and not be tied to the particular framework.

One of the things that mention earlier is Tool Fatigue. You kind of eluded to it a little bit earlier and that's definitely a topic that, as a framework creator, you've got to deal with, right? So, how do you combat this? It's become a hot topic at the end of last year and the beginning of this year. How do you combat this growing trend that when JavaScript is becoming way more complex, we're putting a lot more pieces? ES 6 now requires a build because browsers don't support it. ES 2016, we're talking about decorators here, assuming that we are getting farther out there, right?

Yeah.

And there's a lot of - I don't know if backlash is the right word - but there's a lot of discussion about the community about how the tools are in -even in worse shape now than they were years ago because of how many just more complex to do anything. So as a framework author, how do you deal with that?

Yeah. This is a really difficult issue. You know right now we're in this transitional period. It's like ES 2015 is locked but it is not implemented anywhere. It's implemented in pieces for browsers and but we all want to use it because we can clearly see all these benefits. So, we have to bring in the compiler in the mix. The moment that we bring that - if we start using real modules, you know Aurelia 2015 modules, then we got to think of how our modules loaded. We even need a module loader - Oh, we need a bundler like webpack and then the minute we bring those tools into the equation we're doing unit testing - say like a tool like Karma - it has to now load our codes. Then we have to have the proper Karma plug in to work with whatever loadery thing we pick, right? You know, on and on and on. This is-[Crosstalk].

Is loadery a real thing?

Yeah. Loadery thing is a real thing [Crosstalk]

Look it up in the dictionary.

[laughter] I use the loadery thing.

I think this is the most painful part of the process right now. I'm not sure if I have a good solution for it. Our approach has been to try and just hug the standards as much as possible so that over time the platform itself will address these issues. Right now we're in this interim period and it's really painful to - when there's a lot of especially breaking changes coming to these tools and some of the specs are still un-Flux. And you want to do right by you community by trying to point them in the right direction, but, I mean, I'm looking at there, even in the last week in going, there is no right direction. There isn't. Like there is not a direction I can point anyone in. But I feel it's going to be a safe bet even for the next nine months with respect to some of these toolings. So, all we have to do is - you know as framework authors - we are trying to make our best recommendations to people to stick to the standards as close as possible. So we can support this wider variety of tooling options as possible.

We're trying to guide people - you know - With respect to Aurelia, we're trying to work with the toolers. So we're working, we're constantly in conversation with Guy Bedford who works on JSPM and System JS saying "These are the scenarios, these are the things working, not working this is... This is what the upgrade process has been like. Blah, blah." And, also, working with Web Pack people saying "How can we support you guys" and there are several Open source projects out there that are building these plug ins for Babel or things like Karma and Protractor and these different tools - you know - testing tools. And we're trying to contribute back to this projects.

It's a hard place to be in terms of tooling right now. It helps to stick close to the standards and helps to work together just try and collaborate and submit back to the people that are trying to maintain these tools and build these tools.

I really do wish it could be - you know what Aurelia obviously - we try and focus in a lot of simplicity we have these conventions that we need to stay out of your way. And this is the tooling has been the biggest barrier for us to really achieving our vision for simplicity [inaudible] and made its way to complicated. And the fact that you even have to talk about all this stuff in order to help somebody get started, you know, with modern JavaScript development I think it’s a problem.

It will probably work itself out over time. But, in the meantime, we have to deal with it. So collaborations, standard spaces. Also, we're trying to think "Okay, is there something we can build." You know, but I've always been hesitant to like "Man, I don't want to build a module loader. I really don't want to build a package manager." I know that these things are huge projects on their own, so you want to transport the community every other week on back and forth because, I see the pain.

I'm not sure I really have a good answer but we have to keep working together, keep communicating, contributing back, and try and help educate our communities about kind of the status of things, what's going on, what to expect and just help them through that process.

You mentioned earlier that I’d like to push back on a little... because I feel you but I don't feel you at the same time. And that's on JavaScript fatigue. And I think, first, this statement is going to be a question for you; do you have JavaScript fatigue or any type of fatigue where you have to have done a lot of something to get fatigue, you'd think. Like, I have a fatigue of exercising, for example.

You have to exercise to at least to have fatigue one would think, right?

Quite right.

Doing all these JavaScripts that we've all done in the last several years. I think, what happened is that it's not fatigue so much that is people are finally starting to realize how powerful they can build applications with JavaScript and they realizing that "Wow. To do this, in the way that we've done it with, C# or Java over the last two decades, we need a lot more help." the things like Module loader you're talking about, ES 6, or even, ES 2016 and the up and coming, are going to help these things. But it brings about, and the really interesting question for me is... How do you think the average developer out there, and I there's a lot of them who hasn't started with JavaScript yet still. How do you think these average developers are going to keep up and get into our modern developments in the enterprise using these tools?

That is a really good question, and it's really, really hard. When I talk to people about this I try and make parallels to what they know a lot. So, I mean, you and I have .net backgrounds and so I say that Typescript and Babel is kind of like your C# compiler and if you're using Gulp that's kind of like MS build.

These are very Microsoft-y technology I'm talking about for listeners but the first things I try to do is help them understand conceptually they understand everything. At the concept level, they understand all the pieces that are involved but they need to understand. So, now they're - the challenge is "How did they- what did they meant these concepts to? What are the specific technologies?" I think it's very, very for the average developer. I think this is a problem that is calling for a solution. It's something worth thinking a lot about; we’re thinking about building some stuff. You know, what we want - here's what we want. We want a developer to come to our site, click a button maybe, and have a new project, and everything is just set up. You know everything is just ready to go. They don't need to install- [crosstalk].

Hey, Rob. Right now, what do they have to do right now? This isn't unique to Aurelia, I think.

Oh, it's not [crosstalk].

It's Ember, Aurelia, everybody.

Absolutely.

What is it? What does the average developer going to do with it?

The average developers has to go download and install NPM, or – I’m sorry, NodeJS because we're going to be dealing with NPM and those kinds of things. First of all, if they're not used on the JavaScript development their kind of like "What the heck is this thing?" I mean, I don't- I'm a Java guy or a Ruby guy or I'm a .net guy, you know. Some people are a bit of scared, a little bit.

So this is first initial installation they have to do with this thing and it's weird because this thing and in the case of the most front-end framework has nothing to do with the front-end framework itself per se. Aurelia, Angular, Ember – these are all like JavaScript libraries and they run in the browser and so, why am I downloading this NodeJS thing, right? So the first they have to deal with all those issues they got on and they doesn't always go smoothly. And then, they're like "Okay, now I can get started, right?" Well, no. You've got the NPM install this stuff. So, okay NPM. What's that? Why do I have to go through this whole process installing these packages and they get them [inaudible] a bunch of server side packages that have nothing to do with the framework. They might not even pull down the framework yet.

And then, they're like "Okay. I got this. Now, I'm going to write my app and okay, I'm going to write my app. I'll write some code." And then it's like "Oh well, we're going to compile that code so by the way we're going to have configure that Gulp task to use the TypeScript compiler or to use the Babel compiler or else you're going to need to download this special tool like Visual studio or VS code that will automatically compile it. So now, if you- you've got to pick your pain then. It's like do I want to use a specific editor or do I want to deal with Gulp? It won't just work by itself. So you have to go through all of these things before you can actually open up a web browser and see the text Hello World.

I think this is a definite major problem. It's way too much work and things can go wrong at each step of the way. And one of the things that we've struggle with respect to Aurelia and I imagine in Angular 2 is having these issues and probably Ember as well and React and that is that when people started with - they want to get started with your framework, they have to go through all that. Because things can go wrong along the way you really end up getting stuck dealing with support and maintenance on stuff that you're not responsible for. If you hope, you are responsible for it. It's complicated. Yeah, and what we want is that one click of the button and everything is ready to go, I

open the browser and I see it. We've made some progress to that end. I think there's a lot of work to be done on that. But it's not very implicit especially for people new to modern development.

I agree with you.

It is a problem absolutely everywhere and it’s very frustrating. You’ve got this great thing and you’ve got this great way forward that you're hoping you get the developer excited about. But you keep going down these rabbit holes because something wasn't installed the way you thought it was or it was an old version. Yeah, this is a problem everybody has.

I have an Aurelia question for you. I think one of the interesting things about Aurelia is change detection for those out there. Often a lot of time – how does the UI know when to update because you change some values somewhere? How does it know that the value changed time to refresh it?

And Aurelia has more than one answer to that question and maybe you can talk about it.

Yeah. So we have this adaptive model where when you write a binary expression, we look at that expression and, of course, we parse it and that all happens one time, ahead of time. But when you actually bind it to an actual object instance, we use that [inaudible] expression to inspect the objects and its properties. Based off on what you actually handed us, you know what your objects look like or what those properties looks like will pick different strategies for how to observe these different parts of the expression. Sometimes it would be by generating getters and setters that raise events, sometimes it will be through dirty checking. Sometimes it would be through even wire up so if you're trying to observe a property in a dom element, we understand certain properties of dom element that are related to certain events. We hook these observers up.

And from the outside, it’s a simple interface, just this observer interface that the entire view engine understands so we just supply different strategies to how we did that under the hood. And the cool thing is that it's actually pluggable so you can teach the framework about different patterns that people can create objects in. So if you were using Knockout you can actually plug in an adaptor that teaches Aurelia how to observe Knockout observables or you can teach it how to work with backbone models [crosstalk].

Or Breeze, maybe.

Or Breeze! Yeah. We have a really cool plug in for Breeze. So, yeah. It's adaptive in that sense. It tries to fit the best fit for a situation and you can teach it new things.

Can you talk briefly about - is it called Aurelia interface? Let me put it this way. A lot of people try to build these things and they love to have a nice - they're used to having a component suite that's easy to work with. They don't have to bring a designer in and wrangle the CSS and all that stuff directly. And you seem to be doing something about that.

Yeah. Just a bit as a [inaudible] to that on our business model because we're doing what we typically call an open source [inaudible] or an open core model which is that we have open source free open source - Aurelia framework that's extremely capable and does a whole lot of stuff but we're also building some commercial products kind of around it to fill out the ecosystem in different ways, and there's a variety of different things that we're building. One of theme is called Aurelia interface. And it's more than a component library but it's designed to help people build hybrid mobile apps across platforms and so you have a standard set of components you can use. New inputs, and cards, and lists, and ad bars, and these sort of things. And based off what platform you're running on it will take on the characters of that platform.

So when you're in Android it looks and feels like material design, and when you're on iOS it looks and feels like that. But it goes beyond simple skinning and it actually also takes over some of the UX attributes of things. So when you navigate on Android it's different from when you navigate on iOS and the library understands what different animation should be used and all those kinds of pieces.

So Aurelia interface contains all those kind of things and it also contains a bunch of stuff too such as tooling for building hybrid mobile apps making that easier and such that a bunch of stuff to make using common phone plug ins nicer from an ES 2015 perspective. So it's kind of a suite of things for hybrid mobile app but, also, of course you could use it for just browser-based apps because it is a material design-based component model. It's designed to be super affordable for hobbyist developers and small companies. This is not "I'm going to pay you a thousand dollars for a component library type thing." It's a 100 dollar price range we're looking at.

Just to put the business model behind what we're building and to provide value, there's a lot of people that, actually, want to donate and what we said is "well, how much money do people donate? Why don't we actually give them something special for it?" And so we're packing a lot of punch into this library and I'm really excited about how it's coming. In the next few months, I think, you'll be seeing, well [laughs] I don't want to say exactly but there's cool stuff on the horizon.

Sounds great. We're closed to - we're blowing through the time so much as I have a gazillion more questions I think, Chuck, we're going to have to say thanks, Rob!

You're welcome! Thanks for having me.

So, if people want to know more about Aurelia or find out what's coming up or what you just released when you do releases, where do they go?

So, two places. Aurelia.io is the official website and then of course on there is a link to the blog. We usually have new blog content at the slowest rate at least once a month but usually once every one to two weeks. And we can stay up on all kind of things that way.

All right. Well, let's go ahead and get to the picks. Joe, what are your picks?

Ah geez. You have to ask me first, wouldn’t you? Good thing I'm super prepared. All right, so my first pick is going to be AngularConnect. AngularConnect was announced just recently. It's going to be released on September. It's a pretty awesome conven-

Convention, not configuration, yes.

[Laughs] I'm like stuck on the word now. Conference! I did go there last year it was awesome and being a conference organizer, I do have an opinion on these sort of things. So, big fan of Angular Connect. I definitely hope the people - I'm sure the tickets are going go on sale. I hope that people jump on that because London is an awesome place and they did an awesome job.

So, also, this one is specifically for Ward, I read this amazing article called "Why do composer John Williams knows more about Star Wars than you do?" And it's sort of this deep analysis of the music of Star Wars. Somehow the music of Star Wars actually reflects what's going on in Star Wars the movie and the entire saga talking about one particular song. So, it was a great article, really enjoyed it, a big music fan.

I think that's perfect. You know, he's kind of the Dr. Seuss of the musical world so [laughter] things align perfectly. If you like Star Wars, you like John Williams, those things are a package.

[Laughs] I knew that Ward would love it. Great article, absolutely really enjoyed reading it.

Next on the list, and yet another one for Ward, and that is the LEGO Star Wars the Force Awakens game was just announced. The trailer is absolutely hilarious because it mimics the trailer of Star Wars the Force Awakens but mocks it in Lego-style.

And finally, I got one more pick – this is a lot of picks, I recently did a map with Angular 1 and Angularfire. And even though I've done stuff with Angularfire before, this is my first big flush on app. And I'm just going to say, I was reminded on how much I love Angular 1 and Angularfire just made it even much better. But I was just reminded on how awesome Angular 1 is, working on it. So, that'll be my pick - last pick is Angular 1 and Angularfire.

All right. Ward, what are your picks?

Well, I was going to talk about the Legos with Hamlet but somehow I wasn't able to find that.

It's a little too sophisticated for this show anyway. [Laughs]

A little too high, highbrow.

Right.

I'm going to pick going to the Aurelia Docs. It doesn't take a long time to read them they're a pleasure to read and get a feel for what Aurelia's about. And so, I think it's a good read. You should go do it.

I didn't put him up to that. I'm just saying.

[Laughter] No. No.

All right, Lukas. What are your picks?

I have three picks. The first pick is I got sick over the holidays just an issue with my stomach. I'm actually trying to cut down on my sugar intake. And I found this Bar by OhYeah! It's called just ONE - it's the ONE Bar. So, taste as good as a candy bar with that 22 grams of protein and only one gram of sugar.

Oh, wow.

ONE Bar, you're amazing. I've had a couple of different flavors but I wouldn't recommend eating like 12 in a day. But, you know, after work out or something or late at night, it's kind of good to have some sweets without spiking your [inaudible].

Secondly, I want to give a shout-out to Joe Eames. I just found a blog post today on Angular and NGRX and doing it in Redux style. And he was amazing times a thousand honest feedbacks.

Super great feedback, I can't wait to take this laundry list of feedback to improve upon.

Awww.

Update it to be an even better blog post. And my third pick is, since we're talking about aurelia.io, I just want to say that the website itself is phenomenal. So, I tend to have designer proclivities. And, Rob, whoever did your design work in the site, give them a high five. Amazing. It's such a gorgeous website, a really good job on that.

Thanks. I'll let them know. Our company has a cheap design officer and so that design is really important to us.

I'll bump a bit on the equity then. They deserve it. [Laughter]

Awesome. I've got a couple of picks. The first one, I think I mentioned it last week but it turned out really great, rushmypassport.com. If you need a passport in less than a week they can do it for you and it was just really easy and really straightforward to get done.

Another pick that I have, I have this Mogo chair/seat. I don't know what to call it. It's kind of a seat. And what it is is I have a standing desk and on Tuesday and Wednesday I have three different things that I typically stand up for. So, on Tuesday, I do Ruby Rouges and then I do Freelancer Show and then I do JavaScript Jabber. And by the time JavaScript Jabber rolls around, a lot of times, I'm kind of worn out. So I ordered the Mogo seat. It has one leg. You just kind of lean on it. And it takes a load of and it's pretty nice. So that's the pick I'm going to throw out there this week.

Rob, do you have some picks for us?

Yeah. Picks are hard so I'm just basically going to give you a list of the books that I'm reading right now.

So, I just started reading a fantasy series called The Malazon Book of the Fallen. And I'm just in the - there are 10 books - I'm in the first book, only about halfway through and I'm really impressed with it. I have a particularly high bar, probably relatively speaking for literature so I’m really impressed with what I'm reading. I'm really enjoying it. Next book, and this is a very diverse set of books, a book called Scholastic Metaphysics by Edward Feser. I'm a wannabe philosopher so I tend to read a lot of philosophical works. So this is just a book on the scholastics and scholastic philosophy so it's really interesting. And then my final pick is a Manga; Attack on Titan the manga.

And so, have fun with that.

All right so, thanks again for coming, Rob.

You're welcome.

We look forward to having some people try out Aurelia and tell us what they think.

Absolutely. Love to hear from them.

All right. We'll go and wrap up and we'll catch you all this week.