02:08 - Peter Bacon Darwin Introduction

03:48 - Angular 1.5

06:29 - Will people prefer to write in this style going forward?

09:34 - Styling

15:58 - The Component Router

18:33 - Security

23:00 - Angular 1.4 vs 1.5

25:08 - TypeScript

29:33 - Angular 1.5 vs 2.0

40:55 - Styling (Cont’d)

44:34 - ngTouch

49:58 - AngularConnect

Picks

AngularConnect (Ward)
ng-conf (Joe)
Sarah Blasko (Joe)
Survey (Joe)
AngleBrackets Use the code PAPA for $50 discount (John)
The LOOP (Chuck)
Subresource Integrity (Peter)
Hackers: Heroes of the Computer Revolution by Steven Levy (Peter)
Clause 57.10 (Peter)

Special Guest: Peter Bacon Darwin.

 

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

Hey, everybody.

Ward Bell.

Hello.

I'm Charles Max Wood from Devchat.tv. This week we have a special guest and that is Peter Bacon Darwin.

Hi, it's nice to see you or hear from you.

I don't think we've talked to you since AngularConnect. Do you want to give a brief introduction?

Sure. I'm currently the Angular 1 branch of the Angular quartet. I'm the lead developer on that. I've been running that small team of highly capable guys for about 12 months now. And I'm also one of the co-organizers for AngularConnect which is taking up a good part of my time at the moment.

I think what our audience really wants to know, Peter, is what do you have to do with Bacon? [laughter]

Or Darwin?

So, Bacon is all due to my wife. She's the Bacon. She brings home the bacon and she also puts the Bacon into her surname. So, when we decided to get married she decided to keep the Bacon because that was her working name. So, I said "Hey! I'm a new-aged man! I'm going to take your name instead." So we both double-barreled up. [Crosstalk]

And that's what brought in the Darwin, the evolution of things.

Well, that would be [inaudible], wouldn’t it? So I'm the Darwin, she's the Bacon, and we're a highly scientific named family.

Well, I think that's all of the time for we have today. Thank you very much for coming.

It was great. I really enjoyed it. Thank you.

So, I have to ask you – is she Bacon-Darwin as well? Or she Darwin-Bacon?

She's Bacon-Darwin. Apparently, it's some kind of Spanish thing where you add – the female adds the male surname on to the end of her name.

Okay.

And without a hyphen, just to confuse things. So, everyone thinks Bacon is my middle name. And I just like putting my middle name Darwin. [Chuckles]

All right. Well, we did bring you to talk about Angular 1.5.

Cool. Yeah, we've got it out the door. Angular 1.5.0 was released on Friday. Great fun fact and pretty good perception from the community as far as I can see.

So, I guess. What I'm wondering then is what is in the change log so to speak?

Yes. We've got a pretty good blog post that we put up on angularjs.blogspot.com which I think we'll also get to blog.angularjs.org. This list out some of the new stuff to make.

The theme of this 1.5 release from the start – I think we started in May when we started actually in 1.5 – was to bring people closer to Angular 2 so that when you finally move over to Angular 2, then it's not going to be a big jump. So. we've been implementing a few nice features; a big area that we've been looking at is making easier for the create components or directives. We see components, directives the building blocks of Angular 2 applications and we want to encourage people to do the same in Angular 1.

So we've created a new component helper which means you can register component directives on the module with far fewer key strokes. And we set up some pretty good conventions and defaults to get you close to the component without having to touch too much. In order to support that we have to add in a few extra things which actually happen to fit nicely with Angular 2. Since we got this new dollar on in it, life cycle hook which gets called after your control of your component is set fully up and running and has all these bindings in place. This happens to fit nicely in Angular 2 which has the ng [inaudible] hook.

We were just talking yesterday about maybe having a few other hooks in line with the Angular 2 lifecycle process so you can watch this [inaudible] with some more. One of the only things that's really nice, in the old days in order to require the directives with one of your ancestors, you’d have to use a link function and which would then have the controllers injected into it. But now you can actually specify that you want those back to your controllers so, you don't need to have a link function in order to get access to it. And if you're using binding controller, the binding full based on your component and the parent directives will all appear on your controller, ready to be used. I think you can have a much more ergonomic-style of coding going forward.

Is it your feeling that people will prefer to actually to write in this style going forward just because it's an easier way also to write Angular 1 straight up?

I have say from my own experience, it's an absolute joy to use. It's help – since we've released this site, I've been putting up a few samples. I've been – we can talk about this a bit later but I've been working on the component router – or "rooter" as rich people would say – version of the component work for Angular 1, and writing apps using that router and using this component helper of so much easier and cleaner to follow. It's just a really nice way of writing. So, I think people are going to really embraced this and enjoy.

Am I still creating that crazy thing there with scoping – the local scoping and all that jazz that you do in Angular 1? Is that still part of the interface or is that sort of subside and hidden under the covers?

So with the component-helper defined directive, we specified that it has to be an isolated scope by default. And instead of creating a scope property on your directive definition object, which is what you do previously, we have a simple property called bindings. And this is also an object in the same style as the scope object was. These bindings are going to be bound to your controller now by default. So you don't interact with the scope at all in this new way of working with the component directives. So the scope – it’s basically pushed aside, brushed under the carpet. Everything is about the controller now. And if you're looking at Angular 2 in comparing, you can think of the controller being the actual class that you have in Angular 2 which is then decorated as a component. So, you still got that declaration in there and it looks very similar the way it has that equal sign. [crosstalk]

I was wondering if equals and the ats and all that stuff is still there.

It's still there and in fact we even added into it.

Oh my.

We just created a new binding called one-way binding which allows changes from the outside components come in; that if you change the value inside it doesn't propagate that back out. This means that the [inaudible] is slightly less complicated so it can be a performance benefit. But also it encourages you to have the outward-bound flow of information dump through events throughout them to a binding which – where everyone's view is safer and more workable way of writing.

Well, it's also aligned with Angular 2. So, there'll be a more natural translation like I can sort of look at my scope thing and say "Oh well, that's going to become an input in Angular 2. That's going to become an output in Angular 2. That's going to be an attribute assignment so it won't [crosstalk] the first time.

So, we're trying to set up an arrangement in Angular 1 where the mental jump is going to be small as possible. There's always going to be a syntactic jump, but if the mental jump is small then the syntactic jump is pretty straightforward.

