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

all right so what it says on the calendar is the current state of angular [Music] California this your team need to master angularjs Oasis digital offers angular boot camp a 3-day in-person workshop class for individuals or teams bring us to your site or send developers to ours angular bootcamp.com this episode is sponsored by wigo 5 a brand new generation of JavaScript controls a pretty amazing line of HTML 5 and JavaScript products for Enterprise application development in that wio 5 leverages ecmascript 5 and each control ships with angularjs directives check out the faster lighter and more mobile widmo 5 hey everybody and welcome to episode 35 of the adventures and angular podcast this week on our panel we have Jo hey everybody Lucas rubley hello I'm Charles maxwood from devchat.tv and we've got a couple of special guests we've got Brad green hi mishko Hy hello and eigor Minar hey guys so uh this week we're going to talk a little bit more about the current state of things with angularjs or angular which which is the more official with or without the JS we're actually trying to drop the JS so while we started with the angularjs in the last couple of months probably more than a year actually now we've been just preferring angular and like you can blame me for this because it just drives me nuts when people spell angular space dot space JS or any other crazy variants of angularjs so we just decided to make it simpler for people and just drop JS and just call it angular we were originally a little worried about people being able to find us but apparently uh 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 get to very nice nice now I get to write an angular RB now I have to change the title of my book thanks a lot guys no don't print it yet I need to print it before it gets official so there were a lot of announcements at ngom and we kind of talked through some of them on the live show last week but I'm I'm kind of curious to know from you guys like which announcements did you feel like were the most important or impactful 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 or we can go on specific items whichever you think is better oh we'd love to walk through it yeah three two one go so a couple things the sum up is that angular 2 is in Alpha it's streaming 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 One apps so that you can migrate a little bit at a time we've been investing heavily in the one angular one branch we've almost got a uh uh 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 and angular 2 a new ITN facility that we think is amazing you have to work on ITN there's a lot of problems to solve there internationalization internationalization sorry thanks and that is also shared between angular 1 and angular 2 and so I think the good news is is these things are starting to pave the way for writing code directly in angular tude because you'll be familiar with the API you'll be actually writing very similar code against both so following that we're we're going to be working on 1.5 and we'll 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 simple and easy the other big news from the conference was was our partnership with the typescript guys and we had Jonathan from the typescript team on stage and we announced that we were going to merge all of our atscript extensions to JavaScript development with typescript and that we were able to do this because they'd actually implemented all the features that we had done in at script and they have a wonderful tool chain and they're 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 tool chain and and add features but also Al work with a larger group of Partners on driving these things into the JavaScript standard through the tc39 process cool so what do you feel like that your involvement is going to be in driving this through the tc39 process we like at this point we care the most about moving the annotations forward because that's one of the areas there was lack of forward progress so we we committed to getting the metadata and annotations uh or decorators or something in between to tc39 and get it to the hands of developers the type part of atscript or typescript we feel like the guys from V8 and typescript have the expertise to do this we're happy to consult with them and and give them feedback in that area the piece that we care a lot about is runtime checking which is something that typescript doesn't have yet and uh we working on adding that TP scrip So speaking of annotations we're actually very interested in having more Partners who want to both implement it in transpilers and who want to bring their support we've had a good partnership on this with Yehuda cats from Ember and also Rob Eisenberg of uh what's his new aelia aelia yes and we're looking for more folks who are interested in both using them in their Frameworks and then supporting them and bringing them to browsers earli so could you explain a little bit about annotations and the strength of them and why you guys are really pushing forward with this right so for the real long time angular has been trying to use annotations in our apis because we feel like having ability to describe code through metadata is very powerful it allows you to create um piece of code that can be plugged into a framework and then the framework can declaratively understand what that piece of code is trying to do and how it falls into the the whole framework and if you look at angular one code base you'll see that we already tried to do this through the array notation for dependence injection and even our current directive API is very declarative and kind of looks like one giant annotation if you splink hard enough so this is something we saw in angular but then when we looked outside of angular we saw that this is not just angular specific problem like I was looking at some react demos the other day and I I was just thinking hey they're actually trying to do something that annotations would be better fit for like they have this API and they 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 there's a lot of prior knowledge and we can see that once a feature like this is added to programming language it enables new kind of apis or makes existing apis much more easier to read and this is why we think that having annotations in JavaScript would be very much beneficial not just to angular but to broader JavaScript EOS system it's kind of like bringing reflection to JavaScript as we know it in other languages would you say we already have reflection what do you mean well in the ability to to extend it to actually an extensible reflection in 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 right so it's not just about like in injection there are many things you can do with annotations and we actually have a doc if anyone's interesting I can I can just add it to the podcast notes where we describe many of the use cases already in JavaScript or possible use cases in JavaScript in the future but also use cases outside of JavaScript so we have pretty good collections of these use cases and we definitely want to be to interact with these annotations at drawn time because I think that that's what makes them very powerful yeah when I said that it's not exactly I mean you were saying that we already have reflection but for example the type information that would normally maybe you had some type annotations today they are usually erased in typescript at runtime so you wouldn't actually have any information about parameters and and so forth unless you had these supplemental things during runtime right that's correct maybe mishko could expand on this but before we go there I I just want to make clear distinction between metadata annotations and type annotations for the standardization purposes we are trying to distinguish between these two even though to developers they look very similar and conceptually they're very similar uh for purposes of standardization and and uh just getting it through the whole process it's easier to deal with this two separate features fair enough Mich can you talk about runtime type infint and dealing with types run time in typescript so right right now at runtime the type information is erased but there are use cases when we need to main the type information yes so the way the typescript solves this is that when you have well they don't have annotations they have decorators is that when a decorator is executed it gets past the type information and if the decorator chooses to persist type information it's up to The Decorator that was a big statement other cases where we want to retain type information not metadata what type information what so the typ script only allows you to retain it if you have a decorator there but I think you was asking about use cases we're trying to support like why do we want these things oh so it it really enables meta programming right there's all kinds of ways that as a framework you don't know what the developer is going to write on on on the end of the day but by having a meta programming you can kind of create really meta algorithms and The Meta here is that you plug in the type system uh at runtime from the developer and do we have things specifically an angular we care about uh well dependence injection is an example of that instantiating directives building components assembling them together using the directive information to control the HTML rendering there are all examples yeah so all over the place essentially this is how angular's built and everybody takes advantage like I think like we've already talked about some of the the end developer bits that they'll care about documentation is a big one you'll be able to do you know develop time versus deploy time aspects of your code lots of interesting use cases could we uh 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 comp and in other places there was a really cool Meetup that happened in Mountain View back in early February and so I'm just curious what your 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 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's 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 builtup system but the overall authoring process and that sort of stuff so the way the directives are created and used that has been uh used for for a while an angular Dart so we feel like that that code is pretty vetted you know 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 the syntax and we've been working on it for now over a year tried all kinds of different examples it seems to work well we don't expect to have any kind of a crazy use case to be discovered that's going to throw a wrench under our feet so it's kind of unlikely it's pretty stable there are a few things that we might add but not change right adding is always a possibility changing is uh but again this is Alpha code so if you start building production applications and we change stuff then don't be angry at us please well uh like I think there's probably a good example the uh 4 each syntax right like wasn't that recently changed yeah from bang to Star uh I wouldn't call it a syntax right this is a uh the syntax of binding has not changed what we have changed is the name of of the the directive that to me that's not in the syntax category uh well I think in our demo at the meet up in February we use bang for each and at NG comp we use star for each uh I think he's referring to for each going to four which one are you referring to oh it's a good question no I I think it was the bang went to Star I think youal one of you talked about that uh yeah so the reason we U we went against the bang is because it would say bang if equals expression and it kind of looked like not if equals expression and so we kind of looked at it and say well I'm not sure about that well that that's kind of quite a segue into the whole binding syntax which is actually that was something that that many people who first were encountering your plans for triangular 2 got kind of willed out got really freaked out by and actually it's as uh 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 I thought that mishko that your presentation uh your keynote about about data binding was something that we should tell our viewers to or listeners to go check out but maybe you can summarize what the real change is there so that uh they're invited to go uh you know they really want to go look at that video again because I thought it was a great presentation thank you so the big change is that we're we're changing the semantics of what does it mean to bind in the old system we were binding to attributes on a Dom in a new system we're binding to properties and it turns out that that seemingly tiny change the difference between I whether one can bind Two web components or not the other change is that we needed to make sure that we could Escape The Binding in a way that the web component couldn't get a hold of it and that really meant that you have to escape the key portion of the attribute not the value portion of the attribute so we really changed the the philosophy of saying you know HTML is really just a serialization of the Dom and at runtime the Dom is really all about the properties not about the attributes and once you kind of internalize this particular point of view you know all the other pieces just kind of naturally fall out specifically Ward's probably talking about the unidirectional data flow we've taken on for uh change detection and what does that mean for forms that's right I certainly want to get there but I think that there's the prior prior um observation that you were just making there cuz cuz at first it sort of you know I can tell you our first reaction was wow this is just like some kind of arbitrary shuffling of the chairs uh you know what now you know come on I used to be able to do NG this and my that and now suddenly You' changed that all of that and it seems completely unmotivated and I think that's what you did you made really clear maybe I should have in reading it understood it but you made it really clear that this is a semantic change not a syntactic change that it's about you know that thing about binding to properties directly of the underlying Dom rather than trying to trick the with new attributes is the key move and that uh we'll still be able to do all the things that we used to be able to do but we'll be able to do a lot more of them without having to dip into the angular Storehouse of like what directives do they have for us today kind of thing that's right yes I cannot stress this enough that this has been motivated by you know web components and simplification and it was not just a random let's change the syntax you know that the syntax thing is really a side effect of the semantic change I I think we definitely are learning how to better communicate our intentions and in many cases I think we've done a lot on our end and like all of this stuff was documented in many design dogs for over a year before it was even showed public at at NG europeo so if there's anything I would like to ask your listeners is that when they see something odd before before they make a conclusion they should look for motivation and usually the motivation at least in our cases is very accessible and I think just understanding why we're doing something rather than what we are doing just looking at what we are doing would answer lots of questions and and help people understand why this stuff matters and to make this easier we've recently you probably noticed this on the angularjs.org site there's now a big yellow button that links to our design docs and notes so if folks weren't following our weekly meeting notes or our Twitter posts or any of these other things now there's one easy place they can go to the look for so now we've set the decks the thing that's still got me spooked is how do I well there's two-way data binding and we're all most of us are not everybody understands what two-way data binding is but I'll just say it the surface I don't think any of us actually cares about the phrase two-way data binding so much as we care about the ability to work with forms and get 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 right so we have the new form API and again let's talk about the motivations why we're we're changing it so the issue with the old system is that if you wanted to write a unit test uh all of the information about what Fields exist and what are the validators is stored in HTML and as a result uh 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 uh what exactly are you testing so this is the primary motivation why removing the metadata about the form from the UI to the imperative code of the JavaScript and the idea there is you can just instantiate it you can unit test it you can write unit test that says you know imagine I enter a username into the field you know what kind of error message will I get will I get it 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 know how does the form look like it's the domain of the UI how exactly the form behaves and how to validate it and what Fields exist Etc that really is the domain of the controller and so this is the kind of the motivation why we have moving it into this thing it is slightly more wor both and I say slightly uh because for a large form the benefits greatly outweigh the the the few moreal key strokes that you have to do in order to get in there so that that's basically what's happening now uh the way this gets around the problem with two-way data binding is because the the controller is aware or rather knows the full structure of the form the form can bind to the UI elements around time and set up the right listeners Etc now what we're basically saying is that the bracket notation or the what I like to refer to as the forward binding it gets data from the model to the UI but the event notation or the parenthesis or the on dash notation right that's the reverse Direction gets data from the UI back the model and so the forms control automatically sets up all of the forward and backwards bindings for you so that you don't have to do it you simply have to just say this is a form and it's bound to this form declared imperatively inside of the code and so the end result is that you should be able to do forms just like before but the benefits are you still have a directed gycc graph so we can do single digest and you should be able to have a lot easier time unit testing that thing understanding its behaviors we should also talk about observables and how observables can play a big role in this right so because the form apis now inside of uh JavaScript or kind of the structural declaration not the visible one you can listen to the changes on it and we we've chosen observables as the mechanism by which you can listen on changes uh inside of the code so it's a lot more expressive in terms of what is the intent of form and for those that are not familiar with observables this is a new uh feature that is being standardized as part of es7 or ES 2016 whatever they call it now and the goal is there to be able to create reactive streams in in JavaScript in a standards way standard way just like we have promises standardized on API for reactive streams and the name for that is observables the main benefit is like one once you have the abstraction then you can mix and match streams you can do all kinds of crazy stuff joining forking uh do Transformations on streams all uh regardless of where the streams are originating from and for us one of these origin would be forms is there someplace we can go to learn about a your the sort of new way of hooking up the forms and and be about how it relates to observables unfortunately we don't have documentation but we have lots of unit test where you can see the the mation so I would just say go check out the source code for now but docs are coming soon we we'll make some announcements maybe at the next uh angular Meetup here in Mountain View we'll bring some more attention to to that and I would like to return back to the discussion about oneway versus two-way data binding or what exactly this two-way data binding is because in my experience when I talked to many of the developers there's a lot of confusion about what this two-way data binding actually is and many people think that the double curly uh which they know from angular one is two-way data binding and when somebody says oh two-way data binding is going away they're like are you taking my double curls away how am I going to do anything so let me let me just clarify what what this mysterious 2 Data binding is at least in angular so in angular we have oneway data binding which is the double curly that you know and two-way data binding which is NG model which is the the way to bind forms there is one more use case where we use two data binding which is binding between two components so let's say you have a single model in your application and you have two components and you want to bind that model to both of these components and if any of the components change the model from it's in internal State you want the change to propagate back to the model and from there to propagate to the other component and what we found in large applications is that this approach just doesn't scale it's very hard to understand and reason about in large applications and just causes more trouble than what it's worth so we have different strategies to deal with use cases that would usually be implemented in this way but we have no intention of supporting this through 28 well for our audience let me set out the case where I think that that occurs that we run into all the time if you've ever uh scheduled a meeting or something like that and you put the start time in it usually calculate pre-calculates in output time like a half an hour later right so that it'll be a half hour meeting and if I move the start time up an hour then automatically it 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 an 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 just said but we'll be able to do it somehow so let me kind of rephrase the thing slightly One Way data Bing is basically you read the expression two-way data binding is most of the times read the expression sometimes you right into it and this is where the problem starts so in in the scenario you described with the sliders the way to solve this particular problem is to say whenever I want to write to an expression instead of just writing into it I have to go and make sure that I am 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 digest cycle I have made it explicit and by making it explicit I made it predictable and so what you were asking for or can certainly be done easily in angular 2 but it's not going to be done through the clever use of double curries but it's going to be done by saying you know on slider move or on selection go recompute the other two values okay I kind of expected that but I thought maybe somebody wouldn't know when we were talking about it in the abstract it sure will be great when we see some examples and I know those are coming yes cool there was another thing that kind of got me you know I'm going to take the occasion to have you all here to get it of the things that struck me as um frictional when I Define a component and I I noticed that there's that at temp or at something at the top where I describe the template and I have to list the well what I would have called directives I'm not sure what to 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 yes they're still called directives there was been some confusion actually that I've been answering a question online just the other day where somebody said oh directors were replaced with components and it's not actually true true what we're saying is in angular 1X there's just directive which has all kinds of different use cases in angular 2 we have directives but be specifically laid out the three different use cases that we exist one of them which happens to be a component the other one is The Decorator and the last one is a viewport the question is why do we have to list the import so so the first thing is that you don't have to list every single one you can easily group them together into a common set of uh directives you like to use just list the one by itself if you wanted to imagine you had a angular 1X world it's as if you created a one Global array with every single directive list in it and then you just simply add that array into the directives list the directives list is recursive which means it can have arrays of arrays which can have more arrays and be flatten it into a single list on the end so so you don't have to list every single one but there are benefits by listing them the benefit is that we can really understand uh and encapsulate and we can limit which set of directives are imported in a particular template so you can simply just say I just want director A and B and not the required directive that happen to like do some form validation or something like that uh and you can also rename the directive selectors at this point so you happen to want to import two separate directives that happen to have the same selector and somehow it collides with for you uh you also have the ability to rename one of the selectors so you do have to import you can group them into uh super sets so you don't have to list every single one and there are some very nice benefits you get out of it so I guess the question Ward is trying to ask is why do it have to do the JavaScript when we the place where I actually use this directives is in HTML or in the template Bingo uh yes that's 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 that 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 it's there's 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 with minifier and tree shakers and so on so to like really It Gos 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 there there was an effort to add UT system into HTML through HTML Imports which polymer possibly some other web component libraries are using but there's also a lot of push back against that spec because it doesn't solve one fundamental problem which is how do you unify the HTML Imports with es6 Imports or echos script Imports uh and module systems that that is just not solved yet I know that there is some work being done in many smart people are looking into this to figure out how to unite these two worlds for now we decided we will just take the easy path and declare the Imports in in JavaScript personally this bothers me a lot and I have some ideas about how we could work around this using tooling where the tooling would allow you to specify the Imports in HTML but under the hood it would be converted into JavaScript code so we would have both the nice declarative syntax as well as all the benefits that script 6 gives us but this this work still needs to be done so we're hoping that this will improve but we also trying to push the web platform over this area because it's a bigger problem it's not something specific to Eng well I have to agree with you uh you were about feeling uncomfortable about it and looking for something but one thing that occurs to me is that I'm not sure everybody was clear on why um we felt it necessary why we couldn't just wait um until the template appeared and sort of analyze it as we go which is pretty much what happens today right I mean you bring in a template and then angular one walk it and figures out what's there so naming collisions aside which which we've been living without that being much of a problem anyway what's the motivation for wanting to declare these things uh up front so in aular one you have to list every single directive inside of your module ahead of time so it's as if you had a global list of directives what we're doing in2 is we're just moving that Global list to a component specific list right that's the thing that seems weird in other words if if you came to us and said said yeah you still have to register them somewhere so we know to load them I'd have gotten that but what feels weird is that a I think of it as a view model but the controller or the component uh 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 so it's not the component uh the component has a template annotation and it's a template annotation that knows about this and it's not like the component can really get a hold of the template annotation at runtime I mean that the system can but not the component itself uh and keep in mind like you could have multiple templates per component depending on you know device or localization and so on well that's that that's a shocker so I'm looking we're looking forward to learning more about all this but that's good too because not everybody is saying I want to lock a controller to a particular view again it's usually one to one but not always well the use cases for that are primarily if you're building uis that scale across multiple viewport sizes so let's say you want a specific template for mobile device and other template for a large desk of application and you can achieve benefits through just CSS maybe on on mobile you just want completely different UI these are the use cases where you want multiple templates and if you have different UI in a mobile it could very well be that there's different set of components so why should you be loading these components into your application right component should not be taking out valuable memory space in the app uh so this mechanism allows you to just say only load this components if this particular template is up and running very interesting it it definitely feels a lot different but it's an interesting way to tackle that problem I think if you if you think about it more you'll realize that this is very similar to what we are doing with JavaScript when I say we not as the angular team but as uh the JavaScript Community we realize that at some point just using globals for sharing symbols and and variables just breaks down and that's why we realize that we actually need a module system in JavaScript these Imports in in templates in angular are just analog to that but translated to angular and and templates so this is actually one of the issues that I have with the current web components uh specifications where if you import a web component the import is global and you can import it from wherever and if you do it in the right way then the component web 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 were scoped and were explicit I would feel more comfortable 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 their template refresh and it doesn't work and I think there's a couple of things in angular that I identify with this like it's that one thing that I keep forgetting to do for example a snake case versus camel case and directive names right so we're building tooling that will just tell you that hey there is the suspicious attribute that is not HTML and looks suspicious you probably made a mistake and might want to go back and fix it so it's not just toing but we can do this at runtime uh we can look at for example a property binding and we can do has property off and see like okay you seem to be binding to a property doesn't exist you're probably doing something wrong we can also look at extra attributes we don't recognize and say you know this particular attri doesn't exist in HTML why are you putting it over here you probably forgot something and so in vast majority of cases I believe we can now do a proper runtime error and uh certainly if we can do it run time we can also do it at tooling time but we can give you a nice error it says seems like you forgot to import something I think people are going to really like that 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 fall together into one place I think people are just excited about it and they also what's got me is that maybe at first you know when we first heard about it and this is true of all things where you move the cheese it was like oh they're going to jam 2.0 down our throats but actually when you couple the migration story and the way you guys are talking about it it's more like angular 2 has to go out there and win our hearts and and you've got one to carry you as far as it carries you uh and it'll 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 want to move to two and totally right W but I think I think you reflecting what a lot of people feel and that I haven't seen the syntax yet or experienced it and so I feel nervous about it and so likeor said we're really going to focus on showing examples showing people how forms work getting tooling together showing them how that improves their lives and you you you can hold us do that that's totally fair in the last couple of minutes here well 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 of course yes they can start playing with it and it's a field well mostly because there's no docks and there's missing pieces like there's the router's not been ported uh some of the form stuff is still coming together well I think there's also the issue of just there's not an actual 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 it's probably a little bit of a difficulty with using angular 2 now right yeah and we're definitely working on fixing this the reason why we're showing all of this stuff early on is because we do want Comming to feedback from people that are willing to to spend the time and go through the M field as M described and and give us feedback we're going to make this easier as the time goes but we didn't want to have like big reveal like you know look at the shiny new thing this is the angular 2 and it's done and you have no nothing you can tell us about it because this is how it made all the decision and that's it so the reason why we we're showing this early on because is because we really want the community involvement and get early feedback like this thing about Imports that W mentioned it bothers me personally a lot and I know that it's going to bother other people so explaining why it works this way and maybe having somebody from the community come and and give us a suggestion that would we haven't considered would be very useful and this is not just about Imports about anything we're looking for for any kind of constructive feedback but I would just ask everybody if you want to give us feedback please try to understand why we are where we are right now we have a lot of design docks out there that explain the current state and what how we got there so it's not very useful for us to just go over and over the same discussion we already had uh many times in the past awesome okay well I think that um we covered that in a short amount of time but it's probably sufficient for the moment yep it's going to better yeah so just just to reate the recipe we want feedback and a lot of it but first go read our design docs and watch our Keynotes so that you get the full story and then definitely come tell us what you think all right well let's go ahead and do picks now Joe you ready with a pick 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 and the one that really works out the best best and is the easiest to get going with is a repository by Dave Smith that he made in preparation for his talk at NG comp 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 to be a lot more opportunity to talk about angular 2 in a couple of months than there has been in the past very nice I was actually going to ask you guys about ngie Vegas and angular U at the end of the show I happen to know somebody who's speaking at angular U yours truly awesome as will I all right Ward do you have a pick for us I thought that NG C was so wonderful so full of material that my pick it's so obvious is to go to the uh YouTube channel for NGC and check out some of the videos there in particular the two Keynotes really set the stage and they are worth chewing on so go do it all right I have a big plus one for that I was going to pick the same thing was YouTube channel for ngom it was just it was 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 watt so uh go watch that if you're you're up for a laugh and uh yeah that's that's all I've got Lucas do you have a pick yeah my pick is uh the new angular iio site I'm really dig in it I just am super excited to see new content being added and I actually really love the new logos so plus one all right Brad do you have a pick for us yeah so you know we we focus a lot on diversity at Google here and this is a this is 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 uh in the field and I would urge every guy and woman out there to uh to go read it all right eigor do you have a a pick for us I was going to pick Ang but somebody took that away from me so I'll pick digo instead because at NGC like there were all kinds of crazy stuff that I was just amazed uh with but I also we we we had a guy in the hallway just play digo and I fell in love so I've been listening to music for a while now all right nko do you have a pick for us yeah I'm a big fan of angular 2 I don't understand well done all right Joe any uh news you want to share about NG Vegas 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 lineup should be posted by the time this goes live so excited for that that's it all right and Ward do you have any can I share one more idea sure I have a better one than digit uh Dave Smith he was a speaker at ngom and he did a talk on react in angular and how you could benefit from using react in angular and at the end of the talk he showed the same example uh like the whole story was that particle scenario in angular one was slow he used threea it was much faster it was great and then in the end he showed the same example with angular 2 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 so what he did and this is something I really appreciated was that he went back he recorded a screencast where he explained uh the mistake he made he corrected it and then he showed the actual difference between the two and then asked the conference organizers to pen that piece to his presentation as adendum and I think this really speaks to uh 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 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 the correct information is because there's I just see too much misinformation out there on internet so if we can go back and fix it uh we should do it and this is a great example of that it sure is I I and the the Integrity of our discussion about each other's in Frameworks is something that I thought was s has 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 there that's that really shows that we understand we're all in this together plus 1,000 well said yeah we all benefit from the ecosystem getting better regardless of whether it's right in our backyard with angular or something else all right Ward do you have any news about uh angular U that you want to share well just that it's coming in June and that California is beautiful and it's right next to the angular team so they'll 's an excellent chance of your meeting the team if you come and we haven't had rain in so long that it'll probably still be beautiful in June ex up today so if you have a major annual pilgrimage to mea it's time to go it's time to come to Mecca all right well I think that's all we have so we'll wrap it up thanks for coming Brad mishko and eigor a it's great thanks for giving us the opportunity thank you thanks thanks guys all right we'll catch youall 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 there are a small shop with experience shipping big products they're smart dedicated will augment your team team and work as hard as you do find them online at mad glory.com or on Twitter at madglory hosting and bandwidth provided by the bluebox group check them out at blueb box.net bandwidth for this segment is provided by cash fly the world's fastest CDN deliver your content fast with cashif visit CAF l.com to learn more do you want to have conversations with the adventures and angular crew and their guests do you want to support the show now you can go to adventures and Ang [Music]