035 AiA The Current State of Angular with Brad Green, Igor Minar, and Miško Hevery

CHUCK: Alright, so what it says on the calendar is, “The Current State of Angular.” MIŠKO: California. [Laughter][Does your team need to master AngularJS? Oasis Digital offers Angular Boot Camp, a three-day, in-person workshop class for individuals or teams. Bring us to your site or send developers to ours -- AngularBootCamp.com.]**[This episode is sponsored by Wijmo 5, a brand new generation of JavaScript Controls. A pretty amazing line of HTML5 and JavaScript products for enterprise application development, Wijmo 5 leverages ECMAScript 5 and each control ships with AngularJS directives. Check out the faster, lighter and more mobile Wijmo 5.] **CHUCK: Hey, everybody and welcome to episode 35 of the Adventures in Angular Podcast. This week on our panel, we have Joe Eames. JOE: Hey, everybody! CHUCK: Lukas Reubbelke. LUKAS: Hello! CHUCK: I'm Charles Max Wood from devchat.tv, and we've got a couple of special guests. We've got Brad Green. BRAD: Hi! CHUCK: Misko Hevery. MIŠKO: Hello! CHUCK: And Igor Minar. IGOR: Hey, guys! CHUCK: So this week, we're going to talk a little bit more about the current state of things in AngularJS -- or Angular. Which is the more official, with or without the “JS?” IGOR: We actually try to drop the “JS.” So while we started with AngularJS in the last couple of months – probably more than a year, actually now -- we've been just preferring “Angular.” And you can blame me for this because it just drives me nuts when people style Angular as “Angular dot JS” or any other crazy variants of AngularJS. So we just decided to make it simpler and drop the “JS” and just call it Angular. We were originally a little worried about people being able to find us, but apparently, we've replaced the physics form of “Angular” as the number one search result. So if you just type “Angular” in a browser, you can [inaudible]. CHUCK: Very nice. Now I get to write an Angular.rb. BRAD: [Chuckles] LUKAS: Now I have to change the title of my book. Thanks a lot, guys. [Laughter] CHUCK: “Nooo, don't print it yet!” JOE: [Chuckles] LUKAS: I need to print it before it gets official. CHUCK: So there were a lot of announcements at ng-Conf. And we’ve kind of talked through some of them on the live show last week, but I'm kind of curious to know, from you guys, like which announcements did you feel like were the most important or impactful? BRAD: I'm glad you asked. We recently put a blog post up on the view that we thought was most impactful. We can walk through that today, or we go on specific items -- whichever you think is better. JOE: I would love to walk through it. LUKAS: 3, 2, 1… go. CHUCK: [Laughs] BRAD: So, a couple of things: the setup is that Angular 2.0 is in Alpha. It's extremely fast. It's a lot easier to learn, and we're going to make it so that you can mix and match it with your Angular 1.0 apps, so that you can migrate a little bit at a time. We've been expecting heavily in the Angular 1.0 branch. And we've almost got a release candidate zero for Angular 1.4, which will include some performance improvements and then a bunch of other big feature bits like the new router that we're sharing between Angular 1.0 and Angular 2.0. A new i18n facility that we think is amazing. If you ever work on i18n, there's a lot of problems to solve there. IGOR: Internationalization. BRAD: Internationalization. Sorry. Thanks. And that was also shared between Angular 1.0 and Angular 2.0. And so the good news is these things started to pave the way for writing code directly in Angular 2.0. Because you’ll be familiar with the API, and you'll be actually writing very similar code [inaudible]. So following that, we're going to be working on 1.5, and we'll take community input as to where we should go with it. We have set a theme for it though which is to make migration to Angular 2.0 simple and easy. The other big news from the conference was our partnership with the TypeScript guys. And we had Jonathan from the TypeScript on stage, and we announced that we were going to merge all of our AtScript extensions to JavaScript development with TypeScript. We were able to do this because they had actually implemented all of the features that we had done in AtScript. They have a wonderful toolchain, and they are just good guys to work with. So we're excited about moving it forward. And from here, we're going to be working with them to continue to improve the toolchain and add features. But also work a lot with a larger group of partners on deriving these new things into the JavaScript standard through the TC39 process. CHUCK: Cool. JOE: So what do you feel your involvement is going to be in driving this through the TC39 process? IGOR: This part that we care the most about moving the annotations forward, because that’s one of the areas that lack of forward progress. So we're committed to getting the metadata and annotations or decorators or something in between to TC39 and get it to the hands of developers. The typebar of AtScript or TypeScript, we feel like the guys from V8 and TypeScript helped us produce to do this. We're happy to consult with them and give them feedback in that area. In that area, the piece that we care a lot about is [?] type checking which is something that TypeScript doesn’t have yet, and we're working on and TypeScript. MIŠKO : So speaking of annotations, we're actually very interested in having more partners who want to both implemented in transpilers and who wanna bring their support. We’ve had a good partnership on this with Yehuda Katz from Ember, and also Rob Eisenberg of Aurelia. And we were looking for more folks who were interested in both using them in their frameworks and then supporting them and bringing them to the browsers [inaudible]. JOE: Could you explain a little bit about Annotations and the strength of them -- why you guys are really pushing forward with this? IGOR: For a really long time, Angular has been trying to use annotations in our APIs because we feel like having the ability to describe code through meta-data is very powerful. It allows you to create a piece of code that can be plot into a framework, and then the framework that can declare it to understand what that piece of code is trying to do and it falls into the whole framework. And if you look at Angular 1.0 codebase, you'll see that we already tried to do this through the [array?] notation for dependency injection. And even our current directive API is very declarative and kind of looks like one giant annotation if you squint hard enough. So this is something we saw in Angular, but then when with look outside of Angular, we saw that this is not just Angular-specific problem. Like, I was looking at React and I was just thinking, “Hey, they are actually trying to do something that annotations will be a better fit for. Like, they have this API and they are working around the language, trying to describe what this class is all about.” And there are other examples in JavaScript. We also saw that annotations are really powerful outside of JavaScript. So there's a lot of prior knowledge. And we can see that once a feature like this is added to a programming language, it enables new kind of API or makes existing APIs much more easier to read. And this is why I think that having annotations in JavaScript would be very much beneficial -- not just to Angular, but to broader JavaScript [inaudible]. WARD: It's kind of like bringing reflection to JavaScript as we know it another languages – would you say? IGOR: We already have Reflection. What do you mean? WARD: Well, in the ability to extend it to actually an extensible reflection, in that, it could be used by tooling at static time and also, you can program against those annotations at runtime to do all kinds of things beyond injection and so forth. IGOR: Right. So it's not just about like injection. There are many things you can do with annotations. And we actually have a doc, (if anyone is interested, I can just add it in the podcast notes) where described many of the uses cases already in JavaScript or possibly use cases in JavaScript in the future, but also use cases outside of JavaScript. So we have a pretty good collection of these use cases. And definitely, [inaudible] we are able to interact with these annotations at runtime, because I think that’s what makes them very powerful. WARD: Yeah, what I said that it's not exactly, I mean, you are saying that we already have Reflection, but for example, the type information that maybe you have some type annotations today, they are usually erased in TypeScript at runtime. So you wouldn’t have any information about parameters and so forth unless you had these supplemental things during runtime, right? IGOR: That’s where maybe Miško could expand on this. But before we go there, I just wanna make a clear distinction between metadata annotations and type annotations. For the standardization purposes, we have tried to distinguish between these two, even though to developers, they look very similar and conceptually, they are similar. For the purpose of standardization and just getting it through the whole process, it's easier to deal with this as two separate features. WARD: Fair enough. IGOR: Misko, can you talk runtime, type inference and dealing with types at runtime in TypeScript? So right now, at runtime, type information is erased but there [inaudible] type of information. MIŠKO: Yes. So the way that TypeScript solves this is that when you have -- well, they don't have annotations; they have decorators -- is when a decorator is executed, it gets passed the type information and if the decorator chooses to persist that information, [it's up to the?] decorator. JOE: That was a big statement. [Laughter] IGOR: Other cases where we want to retain type information, the metadata, was type [inaudible] BRAD: So TypeScript only allows you to retain it if you have a decorator [inaudible]. But I think Igor was asking about use cases. We're trying to support like why do we allow these things. MIŠKO: Oh, [inaudible] is metaprogramming, right? There's all kinds of ways that as a framework, you don't know what the developer is going to write but by having the metaprogramming, you can kind of create meta algorithms and the [inaudible] and you plugin the type system at runtime from the developer. BRAD: And do we have [these?] specifically in Angular that we care about? MIŠKO: Well, dependency injection is an example of that -- instantiating directives, building components, assembling them together and using the directive information to control the HTML rendering -- these are all examples. BRAD: Yeah, so all over the places actually. This is how Angular is built and everybody takes advantage. Like I think we've already talked about some of the end developer bits that they'll care about documentations and they want to be able to do develop time versus deploy time aspects of your code. Lots of interesting use cases. JOE: Could we talk a little bit about like the stability of the current state of Angular? I know that there's like… we've seen some syntax at ng-conf and in other places, there was a really cool meet up that happened in Mountain View back in early February. So I'm just curious what you guys feeling is about how much things might change. For example, like the template syntax, how much you think that might change before Angular 2.0 finally releases. Versus the JavaScript the way that you author components, how much that syntax might change. Versus the build system which I think that one is pretty obviously going to change a lot because that’s probably not something you guys have worked on too much yet, as far as putting Angular into a real built up system. But the overall authoring process and that sort of stuff? MIŠKO: So the way the directives are created and used, that has been used for a while in Angular Dart, so I feel like that code is pretty embedded. Obviously, you never know when you come across a use case that totally blows your mind. But it's kind of unlikely. Same thing with the syntax; we've been working on it for over a year, trying to work on different examples. It seems to work well. We don't expect it to have any kind of crazy use case. We discovered it's [inaudible] under our feet, so it's kind of unlikely. It's pretty stable. IGOR: There are a few things that we might add but not change. MIŠKO : Right. Adding is always a possibility; changing is… IGOR : Again, this is Alpha code, so if we start [inaudible] applications that we change stuff, then it's up to [inaudible] doesn’t use it. [Chuckles] JOE: I think there's probably a good example -- the forEach syntax, right? Wasn't that recently changed? BRAD: Yeah, from ! to *? MIŠKO : I wouldn’t call it a syntax, right? The syntax of binding has not changed. What we have changed is the name of the directive. To me, that’s not in a syntax case. BRAD: Well, I think in our demo at the meetup in February, we used for “! forEach” and at ng-conf, we use “* forEach”. MIŠKO: I think he's referring to “forEach” going to “for”. Which one are you referring to? BRAD: Oh, it's a good question. JOE: No, I think it was the ! went to *. I think one of you talked about that. BRAD : Yeah. So the reason we went against the “!” is because if you would say “!if = (expression)”, it kind of look like “not if = (expression)” And so we kind of looked at that and I said, “Well, I'm not sure about that.” JOE: [Chuckles] WARD: Well that’s kind of quite a segue into the whole binding syntax which is actually, that was something may people at first were encountering your plans for for Angular 2.0 that got really freaked out by it. But actually, it was made clear it's really not so much a syntax change as it's a rethinking of the way in which binding… in which you signal what you mean by binding to something. And Misko, I thought that your presentation or keynote about that was something that we should tell our listeners to go check out. But maybe you can summarize what the real change is there so that they'll really wanna go look at that video again because I thought it was a great presentation. MIŠKO: Thank you. So the big changes that we're changing the semantics of what does it mean to bind. In the old system, we're binding to attributes on a DOM and in the new system, we're binding to properties. And it turns out that seemingly, tiny change, the difference between whether one can bind to web components or not. The other change is that we needed to make sure that could escape the binding in a way that the web component couldn’t get a hold of it. And that only meant that you actually escape the key portion of the attribute and not the value portion of the attribute. So we really changed the philosophy of saying, you know, HTML is really just serialization of the DOM and at runtime, the DOM is really about the properties and not about the attributes. And once you kind of internalize this particular point of view, all of the other pieces just kind of naturally fall out. BRAD : Specifically, Ward was probably talking about the unidirection data flow we've taken on for change detection. And what does that mean for forms? WARD: So I certainly wanna get there, but I think that the prior observation that you were just making there, because I can tell you, my first reaction was, “Wow, this is just like some kind of arbitrary shuffling of the shares.” [Laughter] “Come on, I used to be able to ng this and that and now, suddenly you’ve changed all of that?” And it seems to completely unmotivated. And I think that’s what you did, you made really clear. Maybe I should’ve read and understood it. But you made it really clear that this is a semantic change not a syntactic change. That it's about the thing about biding to properties directly of the underlying DOM rather than trying to trick with new which is the key move. And that we'll still be able to do all of the things that we used to be able to do, but we'll be able to do a lot more than without having to dip into the Angular storehouse of like “what directives do they have for us today,” kind of thing. MIŠKO: That’s right. I can’t stress this enough that this has been motivated by web components simplification and was not just a random “let’s change the syntax.” The syntax thing is really a sign that the semantics have changed. IGOR: I think we've definitely are learning how to communicate our intensions. And in many cases, I think we've done a lot on our end. And although this stuff is document in many design docs for over a year before it was even showed to public at ng-europe. The only thing I would like to ask the listeners is that when they see something odd, before they make a conclusion, they should look for motivation. And usually, the motivation of this in our case is very accessible. And I think just understanding why we're doing something rather than what we are doing -- just looking at what we're doing -- would answer lots of questions that help people understand why this stuff matters. BRAD : And to make this easier, we've recently – you’ve probably noticed this -- on the AngularJS.org site, there's now a big, yellow button that links to our Design Docs and Notes. So for folks who were following our weekly meeting notes or our Twitter posts or any of these other things, now, there's one easy place that they can go to look for it. WARD: So now, we've set the… the thing that still got me spooked is how do I… well, there's two-way data binding. And most of us are… not everybody understands what two-way data binding is, but I'll just say at the surface, I don't think any of us absolutely cares about the phrase “two-way data binding”, so much as we care about the ability to work with forms and take user input and bind that into our objects in some fashion or another, in a way that doesn’t require us to do a lot of writing of code or unnatural code. So what have you got for us? MIŠKO: So we have the new form API. And again, let’s talk about the motivations of why we're changing it. So the issue with the old system is that if you wanted to write a unit test, all the information about what fields exists and what are the validators is stored in HTML. And as a result, you can’t really unit test the component or the controller behind that particular component, because without the information of what the form structure is and its validation rules, what exactly are you testing? So this is the primary motivation why we're moving the meta-data about the form from the UI to the imperative code of the JavaScript. And the idea there is you could just instantiate it or you can unit test it, you can write unit tests that says “imagine that I entered a user name into the field. What kind of [?] will I get? Will I get an [?] saying something like you know, ‘this is not an email address’ or something like that.” And the UI should really have nothing but the rendering information. How does the look like as the domain of the UI. How exactly the form behaves and how to validate it and what field exists, etcetera. And really it's the domain of the controller. And so this is kind of the motivation why we are moving it into this thing. It is slightly more robust. And I say “slightly” because for a large form, the benefits greatly outweigh the few more keystrokes that you have to do to get it in there. So that’s basically what’s happening. Now, the way this gets around the problem with two-way data binding is because the controller is aware, or rather knows the full structure of the form. The form can bind to the UI elements at runtime and setup the right listeners, etcetera. Now, what we're basically saying is that the bracket notation or what I like to refer to as the “forward binding” is it gets the data from the model to the UI. But the event notation or parenthesis or on the on dash notation, that's the reverse direction – it gets the data from the UI back to the model. And so the forms control automatically sets up all of the forwarded and backwards bindings for you so that you don't have to do it. You just have to say, “this is a form that’s bound to this form declared imperatively inside of the code.” And so the end result is it should be able to perform just like before, but the benefits are you still have [inaudible] so you can do single digest. And you should be able to have a lot easier time unit testing the same, understanding it's behaviors. IGOR: Let’s talk about observables and how observables can play a big role. MIŠKO: Right. Because the form API is not inside of JavaScript or kind of the structural declaration, not the visible one, you can listen to the changes on having chosen observables as the mechanism by which you can listen on changes inside of the code. So it's a lot more expressive in terms of what is the intent… IGOR: And then for those that are not familiar with Observables, this is a new feature that is being standardized as part of ES7 or ES 2016 (whatever they call it now) and the goal is to be able to create Reactive streams in JavaScript in a standard way, just like we have promises standardized on our API for Reactive streams and the name for that is Observables. The main benefit is once you have abstraction, then you can mix and match streams. You could do all kinds of crazy stuff – joining, forking, do transformation of streams -- all regardless of where the streams are originating from. And for us, one of this origin would be forms. WARD: Is there some place we can go to learn about say, this sort of new way of hooking up the forms and view how it relates to Observables? MIŠKO: Unfortunately, we don't have documentation but we have lots of unit tests where you can see the documentations of. I will just say go check out the source code for now – but that’s a coming soon. IGOR: We'll make some announcements. Maybe on the next Angular meet up here in Mountain View, we'll bring some more attention to that. I would like to return back to the discussion about one-way versus two-way data binding or what exactly two-way data binding is. Because in my experience, when I talked to Angular developers, there's a lot of confusion about what this two-way data binding actually is. And maybe things people think that the double curly -- which they know from Angular 1.0 -- is two-way data binding. And when somebody says, “Oh, the two-way data binding is going away” “They are like, are you taking my double curlies away? How am I going to do anything?” So, let me just clarify what this mysterious two-way data binding is in Angular. So in Angular, we have one-way data binding which is the double curly that you know. And two-way data binding which is ng-model, which is the way to write the forms, there is one more use case where we used two-way data binding, which is binding between two components. So let’s say you have a single model in an application and you have two components, and you want to bind them all into both of these components. And if any of the components change the model from… its internal state, you want the change to propagate back to the model, and from there to propagate to the [inaudible] one. And what we've found in large applications is that this approach just doesn’t scale. It's very hard to understand the reason about the large applications. It just causes more trouble than what it's worth. So we have different strategies to deal with use cases that we usually implemented in this way, but we have no intention of supporting this two-way data binding. WARD: Well, for our audience, let me setup the case where I think that that occurs -- that we run into it all the time. If you’ve ever scheduled a meeting or something like that and you put the start time in, it usually pre-calculates it [inaudible] the time, like half an hour or later, right? So that will be a half hour meeting. And if I move the start time up an hour, then automatically -- from the user’s perspective – the finish time moves a half hour. But I can also change the end time if I want independently, so that’s actually independent control. So that kind of scenario -- and there are varieties of that all the time -- will be able to… that’s certainly a challenge for what you’ve just said, but we'll be able to do it somehow? MIŠKO: So let me kind of rephrase it. One-way data binding is basically you read the expression. Two-way data binding is most of the times, you read the expression --sometimes you write into it. And this is where the problem starts. So in the scenario that you described with the sliders, the way this solves people problem is you say whenever I wanna write to an expression, instead of to just writing into it, I have to go and make sure that I have the first thing that happens. By moving it to the beginning of the whole process rather than just randomly somewhere in the middle of the cycle, I have made it explicit. And by making it explicit, I've made it predictable. And so what you're asking for can certainly be done easily in Angular 2.0. But it's not going to be done through the clever use of double curlies, but it's going to be done by, say, on slider move or on slider selection, go re-compute the other two values. WARD: Okay, I kind of expected that, but I thought maybe somebody would know what we’re talking about in the abstract. It sure will be great when we see some examples – and I know those are coming. MIŠKO: Yes. WARD: So another thing that kind of got me. [inaudible] that you're here to get some of the things that struck me as frictional. When I define a component, I notice that there’s @ something at the top where I described the template. And I have to list the… well, what I would call directives. I'm not sure what they call them. I have to list what they are that will appear in the template in order for them to be found. Is that correct? MIŠKO: Yes. They are still called Directives. There have been some confusion; actually, I've answered your question online just the other day where somebody said, “Directives will replace the components.” And it's not actually true. What we're saying is in Angular 1.x, there’s just directive which have all kinds of different use cases. In Angular 2.0, we have directives but we specifically laid out the three different use cases that exists -- one of them which happens to be component. The other one is the decorator and the last one is the view port. The question is, why do we have to list the [inaudible]… so the first thing is that you don't have to listen to every single one. You can easily group them together into a common set of directives you like to use and just list the one by itself. If you wanted to imagine that you had an Angular 1.x where it's as if you created a one global array with every single directive lists in it, and then you just simply added array into the directives list. The directives list is recursive, which means it can have arrays of arrays -- which can have more arrays -- and we flatten it into a single list. I mean, so you don't have to list every single one. But they are not benefits by listing them; the benefit is that we can really understand and encapsulate and we can limit which set of directives are encoded in a particular template. So you can simply just say “I just want directive a and b and not the required directive that happen to like do some form validation or something like that.” And you can also rename the directive selectors at this point. So if you happen to wanna import two separate directives that have the same selector [inaudible] for you, you also have the ability to rename one of the selectors. So you do have to import. You can group them into supersets, so you don't have to list every single one. And there are some very nice benefits you get out of it. IGOR: I guess the question Ward is trying to ask us is, why do we have to do it in JavaScript when the place where we actually use these directives is in HTML or the template? WARD: Bingo. MIŠKO: Yes, that’s also a very interesting question. So it would feel kind of natural to do the import inside of the HTML. The trouble is, inside of the HTML, you can only write strings. And if you can only write strings, then you have to have some mechanism of matching the string name to a reference inside of the imperative code. And this is where the problem comes in is that there is no easy way of matching the string to the imperative reference in a way that isn’t global, that can be renamed, that is consistent with the minifiers and treeshakers and so on. IGOR: So really, it boils down to we just don't know how to do it while retaining all the benefits of ES6 module system. So I think the friction really comes from how do you integrate HTML templating with ES6 module system? If you look… there was an [inaudible] to add import system into HTML through HTML import, which Polymer, also there’s another library using it, but there's also one push back against that spec because it doesn’t solve one [inaudible] problem which is how do you unify the HTML imports with ES6 imports or ECMAScript imports and module systems? That is just not solved yet. I know that there's some work being done and many, many smart people looking into this to figure out how to unite these two worlds. For now, we decided we'll just take the easy path and declare the imports in JavaScript. Personally, this bothers me a lot. And I have some ideas about how we can work around this using tooling where the tooling would allow you to specify the imports in HTML. But under the hood, it will be converted into JavaScript code, so we would have both the nice declarative syntax, but still have all the benefits that ECMAScript 6 gives us. But this work is still isn’t done. We're hoping that this will still improve but we're also trying to push the [inaudible] forward in this area because it's a bigger problem that’s not something specific to Angular. WARD: Well, I’d have to agree with you, Igor, about feeling uncomfortable about it and looking for something. But one thing that occurs to me is that I'm not sure that everybody was clear on why we've called it necessary. Why we couldn’t just wait until template appear and sort of analyses it as we go, which is pretty much what happens today, right? I mean, you bring in a template and then Angular 1.0 [inaudible] and figures out what's there. And so naming collisions aside -- which we've been living without that being much of a problem anyway -- what's the motivation for wanting to declare these things [inaudible]? MIŠKO: So in Angular 1.0, you have to list every single directive inside of your module ahead of time. So, it's as if you have a global list of directives. What we're doing with 2.0 is we're just moving that global list to a component-specific list. WARD: Right. That’s the thing that seems weird. In other words, if you came to us and said, “Yeah, you still have to register them somewhere, so we know to load them,” I would have gotten that. But what feels weird is that the controller -- the component -- that has any specific knowledge of the view, that’s the thing that just doesn’t feel right for me. So why would I suddenly take an interest in doing that? MIŠKO: So it's not the component. The component has a template annotation. It's the template annotation that knows about this. And it's not like the component can really get a hold of the component annotation at runtime. I mean, the system can, but not the component itself. And keep in mind like you could have multiple templates per component, depending on device or localization and so on. WARD: Well, that's a shocker. [Chuckles] So we're looking forward to learning more about all this. But that’s good too because not everybody is saying “I wanna lock controller to a particular view.” Again, it's usually one to one, but not always. IGOR: Well, the [inaudible] with that are primarily is if you're building UIs that scales across multiple viewport sizes, so let’s say you want the specific templates for a mobile device, then other template for a large desktop application, you achieve this through CSS. Maybe on mobile, you just want a completely different UI, then this is the use case where you want multiple templates. MISKO : And if you have a different UI on the mobile, it could very well be that there's a difference in the components, so why should you be loading these components into your application, right? You should not be taking valuable memory space anyhow. So this mechanism allows you to just say only “load these components if this template is up and running.” JOE: Very interesting. It definitely feels a lot different but it's an interesting way to tackle that problem. IGOR: I think if you think about it more, you'll realize that this is very similar to what we're doing with JavaScript. [inaudible] working with the JavaScript community. We realized that at some point, just using globals for streaming symbols and variables just breaks down. And that’s why we realize that we actually need a module system in JavaScript. These imports in templates in Angular are just analog to that but translates it to Angular and templates. This is actually one of the issues that I have with the current web components specifications where if you import a web component, that import is global and you can import it from wherever. And if you do it in the right way, then the component will just work. And if you don't do it or if you have a collision, then you don't really know where the collision is coming from. And it's just the whole system is for me it's harder to understand. Whereas if the imports or the scope were explicit, I will feel more comfortable. JOE: So one of the things that obviously is going to happen is people are going to be authoring a template at some point, add in a new directive into the template, refresh and it doesn’t work. And I think there's a couple of things in Angular that I identify with this. It's that one thing that I keep forgetting to do. For example, snake case versus camel case and directive names, right? IGOR: So we're building tooling that will just tell you that, “Hey, there's this suspicious attribute that’s not HTML. It looks suspicious. You probably made a mistake. You might want go back and fix it.” MISKO: So it's not just tooling but it's at runtime. We can look at for example property binding and we can do “has property of” and see like, “Okay, you seem to be binding to a property that doesn’t exist. You're probably doing something wrong.” We can also look at extra attributes which will recognize and say “this attribute doesn’t exist in HTML, why are you putting it over here? You probably forgot something.” And so the mass majority of cases, I believe we can now do a proper runtime error. And certainly, we can do it at runtime [inaudible]. It will give you an error that says “Seems like you forgot to import something.” WARD: I think that people are going to really like that. IGOR: I think it's important for people to just be a little patient. Like, all this stuff is Alpha and there are many pieces still missing that will fill in the whole picture. And I think when we show the whole picture, things will make a lot more sense. And you'll see why these things actually matter and how they pull together into one place. WARD: I think people are just excited about it and they also, what's got me is that maybe at first, when I first heard about it -- this is true of all things when you move the cheese -- it was like, “Oh, they are going to jam 2.0 down our throats.” But actually, when you couple the migration story in the way you guys are talking about it, it's more like Angular 2.0 has to go up there and win our hearts. And you’ve got one to carry you as far it carries you, and it will be great and you're going to stand behind it, but we're going to have something for you that makes you feel “Wow, I really wanna move to 2.0”. MIŠKO: Totally right, Ward, but I think you're reflecting what a lot of people feel. And that I haven’t seen the syntax yet or experienced it, so I feel nervous about it. And so like what Igor said, we're really going to focus on showing example, showing people how forms work, getting tooling together, showing them how it will improve their lives. And you can all just do that. That’s totally fair. JOE: In the last couple of minutes, I think one thing that everybody wants to know is can they start playing around with Angular now and what's that like -- Angular 2.0, of course. MIŠKO: Yes, they can start playing with it and it's a mine field. [Laughter] BRAD: Well, mostly because there's no docs and there’s missing pieces. Like, the router is not [imported?]. The little form stuff is still coming together. JOE: Although I think there's also the issue of just there's not a natural like really good build out there. So getting Angular into something and playing around with it involves a lot of like working with bigger pieces -- lots of different files -- that sort of thing. That’s probably a little bit of a difficulty with using Angular 2.0 now, right? IGOR: Right. And we're definitely working on fixing this. The reason why we're showing all this stuff early on is because we do want people feedback coming from people that are willing to spend the time and go through the “mine field” as Misko described it, and give us feedback. We're going to make this easier as time goes, but we didn’t want to have a big reveal. Like, “Look at this shiny, new thing! This is the Angular 2.0 and it's done. And you have nothing you can tell us about it because this is how we've made all the decisions and that’s it.” So the reason why we're showing this early on is because we really want the community involvement and get early feedback. Like, this thing about imports that Ward mentioned, it bothers me personally a lot, and I know that it's going to bother other people. So we're explaining why we're doing it this way and maybe having somebody from the community come and give us the suggestion that we haven’t considered would be very useful. And this not just [inaudible] or anything, we're looking for any kind of constructive feedback. But I would just ask anybody if you want to give us feedback, please try to understand why we are why we are right now. We have a lot of design docs out there that explain the current state of why and how we got there. So it's not very useful for us to just go over and over the same discussion that we already had many times in the past. JOE: Awesome. Okay. Well, I think that we covered that in a short amount of time, but it's probably sufficient for the moment. BRAD: Yeah, so just to reiterate, we want feedback -- and a lot of it -- but first, go read our design docs and watch our keynotes, so that you get the whole story. And then definitely, come tell us what you think. CHUCK: All right. Well, let’s go ahead and do the picks now. Joe, are you ready with a pick? JOE: Yeah, you bet. I'm going to cheat and have more than one pick because it's related to the topics. We just talked about getting started with Angular. I’ve played around with a lot of different ways to try to do Angular 2.0, and the one that really works out the best and is the easiest to get going with is the repository by Dave Smith that he made in preparation for his talk at ng-Conf. So I'm going to make that my first pick. And then my second pick is going to be the ng-vegas conference coming up in May, which I'm helping to organize. Which I'm really excited about because there's going not be a lot more opportunity to talk about Angular 2.0 in a couple of months than there has been in the past. CHUCK: Very nice. I was actually going to ask you guys about ng-vegas and AngularU at the end of the show. JOE: I happen to know somebody who's speaking of Angular U -- yours, truly. CHUCK: Awesome. WARD: As will I. CHUCK: Ward, do you have a pick for us? WARD: I thought that ng-conf was so wonderful – so fill of material -- that my pick (it's so obvious) is to go to the YouTube channel for ng-conf and check out some of the videos there. In particular, the two keynotes really set the stage and they worth chewing on. So go do it! CHUCK: All right, I've got a big plus one for that. I was going to pick the same thing; it was the YouTube channel for ng-conf. It was just a terrific experience. It was fun to be there and there was a ton of just great information. I think my favorite of the, you know, not the keynotes was probably “ng-wat.” So go watch that if you're up for a laugh. Lukas, do you have a pick? LUKAS: My pick is the new Angular.io site. I'm really digging it. I'm just super excited to see new content being added. And I actually I actually really love the new logo. WARD : +1. CHUCK: Brad, do you have a pick for us? BRAD: Yeah. So you know, we focus a lot on diversity at Google here, and this a big, huge, cultural shift we're trying to go through -- particularly in Computer Science. I saw a great post just last week called Coding like a Girl, where it talks about the experience being a woman in the field. And I would urge every guy and woman out there to go read it. CHUCK: All right, Igor, do you have a pick for us? IGOR: I was going to pick ng-conf, but somebody took that away from me, so I'll pick Didgeridoo instead because at ng-conf, there's all kinds of crazy stuff that I was just amazed with. But we had a guy in the hallway explain Didgeridoo and I fell in love, so I've been listening to Didgeridoo music for a while now. CHUCK: Misko, do you have a pick for us? MIŠKO: Yeah. I'm kind of a big fan of Angular 2.0. [Laughter] LUKAS: I don't understand. JOE: Well done. CHUCK: All right. Joe, any news you wanna share about ng-vegas? JOE: Obviously, we're looking for sponsors and by the time this goes live, the early bird tickets will no longer be on sale, but we have lots of speakers. And the speaker line up should be posted by the time this goes live, so I'm excited for that. That’s it. IGOR: Can I share one more idea? CHUCK: Sure. IGOR: I have a better one than Didgeridoo. [Laughter] IGOR: Dave Smith was a speaker in ng-conf and he did a talk on React and Angular and how you could benefit from using React in Angular. And at the end of the talk, he showed the same example… But the whole story was a particular scenario in Angular was slow. He used React. It was much faster. It was great. And then at the end, he showed the same example with Angular 2.0 and it was even faster. But what he found out after the presentation was that he made a mistake in his presentation, and actually accidentally made the React code slower. And so what he did -- and this is something I really appreciated -- was that he went back, he recorded a screencast where he explained the mistake he made. He corrected it and then showed the actual difference between the two, and then asked the conference organizers to pin that piece to his presentation as addendum. And I think this really speaks to the integrity of the speaker. It's something that I don't see very frequently. And I think that it's very common that people make mistakes. Admitting that you’ve made a mistake is really cool when you do it. And it's even important if you make this in a way where you can actually explain what happened and what the correct information is. Because I just see too much misinformation out there on the internet, so if we can go back and fix it, we should do it – and this is a great example of that. WARD: It sure is. And the integrity of our discussion about [inaudible] frameworks is something that I thought was sorely been missing, but it's a kind of maturity that’s coming to it. It was made clear at the beginning of the conference and I think that’s the way we all should go forward. And I'm looking forward to more of that kind of thing that you're talking about. That really shows that we understand that we're all in this together. LUKAS: +1000. Well said! CHUCK: Yeah. We all benefit from the ecosystem getting better, regardless of whether it's right in our backyard with Angular or something else. Ward, do you have any news about AngularU that you wanna share? WARD: Just that it's coming in June and that California is beautiful and it's right next to the Angular team, so there’s an excellent chance of you meeting the team if you come. And we haven’t had rain in so long, we promise it will be beautiful in June. JOE: It's like a major annual pilgrimage to Mecca. It's time to go. WARD: Yeah. It's time to come to Mecca. CHUCK: [Chuckles] All right. I think that's all we have, so we'll wrap it up. Thanks for coming, Brad, Misko and Igor. MISKO: It's great. Thanks for giving us the opportunity. IGOR: Thank you. BRAD: Thanks. LUKAS: Thanks guys! CHUCK: All right. We'll catch you all next week![This episode is sponsored by Mad Glory. You’ve been building software for a long time and sometimes it gets a little overwhelming; work piles up, hiring sucks, and it's hard to get projects out the door. Check out Mad Glory. They are a small shop with experience shipping big products. They're smart, dedicated, will augment your team, and work as hard as you do. Find them online at madglory.com or on Twitter at @madglory.]**[Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net]**[Bandwidth for this segment is provided by Cache Fly, the world’s fastest CDN. Deliver your content fast with Cache Fly. Visit cachefly.com to learn more.]**[Do you wanna have conversations with the Adventures in Angular crew and their guests? Do you wanna support the show? Now you can. Go to adventuresinangular.com/forum and sign up today!]**