Right.

And could possibly be even be automated with a tool.

So, where does one get style advice on this? I wish – is John with us? Not yet.

Not yet.

This should change the way the style people developed there.

In many ways, the component helper was actually driven by the styles. And in fact, I think if you look back in GitHub, it was John Papa's issue where he suggested this helper which triggered a lot of the development.

So, although the component helper is a new thing, it's basically encouraging people to follow the guidelines that John has been promoting in the last couple of years anyway. So, if you were following his guidelines already, then you could repack your code to use component helper without having to really change any of the fundamental code that you've written which makes your code clean to accept.

That being said, people who've read John's guidelines will know that – it mentioned this thing called VM which is the name he suggests that you can use for labelling the controller inside your template. So when you're in your template and you want to access the controller, you need to use some property of the scope.

There was a vote about that, about what the change in name [crosstalk] you stack the vote, didn't you?

Large numbers of people in the community currently use VM. We weren't a hundred percent sure that it was the right term. And to be completely transparent and fair, we asked members of the community to vote and get up.

You rigged the vote?

And we even tweet about it and ask– try to publish it as much as possible, as many people who voted. It was unambiguously in favor of ditching VM and using a new term which is dollar CTRL which obviously is short for control.

Like I said, they rigged the vote. [Laughter]

We need that – we haven't been able to please everyone. There were pretty strong arguments in both directions and people who are very keen on one thing or the other – someone was always going to be unhappy. But I’d like to point out that if your read John's guidelines carefully, it says that you should use a consistent name for your controller such as VM. He does or doesn't say that you have to use VM, he just offers that potential. So we'll see how that turns out. You do have the option of changing the name when you define your components. So hey, if you don't like dollars and CTRL then you call it an Aardvark [inaudible] instead.

Well, I'm well behind the movement to Aardvark.

So, next time a quick strong poll again? Who's unhappy about the change away from VM? No one. Then we go [laughter].

But then no one is complaining over here.

Sadly, we’re unhappy.

Yeah. There you go. Well, I – I'm only writing in Angular 2, I don't think I can vote. [Laughter]

It's a shame that we couldn't – we really would have like to have removed this requirement altogether. Obviously in Angular 2, the context of the template is the component itself. I perfectly like this. But because in Angular 1 we still have got scope very much in the forefront, we couldn't get rid of it altogether. You can go and look it up and see the different options that were there. But I'd like to feel that we're very fair with that decision-making.

Suddenly all the other things that we've cut on – which I am really pleased with that – one of them is multi-slot transclusion. We already talked about this a few months ago because it came out one of the beta release [inaudible] and been kicking around since.

There was actually a talk by Cara Erickson who's just joined the Angular team where she created [inaudible] concept for this. It's a really nice feature where you can now select parts of the transclusion and inject different parts of your template. So previously to this, you have a single transclusion and there was one ng transclude position in your template where it will all appear. But now you can specify that; certain elements of the transclusion will be made available to be transcluded into the different parts of the template.

Now, there's nothing comparable to that in Angular 2 because the equivalent of the transclusion is the ng content. As far as I know, there is only an ng content hack; do you know about any variation on that?

I was not aware of that. I thought that you could select different parts of content – of ng content. You're the man [crosstalk].

Oh no, no.

Writing of the docs so you should know better than me.

Maybe there's an option of – maybe you can have multiple ng content and you can tag them in some way and I just don't know about it. I have a "to-do" item to go find that connection.

Yeah. It's pretty straightforward in Angular 2 to properly implement this. So it may be even be it's not needed as [inaudible] because it's feasible to do it straightforward just using the concepts of Angular 2 in itself, which is quite a common theme in moving from Angular 1 to Angular 2. For instance, in Angular 1 you have all these directives for ngClick and ngShow, whatever. Whereas in Angular 2, you just directly access the docs so we'll see.

Yeah. It's a research to-do for me to go find out.

And if not, and you know [crosstalk] we have a business out there; that's probably an opportunity for poll press. I think it's a great feature.

Yeah.

Especially if you're doing things like typings, couple boxes, and [inaudible] boxes, things like that. It's really nice to be able to transclude real HTML into different sections.

It all makes total sense. If it's not there, it should be there. [Laughter]

And so, I'm hoping I can come on back and report that it was there all along and I just didn't know about it. [Chuckles]

Yes, and it's been a few little bits and pieces. Mattias, who's always keep on creating new and wonderful things, created a new directive called ngAnimateSwap. And this is very simple but it provides a really neat solution to a pretty common use case where you want to take a whole block of content and animate it a way and bring in a new block of content. And that's going to be triggered by change in the doc and in the scope. And at the moment, if you want to animate the entire block thing, you would probably have to use some kind of ngRepeat which only has a single item. And so what's – ngAnimateSwap does it gives you the ability to group all that content into one place and then trigger an ngAnimate transition based on just a single change to the scope. So, I guess the impression that lots of people has been asking is what's happening about the component router. It says [crosstalk].

It says? And yes that's definitely something I need to you're [crosstalk].

Hey, Pete! What's happening with the component router? Especially [crosstalk].

I'm glad you asked!

So– and then if you [crosstalk]

So, what's with the context though? Because this is a particularly useful question with regard to how you're going to bridge Angular 1 apps and Angular 2 apps, and it would be ideal if I had one rather running the whole show. So go ahead; tell us about it.

So the component router is an interesting – from a technical development point of view, it's been an interesting project because Bryan, who’s been working on this quite a few months now, has been given a task of creating one router to rule them all. It has to work in both Angular 1 and Angular 2 with a single code base. And if you consider the complexitive achievement on that, he's done a fantastic job. And we're now at a point where it works for both Angular 1 and Angular 2.

We wanted to release the Angular 1 version of it with Angular 1.5.0, but there were a few issues with synchronization of the Angular 2 repository, internally Google, last week. So we decided to just roll out 1.5.0 as it was and then spend this week getting the router in shape to be released.

As a [inaudible] of your web, Ward and I both in [inaudible] be this week. So I've actually able to spend some time with Bryan; between this week, been able to kick the tires on this thing and get into a position where we're almost ready to release. If I wasn't doing podcast, then it would probably be getting released.

Well then, quite wasting your time.

Yeah, exactly. I'm trying to type in while I'm speaking to you and get it released but [chuckles].

There are two or three pull request which is sitting and waiting to be merged. Once there's a [inaudible], I feel confident that we can actually publish the 1.0 version to NPM; our people can get and start playing with it.

There's definitely features that are not coming yet. There are bound to be some bugs in there but we're going to be able to flush those out so people start playing. I'm also in the process of writing a guide based upon a – I brought a nice guide which a guy called Ward Bell's written. And that will be ready to be published at the doc website at the same time as we release the router. So as soon as we get it all in the polished queue then we can blog about it and you can rush out and get your copy.

That sounds great. Let's see what else we got in here. We've got some security perp.

Over the last year or so, as a group of guys in the community who are specialists in security, and they've been doing some extra work of breaking into Angular and making it a full over and stuff. And they put together this excellent audits and send them through to us. We then we act on them and fix the holes as quickly as we can. Although one of them just seem to sit there waiting to be down with a couple of months. But I'm going to put that in context in a second.

So these guys, including Mary [inaudible] and Garret [inaudible] had done a great job but it's – the work they've done is often hidden in the background. We don't try to advertise the security concerns with Angular, certainly not until we fix them but there's another aspect which is Angular is actually really, really secure. We've had eyes on it by the Google security team; people [inaudible] to tell me. These issues that have been raised over the last few months are actually based around this thing that we called the Sandbox.

Now, the Sandbox is really not a security feature. The Sandbox is designed to prevent from accidentally doing things that are going to break your code. What it does is when you're evaluating on an expression on the scope – so for instance you've got an interpolation expression of binding double [inaudible] and you've got an expression in there, it's possible for you to execute some JavaScript code. But what we want is to prevent you from executing code that could allow people to access information that they shouldn't or to change the way that your browsers behave and effectively triggering the cross-side scripting exploit.

So this Sandbox is in place but as it turns, out even if you can break the Sandbox, the only way that you can actually undermine the security of an Angular app is if you actually allow your users to inject their content into your template before Angular gets a hold of it. So what I mean is, for instance, if you've got a CMS that's generating your page, if you allow your users to write some content which will then get put into an Angular template dynamically via CMS, that is a good flop. So we always recommend – and there's a page in our docs, security page, which explicitly says that "Do not generate your Angular template dynamically if there's no [inaudible] for user and content hidden there." If you don't do that then Angular is rock-solid. So the problem is with the Sandbox – don't actually affect you if you do not generate your templates.

So in some ways, we'd rather not fix these Sandbox exploits and leave them there because by fixing them, we're encouraging people to believe that they can generate content dynamically on the server and then inject it to template which is definitely a no-no. So anyone who's out there doing this, you should go and re-factor your applications immediately. But in any case, we have fixed these exploits and you can now break into the Sandbox using the ones that are published. But it’s only a matter of time before more come along, no doubt.

So my message is really that we've got a very secure framework that's had a lot of security audits. There were awesome guys who created the most amazingly convoluted code in order to try and break into Angular who we really thank and appreciate. You definitely shouldn't dynamically generate your templates from user-generated content – user-provided content.

Right.

Well, I create a lot of wonderfully convoluted code. I don't do it to try and break into anything. So you want to thank me for that, please feel free.

I always – I'm very pleased when people create convoluted code. Provides me with fun and entertainment when I get to come and look at it. But we're all cramped about applications, aren’t we? So given that Angular 1.5 is designed to narrow the semantic app in Angular 1 and Angular 2, I guess there's also an issue – is there now a bigger gap between Angular 1.4 and Angular 1.5?

Yeah. I would want to know what's going to happen if I have an existing app and I just do my usual thing and flip the switch and narrow from 1.4 to 1.5. Can I do that? Everything will still work? Or is there something to worry about?

No.

Which which? No to which? [Laughter]

I would say that as breaking change versions go, 1.4 to 1.5 is pretty minimal. We've got a handful of breaking changes, maybe half a dozen. But if you actually look in the change log, you will see that first of all, most of them do not actually impact on the core at all so they be impact on ngAnimate or [inaudible] or ngRoute. And even within those ones and the core ones, most of the breaking changes of the small core indicators which will unlikely to actually hit in your application. So I would be pretty confident, to be honest, of taking a 1.4 app, switching it to 1.5 and having zero breakages. Well, what you won’t get is probably some performance improvements because we have actually improved our performance from Angular 1.1 to Angular 1.5. More importantly, use certain access toward these new features that we've been talking about earlier. So I would definitely recommend people who run the 1.4 branch to go and have an upgrade to 1.5. It's definitely the most stable, reliable version we've ever produced.

You know I could start writing in this new controller stuff.

You can now stop writing component based applications. The component helper is also streamlined to help write component router applications. So if you're using the component router when it comes up, using the component helper to build your components is even slicker. So you can now put a link to a GitHub that I've been working on with an example application. You can go look at it. It's a beauty to behold if I do say so myself.

So let me ask you a non-prepared question. If I want to use TypeScript with 1.5, am I going to get typing support and all that stuff?

So there's a lot of factors of when you say "use TypeScript". TypeScript is a super set of Java-set script so there's no reason why you can't compile your code as it stands using the TypeScript provided compiler. If you want to start using features of TypeScript which are not in ES 5, such as classes and fat arrows and let and so on and things like these, you can totally start doing that. The only trick bit really of doing that is that things like classes don't get hoisted. So although it's totally impossible to create things like services and controllers as TypeScript classes, it's a little bit irksome and unaesthetic because you end up putting the class declaration above where you would normally put it in a file under a natural component or the service.

Right. So most people go app.module.something your class, and you're saying that I have to move that to the bottom of the file [crosstalk] because I have to [inaudible] first.

In the end, it's like code that just doesn't look quite attractive and this is one of the reasons why the guys at ng-forward created ng – so the ngUpgrade as team created the ng-forward quartet, which we talked about, is AngularConnect. This is one of the two big projects that we kicked to try and help do migrations from Angular 1 to Angular 2 that will be ng upgrade.

So in ng-forward they actually have plastered over all of the Angular 1 API with a whole load of annotations automatic loading of modules based on six dot modules. So you end up writing codes that’s very similar to Angular 2 with classes and decorators and modules, but it all gets converted back into Angular 1 code. So you're writing pure Angular code that superficially looks like Angular 2.

So is ng-forward one of your– one of the official Angular projects? Is it some side show?

So basically, it's written by a community group outside of Angular, but we support it terms – of all the projects that do this kind of thing, this is the one that we think is the one to use. I'm kind of up in the group and we have meetings to discuss the direction it's going.

One of the current developers in there is Michael Ryan who is also working with, I believe, with Rob on the Rx – ngRx project. And it's really good fun to play with, actually. If you want to go TypeScript and you want to stick with Angular 1, I think it's a really nice project to use.

That comes up a lot because we talked people about how to get ready. They can't– they got a big Angular 1 app; they can’t just stop work developing it but they would like to keep it moving forward in a way that positions it for easier transition. One of the things we tell them is not hard to start working with TypeScript and stuff like that. But it sounds like ng-forward, it would be a non-invasive way to push my project forward, staying in Angular 1 with making it more ready when the time comes for me.

Yeah. So I think – there are actually two reasons to use ng forward. One is I don't care about moving to Angular 2 but I like using TypeScript. I like decorators; I like the clarity of code that it gives me. Ng-forward provides you with the ability to write Angular 1 apps without any intention of moving to Angular 2. The other is exactly what you say where you're thinking you might like to move to Angular 2 but you want to wait for it to go for a full release. So you want to stop your production app moving in that direction already so you could start moving your code into that style so the one you did decide to move over, it’s not an easy – semantically not a big jump but syntactically it's pretty close.

There is a concern that maybe you're so close that you start to think that it's Angular 2 and then you get confused yourself. I think there's a really nice sweet spot for this project out there and I recommend people can have a look at it. So yeah, I think there’s a lot of really good stuff to get involved in in Angular 2, Angular 1.5 as well.

Do you [crosstalk]. I'm wondering do you have an idea on how many people are moving to or planning to move to Angular 1.5 as opposed to Angular 2?

I don't have any figures. My hope would be that everyone who uses Angular 1.4 right now will just move to Angular 1.5. It's almost a no brainer in my view. The decision to move to Angular 2 is much more subtle and a tricky one to make at this point in time. In six months’ time, it might be a much more straightforward decision to make.

Right.

But right now, if you're running an Angular app – whether it's in development or in production, I would look at leaving it to 1.5 in the racial tub. If you're thinking of creating something that's going to be ready for production at the end of this year or early next year, I would seriously consider just starting it in Angular 2.

Right. A greenfield app.

Just because it's cool. It's got a load of really nice toys and it's definitely going to be the framework to use in 12 months’ time. And then the shorter term it's going to be ready and people will be collaborating to use it up short. [Laughter]

I like to think of it as more than just a coolness factor but I hear you.

Coolness is only one of the many reasons to use Angular 2. But this one I like to think about – a very much a gut feeling kind of developer. Although the numbers are really important, I do like the aesthetics of Angular 2. It makes me feel happy to code it. And Mishka always said from day 1, he wanted to make developer's lives more fun and more enjoyable. Ten times less code, ten times more fun I think it was the original catch line of Angular.

So one thing that's related to this then is if you want people to move to Angular 1.5 as kind of a

stepping stone to Angular 2 then do you perceive people writing their Angular 1.5 in things like TypeScript and are you encouraging things like that?

Do I encourage it? I don't really have an opinion on whether to use Typescript or not for Angular 1. I think it's totally feasible to use TypeScript. And if you are thinking of moving to Angular 2, there's other aspects of your decision process such as "what are the skill level of my team and the different tool set that we need to use?", "What tools am I actually to be using to do my build processes?" And so in moving to Angular 2, there are going to be a number of changes, not just the code based. And so it might be that you choose to start using TypeScript with Angular 1 purely because you want to start skilling up your team.

Then, if when – I would argue for the immediate benefits that TypeScript brings particularly to a large team trying to work on any kind of JavaScript application.

Yeah. So the actual typing system itself and the [crosstalk].

IDE support and all that stuff just changes the story for the pace of development and particularly the coordination of number of people in the project, period.

That's good. Yes, good point, Ward.

So there’s this connecting. You have any connection with [inaudible].

Hold on. Before we go into that.

Oh, sorry.

I want to chime in just a little bit about Angular 1.5.

Waiting very patiently to go. [Laughter]

Because I never look at the screen here.

A little bit less of a question, I've recently been doing a bunch of work in Angular 1.5. I wrote a little app in Angular 1.5 with AngularFire and messed around with the component function. I've got to say that I was greatly pleased with how it came off and the new component function, I really like it. It's much better to work with and I felt like it really clears up things. The fact that you can use components now is the source of your destination for routes. So you route to your component, essentially. I think this just – it makes a ton of sense and it makes Angular 1 even more solid for me. So I've been very pleased with it and I think it's been absolutely a joy.

Oh, glad that worked out for you. Because as I was saying, in the beginning when I played with it, it actually is a much nicer – a nice way of developing applications. So I'm glad that it's the same for us old people, too.

Yeah. I imagine that you're getting a lot of very positive feedback about this.

Well, we haven’t yet released the full version on Friday. And I think often people will hold off on really starting to play around with things until it's stabilized. So there's not been a huge amount of feedback either way on this stage but I definitely recommend, if people got some views either good or bad, then just please do let me know. We'd love to hear about it.

So, yeah, I was just going to say that components are quite cool but you don't have to use them. So I think the nice thing about Angular 1 is that it's a progressive development. You can move over to Angular 1.5 and start using components in the small part of the app and you don't have to any kind of big bang migration to start getting the benefits of using it.

I think that one of Angular 1's weaknesses was the fact that it’s not definitely clear about controllers and maybe ngInclude versus directives. When do you– how do you sub-modularize your applications? In over time, we've seen John Papa's style guide come out sort of guide us in a particular direction, but even from that stand point, for me it was always slightly ambiguous as to should I put a controller here? Am I routing? I guess the shift of the controller is the destination for all these routes. But then do I break up my page into a whole bunch of little directives?

And it always felt clucky to me because directives themselves are little bit clunky so I only ended up using directives for very specific things, like very reusable components. Whereas, maybe – I think it's just a feel matter, but now with 1.5 if you look at it and take it at the stand point of there are components and they're kind of the default way and you started cutting that way, you very quickly you realize "wow, this is very neat and clean." And I no longer am wasting mental energy deciding should I put a controller in here? Should you ngInclude? Should I make this a directive so I take this bigger piece and chop it up into smaller directives? What should I do? I think it becomes obvious and straightforward. I really like that.

Yeah absolutely. With 1.5, if you started writing a new application, you could write your entire application without ever putting a controller – an ngController or an ngInclude in your app now. And you can even write an entire app with very little touching of the scope objects directly. So these things mean that you have fewer things to think about which I think is what Joe was implying. You can just build your app from components into a much simpler model. You also have to throw in some more – some technical directives in there and build come tricky things. But the back end your application is going to be just these components so you have your fewer mental cycles to focus on.

Yeah. I remember people saying that you should stop writing controllers and stop using ngInclude, and they were writing the big provision sign language, always saying "No, that's a terrible thing to tell people to do because there was no real easy way to write components." But now that you introduce this feature, I would feel more comfortable with somebody saying "As a general rule, we shouldn't be writing any new controller, ngInclude pairs."

Absolutely.

I agree with that completely.

Oh, you're actually clear now. Go ahead, John.

I think the problem we had back in ng 1 before 1.5 was that everybody was like directly [inaudible]. We had shows talking about directives where some people create directives that house directives that house another directive. You end up with like seven layers of directive nested hell. The reason I didn't like that pattern was not just the nesting, but directives has two big flaws in my mind.

Joe pointed the balls out. One was that the DDO was a complete nightmare. Second was if you wanted to route to something, it was harder to route to a directive. Controllers kind of made that easier to deal with but we didn't have a good way to make controllers more component sized. So I feel like in ng 1.5, the best recommendation is – this is for being out for four days – is to say "Hey, if the promise of this holds true, we should be writing components now instead."

Yeah. There's another – I think one other benefit that I just thought of but it was mentioned earlier is the fact that you no longer choose – do you want an isolated scope, an inherited scope, or a shared scope? You don't have that choice anymore; it's taken away from you. It's amazing how great – how many times, in computer science, taking away choices is a huge benefit.

I think of it like going into a restaurant. You've got this massive menu and then you look to the side and you've got a set menu. And it says, you've got three options – just take one menu and take the set menu and it's much easier. You just get on there and enjoy your meal rather than fretting that you could have chosen something that was better. [Chuckles]

Yeah. For people on the west coast, I love Cheesecake Factory. They're one of my favorite restaurants. They got a menu that's like 15 pages and I always choose from three different options. [Laughter]

You know I wrote a generator at work. And I was telling Ward just the other day, my generator originally – the original version had about 28 pumps. And what I learned quickly was that was absolutely wrong thing to do. And then when I wrote that at work, what I [inaudible] up with this public one, the hot towel and the ordinary rope, has zero questions. So that was a much better option.

Well, that’s why a lot of these frameworks work as well. I remember a talk was given by Yehuda Katz about Ruby on Rails and he basically mentioned that the power behind conventional reconfiguration was in the fact that they gave you so many options, rather it made the decision so you didn't have to worry about making them yourself.

Yeah, but I think it's also important to remember that they – that there are options available as well so that you're not trapped in a one-way thing. You're right. The most important thing for the 90% of the cases is that you're going to do the same thing over and over again. You should streamline that for ergonomics.

Think about like then modern cars. A lot of these cars, even the ones that are manual, they have – they're automatics and manuals, right? So what do they do by default? Turn in automatic mode. But when you want to go to manual, maybe some drivers never do it. You can shift over there use the pedal shifter. I think that's a growing need in the software industries and a lot of people who just don't need all these options. And we should just pick the best path for 90% rule and then leave that configuration where you know what, sure power user, here's how you can tweak it up.

Yeah, I think that's a reasonable way to – [crosstalk].

Plus one on that.

Yeah.

So John, now that you're here, one of the questions that we asked was about the style guide and how the new component pattern might affect the style guide. Is there something you're thinking about there?

Well, the number one thing is going to be "Maybe now we use components instead of controllers or directives." That's the first thing I would kind of look at there. But I haven't had the chance to digest all the changes yet. I'm actually trying to upgrade that project internally at where I work where we wrote the whole thing at 1.3 and now we want take that and move to 1.5. And we found one or two things that are not compatible which I'll probably thank Peter on.

But for the overall part, I'm not worried about compatibility as it is. This is a massive application and the code that this team wrote is going to be easy to test and do reduction testing after 1.5. But the concern I have is we wrote about 40 reusable work [inaudible] for example, where NPM components that rely on Angular. I need to support 1.3, 1.4, and 1.5 – how do I – and this is just a rhetorical question for now but how do I make sure that stuff I write while I allow the new people doing 1.5, the stuff that I wrote still works on 1.3. And that's one of the problem I'm having.

It's not just the code, it's also the versions. Like if you saw a new project with 1.5, what version strategy do I put in my packages for a reasonable [inaudible] I wrote? I think there's a – that's giving me a little bit of a pause to upgrade in 1.5 even though I'm really eager to get there. It's how do I support the new people while still supporting the old ones?

So is it your concern that there's this backward compatibility issues?

No, not so much as – let's say you wrote a Bower component, it's the reason Bower to get rid of NPM [inaudible]. I wrote something called like "My logger” at my company. That thing right now says "hey you depend upon Angular 1.3". If I now say you can use 1.4 and 1.5 as well, what version do I put in my package to make sure that people using 1.3 still get 1.3 and people using 1.5 can get 1.5 without there ending up being 20 of those. You know the questions they asked them in Bower and NPM? "Hey would you like to resolve this?" and they would give you 22 options and say – and make you want to shoot yourself in the head.

Can you not do that with some kind of clever [inaudible] expression? You can do like 1.3, or 1.4, or 1.5 or something like that.?

That's kind of where we're going it's more like that. We've tried at least 1.3 or less than 1.6 but that doesn't always work. Because it tries to be clever back and say we'll get the one that’s the minimum value that meets this requirement. And so it’s interesting; versioning is your hard problem [inaudible] I missed my point. [Laughter]

And then it doesn't help that Angular 1 doesn't strictly follow [inaudible] because operator have changed his goal between minor versions where [inaudible] it expects to go between major versions.

Exactly.

What's interesting is that I was talking to the Angular Material team recently and what they do in their libraries is they actually put stuff into the library that works out what version of Angular you're using and then takes advantage of things if you're using a newer version.

I can't remember any specifics right now but we were talking with them about ways of adding more metadata to Angular modules so that you can actually do a look up on the module and find out exactly what’s there.

One thing that's interesting that might be worth talking about because it is a breaking change from 1.4 to 1.5 I just remembered, is that you know you got this module called ngTouch. Now ngTouch was designed to help with running Angular on devices that were touch compatible. But really, all it came down to is a bunch of really nice, white directives and an override on the ngClick directive which helped with this fast click problem.

If people don't know, in order to tell whether you're actually clicking on the screen or tapping and sliding or moving things, then the operating has to – the browser has to wait 300 milliseconds before it says "Yes, that was a click." And that could create such a delay that it upsets users. So there have been various ways around this. And the ngClick I would write tend to do this. But it didn't do that well and there were lots of problems and it was incompatible with other ways of doing it. So there's a live record fastclick.js or something.

And what we’ve decide – and also there were loads of issues coming in with this and we haven't gotten anyone on the team who is actually – has the capacity to really work on these things. And also with notice recently, the browsers are actually implementing strategies of their own to deal with this. For instance, in Chrome I think – possibly and some many of the others. If you specify certain properties in the header of your HTML file to do with the view port, then actually the click delay gets turned off anyway.

So this problem is kind of going away. What we decided to do is to remove the ngClick override from ngTouch altogether. Which leaves you with a very nice reusable module which contains all the swipe stuff but it's not going to break if you want to use something like fastclick or another strategy for dealing with this or not using at all. And so if you're currently using ngTouch and you rely on this ngClick override then you need to be aware of that. We've got a really good write up in the change log of your options and how to move forward from that.

Did you – John, you were saying you want to [inaudible] around this or is that kind of covered what you were worried about? Or do we just–.

Yeah. Sorry, I couldn't get my phone off a mute fast enough. [Laughter] So yeah, I remember in Angular 1.3, one of the promise we had was ngTouch wasn't kind of doing it all for us so we, if I recall correctly, we had to use ngTouch. But then to get rid of the fast-click issue, we had to also put fast-click. So, clicks didn’t wait and delay on phones. And then we also want to include Hammer.js because we all wanted to get all the different touch on there. But then to make that Angular-ready, we also used Angular Hammer. So we literally had to add four libraries just to do touch.

All right.

In Angular 1.3. Is that going to change at all in 1.5? It sounds like it won't actually. As you were saying [crosstalk]. It's going to be pretty modular.

So I can't remember where that – Angular have improvised these swipe directives.

It does.

If it does, then there's no reason to use ngTouch at all anymore. Because ngTouch is only providing some swipe directives now in Angular 1.5. So at least that means you can remove that dependency from your system. Sounds like you're already using fast-click to deal with that problem; in which case, you wouldn't have the [inaudible] of removing ngTouch is going to repair to that either.

Okay, so basically now it's just pull fast-clicking because that separates – and that’s a very small library where you use [crosstalk].

Yeah.

Then use your favorite touch library which – is Hammer still the best one you guys recommend?

I don't actually know of many others that I've really used. Hammer certainly does provide a good range of things. If you really only wanted to have some web support, then you can just use the ngTouch because that's now compatible with things like fast click. We felt that there were people out there doing more focused work on these libraries than we have time to do. And we wanted to focus on the core of Angular instead.

I would definitely recommend researching the up and coming browser support for fastclick natively because I think it could probably remove the problem all together.

That's good to hear. A lot of the app we build, we want them to be mobile available but they're not built for mobile. Meaning you can use them on an iPad, iPhone or an Android but all we really care about is the touch. It's not so much the swipe and the pinch and the zoom and all that. So just having the ability to pull on the libraries – you know what, make clicks actually click and taps do tap without waiting the 300 millisecond delay. I think that's the big thing most people really want. If you're building mobile app, don't go mobile.

Yeah. I think it's definitely worth reading up on that because I think that if you've got an app that doesn't require pinching and zooming, then you can completely remove all the fast clicks stuff now.

Awesome.

And if you look in the change log and go into the ngTouch breaking change section, there's a link through to an article about how the browse support is improving.

We've been talking about this for about an hour. Is there anything else that we really have to cover before we wrap up?

I wanted to ask you about AngularConnect which is you're the leader of it, right?

Well, I'm not the leader but we have – a group of us. There are three developers – Ed, Josh, and I – and we work with a wonderful woman called [inaudible] has a small event, Call For Papers and together we put this conference together last year. And we're very happy to be loving again this year in September.

I wanted to say actually, we've just released – or I've ended up there – Call For Papers. So we're already interested in hearing if people want to give talks. I appreciate that at this point in time, it's still some way off until that conference and there's probably going to be some pretty exciting talks coming out as Angular 2 gets placed into full release and people start using it more and I'm currently in production.

So we can really have a really long period of CFP, but if you've got some interesting ideas for a talk, do get them in now because we really came to stop looking through building up the program.

We've got some – this year, we've decided to challenge ourselves. And one of the ways we wanted to improve the conference from last year was to increase the accessibility of the conference because it's so easy to forget that sometimes it's hard to attend the conference if you, for instance, hard of hearing or hard of sight. Hard of sight? It's not a really valid term.

Visually impaired, I think. [Crosstalk]

Yes, because you know [crosstalk].

Or if you're verbally impaired like we are? [Laughter]

Yeah. [crosstalk]

I've got a bad case of that.

Especially if you're trying to give a speech and you’re verbally impaired, that's pretty valid. So one of the things that we're going to do this year is that we're going to be having a live captioning of all these talks. So we've been talking with a company about how some crazy guy who sits there with one of these stenograph machines in which he types everything that we're all saying in real time and it'll be displayed up on screen. And also, we're hoping, it's going to be added directly to the livestream on YouTube as well.

And Naomi, in the Angular team used to work on those so she's given us some contacts on how we can actually inject that straight to the livestream. So – and I think it's also useful for people who are not native English speakers as well because sometimes, especially if you've got a lot of different accents, it's difficult to keep up with what's going on. So being able to look at the stream of text as well is quite helpful.

So that's one of the areas that we'll going have a closely appearing loop system in place for people who have hard of hearing and wear hearing aids to the system so they can get a much better sound coming through. So these are the kinds of things we're looking at this year to try and make the conference more available to everyone in the community or [inaudible] just the majority of people. So if anyone's got other ideas on how we can improve things – accessibility for conference then please get in touch because we're really keen in trying to get the most accessible conference yet.

So yesterday, you were talking about a different flavor of accessibility. Mainly, you really want to emphasize a feature that you brought out last year that was sort of – people didn't recognize how valuable it was which is the holding the talks with the experts’ kind of thing where people are really talking to each other about a particular topic of interest with one of the conference speakers and really go deep into an area and really talk to each other and share ideas and see the code there on the screen. Maybe I just said what you're going to say, [Crosstalk] But this is a feature of conference that you don't see a lot.

So we – when we devised AngularConnect in the first place, the reason we called it "AngularConnect" was that we felt that what was really important was bringing people together to actually connect, communicate, to get to know each other, to share information.

I’ve just been reading a book which is going to be on my picks later on which mentions this good called the Homebrew Club who are based on California, I believe. These geeks would come together and share all of their cool bits of the kit that they've been building and software that's been rising and help each other out. And I think, sometimes when you have a high profile project with well-known speakers, we become a bit intimidating and you tend to sit there and try to absorb everything but it's hard to actually interact with them. So we want to try and create a space in AngularConnect as a conference itself where everyone can share their information and everyone can get something out of it.

So last year what we did was this thing that we called AMA – Ask Me Anything sessions. And they were extremely successful for the very small number of people we went to it. But I think we didn't do a very good job of advertising and marketing this feature at the conference. So, everyone was focused on going and just went to the talks but the talks were recorded and you can listen to them later on YouTube. What wasn't recorded was the opportunity to go into a room where the very small number of people [inaudible], tens of people have a direct contact with core Angular developers; really senior, experienced developers from all around the industry, from places, from really top companies. And then we really talked things with Angular and computing in general.

And the people who didn't go into those AMA sessions came out saying "What an amazing experience it was" because they were able to ask questions specific to their own issues. They were really able to really engage and pass all ideas of their own to people. We wanted to try and build on that this year and make it even more important.

So one of the things that – we're going to slightly rebrand AMAs, try and give them a bit more importance. So as well as having the two main tracks which you can just still be presentation style. We're going to sort of give the AMAs almost a track feeding of themselves. So we're going to give it the same importance. And one of the things that we're going to do is encourage the speakers not to just have panel Q and A’s but maybe be a bit creative. We’re going to offer a smaller number of slots and we're going to encourage them maybe to do sort of micro-workshops or little hands-on demos or something that's just not about them talking.

And then I guess to some extent this has been inspired also by the fair that we're going to hopefully getting at the ng-conf that's coming up soon. For my upstanding of it, this is also a situation where we're going to try bring together the experts with the people in a much more hands-on, direct contact in a way.

So the idea is that from ng-conf being cross [inaudible] back into AngularConnect. And I'm definitely get– I'm hoping to be there at ng-conf so I'm going to be looking very carefully how it goes and extracting the best bits on that. So when you come to AngularConnect, you can expect really high quality content, to actually really [inaudible].

Engage with us personally, yeah.

People engage with the – the top people but also engage with the other attendees who are all using Angular day-to-day and got stories of their own. And if people come away from AngularConnect saying “I made some new contacts, I found out some new stuff”. Even if they didn't learn anything by actually listening to the presentations, it’s as if they met someone that gave them an idea, then I'll be happy that we've done a good job as a conference provider. So if anyone's got other ideas to do that then do get in touch with us.

I think that's a good segue into picks because my pick is going to be AngularConnect.

Alright, Ward. Go ahead, start us off the picks.

That was my pick. Go to AngularConnect, go to ng-conf if you can get in. Go to AngularConnect, fly to London. It'll be a great time.

Yeah. I'm pretty sure we're all planning to go on ng-conf. I’m hoping to get to AngularConnect this year but watch and see.

Let's just be honest. If you don't already have your tickets to ng-conf, it's probably not going to happen so AngularConnect's the way to go at this point. I know that we always try to put the last few – there's a few tickets there held out for speakers and staff. We always put the last few tickets on sale but nobody should be holding their breaths for something like that. Unless your company is [crosstalk] seriously going to sponsor

You're so mean, Joe. Why don't you let everybody come?

I really, really wish – I mean, it was a really big deal for us just to double the attendance this year because what you don't want is a conference that has 50,000 people. And I think that we were validated in what we did because AngularConnect – What was your attendance this last year, Pete?

We actually had about a thousand attendees.

Yeah.

All including speakers and sponsors and so on.

So, that's like 50% bigger than Angular – than ng-conf was years one and two and I didn't feel like I was lost in a sea, right? So for me, that was really nice to go to AngularConnect and feel still like I have the same – and I think the AMA is really – were a big part of that.

Nice [crosstalk].

So go to– [crosstalk].

So tell me Joe, your ideas for the fair at ng-conf still a little vague about that. Is it going to be a set way that it's going to work or is each speaker or fair provide again to be making out their own thing? How is it going to work?

So, I’ll try not to give away to many details but [crosstalk].

So it's a secret? Okay.

It's not so much of a secret; it's just that a lot of details haven't been solidified. We know what the main feel and coin is. So I can hopefully give clarity on that but we're still lining up like what are all the different things that will be going on. But it's not so much – it's definitely not the whole "the speakers will make up their own things”; it's “we will have exist” – imagine more – it will feel a little bit more like a multitrack conference where there are a bunch of things going on simultaneously and you will have to choose from a lot of different activities what you want to do at a given moment. Some of what then will be entertainment, fun-type related activities and some of them will be – the vast majority of them will be educational. And I think it's definitely an iteration or inspired by the AMAs where we're – the goal here is if there's more people at the conference who want to give them more opportunities to connect with the people that they care about and want to talk to.

So a lot of it will be centered speakers and Angular team being available in places for people to talk to. I can tell you one thing that will be going on is there'll be a room that will be labeled the Tour of Heroes room. The Tour heroes, if nobody knows or for those of you who don't know, are written entirely by John Papa and curated by Ward Bell, our two brilliant Angular 2.0 documentarians here. It's the tutorial for Angular 2. It's kind of a long multistep tutorial that you can go through to teach yourself Angular 2, kind of get your feet wet so to say. And there's a room where people will be able to go with and walk through Tour of Heroes and there will be people in that room who will help you out whenever you get stuck. And John Papa will probably be in that room for at least some of the time.

I don't know if that – I don't know the details about if the room will be open all day long or only for a certain time. We'll have set sessions you show but a certain time and you walk through the Tour of Heroes and a bunch of other people and there's somebody up maybe trying to lead or whatever.

But that for example is one of the things that will be going on.

That's great to hear because I've been trying to figure out how to [inaudible] tutorial and I need somebody to help me. [Laughter]

Awesome.

I'll be in that room. I would like to be there. That sounds like really lots of fun.

Yup.

Yeah, yeah. So, that's the kind of thing; we're going to get experts in rooms where people can go and learn from the experts and there'll be a lot – they'll be different than just the session. Of course, there will be two days a session but we also want to play so people can go and get a little bit different information or information in a different way than we typically see at conferences. And I think that you guys are obviously arriving at the same thing with what you – what you want to do with AMAs.

Well we – yeah. We're definitely keeping an eye out on what's going on at ng-conf because what you guys do will definitely influence our sum. We're still very much in the planning stage but all of the principles that we've been talking about – the philosophy of bringing people together is the driving course behind it. So, yeah, go and check out the website, angularconnect.com.

Alright. Joe, since you've been talking. What are your picks?

Well I obviously want to pick AngularConnect as well because I have – I did go last year and had a great time. And I guess, I'd look for that. I don't know when tickets would go on sale but when they do, jump on them because you can expect it to sell like it did last year and ng-conf tickets are pretty much gone. So unless your company is going to sponsor or you get selected as a speaker then that ship has pretty much sailed. But there is always next year.

I also want to pick an interesting recording artist I just heard, about Sarah Blasko. Been listening to her a little bit. She’s kind of the same band as maybe Adele or sort of melodic [inaudible]. Fun music to listen to.

And finally, I was inspired by our discussion at the beginning of this episode about what are people – you know, the question to Ward or to Pete which was are more people going to upgrade to 1.5 or to 2.0? So I put together a survey monkey survey that I'm going to link in the show notes. That for anybody who’s out there who's got an Angular 1.x that are considering or not considering upgrading it, please head over to the survey and fill it out. I think it'll be cool to get a bunch of responses and see what people are planning on doing with their Angular 1.4, 1.3, 1.whatever apps.

All right. John Papa, what are your picks.

My pick is – I'm going to go with another conference called AngleBrackets. If you guys want to learn about modern web technologies, there's a conference called AngleBrackets and it's in Orlando right on Disney World property actually, in April. And Dan Wahlin and I will be holding two days of workshops with Mr. Ward Bell. So if you want to learn from me, Dan and Ward, come to that show; come to our workshop and it'll be a lot of fun. I'll put a discount code up on the website so you can actually get in there.

Awesome. I'm going to throw out a couple of quick picks. I'm going to be at ng-conf. I'm also planning on to being at NG-NL. By the time this goes out, it'll probably be either over or the day of.

Anyway, I have some little – I like giving stuff away so, I've given stickers away for a long time. I still have stickers to give away. But I ran across these other things that are kind of cool knick knacks to give away. The box got here today so I'm going to be taking a box full of these little knick knacks with me. And what they are are – they're actually – they call them iPocket Loop. And what they are are – they’re a way of wrapping up your earbuds so they don't get tangled up in your pocket. So it's this wheel and it's got slots on one side and it's smooth on the other. It says Adventures in Angular on it.

It has a whole in two ends of the wheel. So you stick the plug to your earbuds into that hole then you wrap it around and then you just put your earbuds into the slot when you ran out of cord. And it keeps it wrapped around there really neatly and fits nicely in your pocket. So, if you want one of those coolio things, you can find me at one of the conferences. I don't imagine I'll give them all away in Amsterdam so I'm sure I'll have some for ng-conf and AngularConnect as I get there. So yeah, that's my pick.

I would also promote a conference but Angular Remote Conference is until September or October. You can check it out, angularremoteconf.com. Call for proposals is open because it opens the second I put the conference page up. Anyway, go check that out as well. And Peter, what are your picks?

Cool. So I got one interesting, tacky one which came up on an issue on Angular last week.

So there's this thing called Subresource Integrity and it's a new browser feature which I think is pretty much agreed between the manufactures. And this is the security feature for people downloading files from CDNs. So the concern is they exploit – if someone managed to hack a CDN, they could basically replace the jQuery.js file or the Angular.js file you're downloading on to your – [inaudible] into every browser that we’re not users with something which is going to be malicious and potentially do nasty things.

So this API or this browser feature allows you to specify a hash [inaudible], like a hash of the file so that when the file gets downloaded from the CDN, the browser checks it against the hash and if it doesn't match up, then it won't run that script. And I think this is a really nice feature and a pretty simple one to implement. And so we're going to adapt to Angular. We're going to basically publish our suite of the distribution of files so you can actually update to your script type to make sure that you’re definitely getting the file you thought you're getting. I'll open a link up to the Mozilla website where there are some information about that. I think it's worth looking up and adding it.

There are two more things; one is a really cool book that my son, who's only nine, bought me for Christmas. I don't know how he chose it; it was completely off his own bat but it's a book called Hackers by Steven Levy. It was written in the 1990s but it’s absolutely fantastic. It's a historical overview of computer hackers from the 1950s through to the 1990s. And he's just extracted all these wonderful anecdotes about these very charismatic and sometimes, idiosyncratic characters who drove forward hacking computers from mainframes through to home computers over the last 30 to 40 years. And I've just been completely transfixed by this book and I recommend everyone read it. It's very inspiring if you’re getting a bit low on your hacker energies to go and read this.

And the last thing is something that actually my wife forwarded to me this morning. She's a lawyer and I don't know if she was reading the service terms for the Amazon web services website or whether it’s one of her colleagues, but I recommend you to get up and read clause 57.10 of the Amazon web services service terms. I think you'll be pleased that you did. I'll put a link up to that as well.

Alright. If people want to find out more about what you're up to, Peter, or find out more about AngularConnect or Angular 1.5, what do they do?

I do have a Twitter account which I’m slowly starting to generate more content from. I've been pretty poor on that over the last few of years. So you can come follow me; it’s @petebd. That's my Twitter handle. You can even just email directly; I’m very accessible so pete@bacondarwin.com. It's always a good place to get me. I promise I'll reply. And follow us on angularconnect.com, get tickets of Angular JS and lots of ways of getting through.

Alright. Thank you all for coming. We'll go ahead and wrap up this show. We'll catch you all next week.