016 AiA NG 1.3 and 2.0 with Brad Green, Igor Minar, and Miško Hevery

so does this podcast make my butt look [Music] big 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 adventur and.com Forum and sign up today hey everybody and welcome to episode 16 of the adventures and angular podcast this week on our panel we have Aaron Frost hello Joe eam hey everybody John Papa hey from sunny Florida Lucas rubley hello from Phoenix I'm Charles maxwood from devchat.tv and we've got a few special guests we've got misco Hy hello Brian Ford hello Brad green hi everyone and eager Minar yes hi there so we kind of did an impromptu extra episode here uh it'll come out on the normal schedule but there's been a lot of discussion about what's coming in angular and there's been a little confusion about angular 13 and angular 20 and just you know what's coming down the pike so we thought we would bring you guys on and just talk about it and make sure that we and the rest of our community understand what we're looking forward to in the new versions of angularjs do you guys want to just give us a brief introduction or a brief discussion over you know what's coming in angular 13 and 2 and where you've seen some confusion maybe sure I can start so with one 13 we just released 13 about two weeks ago is it now and 1 three was a big milestone for us uh we put in quite a few good features but the main one was really a lot of work we've done on performance we um wanted to fight some some of the misconceptions about angular and and show that angular can be actually pretty darn fast and many of the things we are doing and the abstractions we have in the framework are pretty solid and I I think we proved that pretty well in 13 so performance is one of the huge features there is a whole bunch of other ones redone the form validation the way the forms binding work we've done stuff on accessibility and a ton of features that just make developing with angular easier and more enjoyable now I should mention that we covered a lot of these things at NG Europe last week the week before last and we'll have all of the videos up on our site by the end of the day but you can find them out on YouTube right now under the en Europe account and I think a couple things to to look for are not just the things we had in 1.3 then in our keynote we talk about it but there's a deep dive that Brian and Jeff did that talk about specifically how much faster particular pieces are and some of the developer ergonomics bits we added just to make it nicer to work with angular there are some things outside of the angular core that we're even just excited about one of them is material design this new UI toolkit and interaction design patterns that we're supporting as a as a separate library and then there's some fun stuff with our partners that we talked about supporting mobile as well yeah I think it'd be important to note that we're trying to rather than add more things to angular core build up new modules for new features so I think that's really cool to think about what's coming with 1.3 what's already here with 1.3 and what's coming 2.0 if I took a stab at 1.3 the main features sound like there's a lot of performance stuff under the covers that you can do uh there's the bind ones features there's the NG model options there's NGA NG messages am I missing any other main features in 1.3 it's really the performance and the work we done on binding um there is a lot of stuff we' done around defaults so many features we had in angular were opt in before and now they are just available to you without you know having to know about these are thinking about something particular is there something that you particularly like about three my favorite feature is bind once why tell me why oh just because that's probably the number one thing I have people ask me about that is a little bit difficult to address you have to kind of like do something a little bit smarter got to know angular a little bit better than maybe uh people will typically have known it after a few months so with bind on it's easy for somebody that's really new at angular to still be able to put together performant piece so I I would like to challenge you on this because like when we originally started working on one time binding in angular we thought of this as a performance enhancement but with all the other work we've done on on the parser and the checking it actually turns out that the whole onetime data binding is not as relevant or as impactful as as people would think and where it brings some advantages is that it reduces memory conception so at this point that's the main benefit of onetime binding if you use onetime binding you shouldn't be using it because you want perform an app you should want it because you know that these bindings on a page will not change and you don't want the memory to be tied up because of something that will never change so it's it's a good way to reduce memory consumption but there are very few cases when uh you can truly benefit from onetime binding when it comes to Performance just because the rest of the system is already so fast the reason I really love bind once is because when I did want bind once I used to have to pull in a separate Library called bind once so now I don't have to do that I kind of want to turn the conversation though back to some of the confusion that I'm hearing and one of the things is over 1.3 and 2.0 should I bother switching over to 1.3 before I go to 2.0 or should I just wait until 2.0 comes out can I mention something real quick about that Chuck so at Domo we have a large app we we talk about how large it is and a lot of it's angular we made a branch with 1.3 the other day and it just worked like we were kind of surprised that there wasn't a lot of breaking and like so far the app's working the only thing that broke surprisingly was the directive that Papa just mentioned which is the bind want Direct Ive doesn't work anymore and so um a lot of a lot of stuff disappeared but it's working and like the screens are visibly faster and so that's for me one of the great things is I don't think the migration is going to be super painful to be honest with you yeah and this was one of the goals of one three we didn't want to make breaking changes that would make migration very difficult like there there are if you look at the migration guide there are breaking changes but all of them are very small or are just Cor cases that people don't typically see in their applications we still wanted to document them just so that if somebody uses a particular coric is in particular scenario knows they know how to migrate but even though the migration guide might look kind of scary for the most app it should be just upgrade to the latest version and and things should work so having said that if you want to make your application significantly faster uh for your users and you want to be on the latest code defin only upgrade to 13 there is no reason to wait I'm sure there are some applications that are in production are working just perfectly fine and nobody is in rush to upgrade upgrade them so I wouldn't upgrade just for the sake of upgrading but if you have a high traffic application that you want to make faster and you want to continue developing 1.3 is the version you should be using I mean and other things we've mentioned about cleaning up some of your forms code this could be very nice the way you report users to errors can be much nicer with one three the ARA bits we added and then if you're interested in taking advantage of the new router that we'll be building and the material design components those are all things that you get in 1.3 so kind of like eager was saying if there's apps that work fine and you're not don't want to invest a lot in them then maybe not but yeah 1.3 can give you a lot of advantages if you're actively developing an app so if you guys would in mind I put this out on Twitter to see hey what kind of questions uh can people come up with and one of the the first ones we got here was which is related to this topic is if I'm just starting with angular it's from Brun J swick if I'm just starting with angular where should I put all my time right now guessing 1.3 since 2.0 is not out yes absolutely like 1.3 is the version we want people to use today it's the best angular we have it's fully supported we have a dedicated team of people working on it you know listening to a bug reports and fixing issues there are features that are still coming to 1.3 so like some people say that 13 is dead or is obsolete that's absolutely not true we have so many applications here at Google just NG Europe we announced that we have over 1,600 applications that Google build with angular and these applications are moving to 13 most of them not all of them for some it just doesn't make sense but to keep 13 going and if you're starting with angular 13 is definitely the way to go 2.0 is still work in progress It's a moving Target it's too early to like spend significant time on it unless you want to be part of the discussion and shaping the future of angular then you you're welcome to be part of this another just a following question that I've seen around this is how do I prepare myself for 2.0 and what kind of help are you guys going to provide in helping my migrate and although we've heard it a lot we don't have an answer and the big part of the reason is the 2.0 isn't done and so we can't build a migration path to the city that doesn't exist yet and this is something we'll work on as we closer as we get some real bits implemented in angular and as e said like real development should be on 13 but come join us on the discussion around 2.0 if you want to help shape that I do have some like concrete ideas for how we'll be able to M migrate apps from 13 to 2.0 so one of the big things is we'll be releasing a separate routing module which is something that I'm working on and that will be almost exactly the same code in angular 2 as in angular like 13 or or an angular 13 compatible module some other things is like we're going to continue working on angular 13 and we'll be you know fixing bugs and trying to see what the best practices are there and one project that I'm working on is called angular hint and so I'm going to continue adding more kind of checks in there that that try and tell you whether or not something that you're doing is like a bad decision architecturally um if it's something that that I can detect so um I want to hear more about that because I'm building something like that for uh for my own stuff you're building something like what uh like an angular hint like a linting tool so I'd love to talk to you ah okay yeah just and a side I presented about this at NG Europe but it's a it's a runtime hinting system so one of the interesting things is it can detect more things than something like JS hint or JS lint could and there's a whole talk that I give about that and I don't want to spend too much time here but um I think this is something that I can continue to extend as we figure out what the ways that angular 2 is going to be different than angular one so that way you can kind of guide yourself along architecturally so you're not building your app in a way that's too different than angular 2 will be so the question that I have is I think 13 is excellent just the performance and and the new features and somebody coming into Angular JS now is I would definitely recommend start with angular 13 you know it's never too late to start building awesome things right now but from kind of a pragmatic business case standpoint are there any concern starting with 13 if you're building an application that has let's say like a 5-year life cycle that you need to support yeah not only that but say something that you expect to be pretty big in size by the time 2.0 comes out so I mean do we talk already about backwards compatibility in 2.0 versus 1.x I think we can ask about that in a minute but yeah I mean if if you've got a long life cycle project you know should you start with 13 now or are you better off you know hold holding off or making another decision and I think where this question comes from is a lot of Enterprise and business type developers you know they've got managers and leaders looking at them saying hey if we're going to bet on this thing because they're used to the world where they can build an app and let it live for 5 10 years now on the web that might not make sense but still the questions are being asked so how do you guys respond to that this is a good question this is Brad by the way and we have a lot of similar apps here at Google we've kind of maybe a couple different categories of the way we deal with them what one thing to think about is that the web is backwards compatible so even our 1.x or 1.0 angular code if you have an app written in it it will work forever supposedly that the web may change but that's how things work today so even if you're on 1.2 or you decide to go to 1.3 these things will work as e said we've got a team who's going to continue to support 1.3 and fix bugs and there will be there are even some some kind of sizable features that will come in that still aren't done yet at Google we have maybe maybe a couple different categories of apps some are like we talked talked about earlier apps that run fine they don't have a dedicated team that are going to actively develop them it's basically just bug fixing because it it serves the need and some of these are our internal apps and maybe some of these are our lower traffic external apps then there are the projects with active development and these are candidates for possibly like upgrading to 1.3 never moving to 2.0 because this is going to be it's it's a large app lots of lines of code and we're going to maintain it on the 1.3 base there's other folks who will want to take advantage of things that we're developing in 2.0 that will want to undergo the cost of migrating to two and we actually don't know what that cost is going to be we're going to work on the development plans and tools going forward as soon as we know what 2.0 end state looks like a little bit more but so in this category you know what should I do right now if I'm thinking that yes I have an active development and I will want to go for 2.0 really like we've said said there is only 1.3 um there's nothing to develop on top of 2.0 the thing that we're going to do to help right now is to make our activities really visible and so we're doing talks like this we invite all of you folks to ask us where you have questions and then there'll be other forums and our GitHub repository on angular angular is the place where you can see a lot of this activity and weigh in on the issues that we raised there so Brad I had a question um you're talking about long time support for 1.x do you foresee like a 1.4 release eventually like is it that kind of like long term or is 1.3 kind of the end with with some addition of of a couple extra features you go here so I think it's too early to tell there is a possibility of 1.4 but I don't want to comit to 1.4 we definitely want to add features to the 1X branch and some of them are pretty significant like we're looking into better internationalization for example I'm not sure if this will require changes in the core if it will we'll probably go to 1.4 if not we maybe we'll just keep on backf fixing 1 three and adding all these extra features outside of the core we'll see it's really too early to tell and it also depends on the internal needs from Google and and some of other partners we have these discussions with teams that use angular and depending on their needs we adjust our plans some of this is in the support for material design and this is actually not a small thing this is actually a giant push and I I'd suggest maybe go check out the NG Europe talk that folks did we're actually going to need to upgrade we're going to need to pull in this new router that is our 2.0 router backported to 1.3 and there'll probably be some changes to animation coming to support this better as well so this sort of Google wide effort to get on the same ux standard is driving some of this and it's it's a thing Google's doing and we'll support it I would just add to the the question about should I use 1.3 when 2.0 is coming if you really are excited about the the stuff we are doing in 2.0 I think 1.3 is the best starting point for you right now like even though we're going to change apis uh for sure the concepts many of the concepts will remain the same so if you're building application if you're starting now and you will want to eventually use angular 2 angular 13 is the closest thing you can start with today so that just to to add to the one three and and how important it is for us that leads really nicely into another question we got on Twitter and that is Thomas brenz asked if I'm going to learn angular what impact will 2.0 have on me and how can I prepare so you know what is different what are we gaining what are we losing hi this is Mich here I think the motivation behind 2.0 there's two parts first we wanted to make sure that we play nicely with web components we think that the web components are kind of the future we want to support them both as angular becoming a web component if you wanted to do it and as also angular consuming in web components and this is kind of the driving factor for some of the changes in templating which we can talk about later the other thing is we want to simplify things and the simplification thing is you know a lot of the apis we currently have are kind of I would call them organic they kind of grew up because those Fe people asked for features we kept adding them and so on and now if you can step back and look at it and and for example how we got the components Etc you can really rethink and say well actually we can simplify a lot of things by saying for example a directive has both a linking function and also has a controller how about we just make sure that everything is a controller and then you kind of step back further and you say well wait a minute this controller on a directive is really the same thing as an ng- controller which is why we went to the direction of simplifying that part as well so all of the things that you love are still going to be there they're just going to be rearranged in a more sensible way and basic basically you'll be able to describe your application with a more limited vocabulary which is always in my opinion a good thing so I have a question about that can I still describe it the old way like not using the ad script stuff can I still write it like the way I'm used to or or how's that going to work that's an excellent question absolutely one of the things that we have learned from doing this thing for a while is that people have a lot of reasons to do different things and forcing people to do something is just recipe for disaster so if you wanted to build your application in equiscript 5 by all means you can do so if you want to build it in typescript or coffee script or es6 or any other common U languages you should all be able to do that but of course we think that if you can do it in atscript we can make it even more smooth for you but again it is not a requirement and so we are spending a lot of time designing kind of the backwards compatibility story so that you can express yourself in just good old es5 in a sane way I also get asked quite a bit about atscript and whether it's something that is specific to angular and I think we need to clarify that this is not something that's specific to angular it's something that will make angular development better but you can use it without angular so if you want to have a language that has optional type system and metadata annotations and you want to use it in OJs you will absolutely be able to do that so we are not building something angular specific it has bigger purpose so I'm going to paraphrase what Igor just said eigor correct me if I'm wrong to use aspt I don't have to use angular but also what misho said is I don't have to use atscript when I'm using angular 2.0 either like neither one of them are like requirements that's absolutely correct yes okay cool that's good because that's a big confusion that I see out there quite a bit and one of the other confusions I see is from some of the videos that I've actually watched a couple as they' been coming online too which is great cuz I wasn't able to make n Europe there was a couple slides in there about features that are rest in peace some RP slides and I've had a lot of interesting comments from people about hey what's happening there scope is gone controllers are gone modules are gone but I think if I heard you right in the talk it's not that they're gone it's that instead of using this feature in angular 2 you'll use this instead is that correct eagor yeah that that's correct and I kind of wish that this would work out better uh I think the theay of videos being available cause some some kind of confusion and and early premature reactions because now when I look at it back when I when I look at the slides I'm like oh yeah that looks pretty weird but if you listen to if you listen to the video like yes we are saying that doll scope is going away but there are reasons for it and we have a good replacement story so it's not like we're crazy and just going on and killing features we actually are just simplifying the apis and many of these Concepts like scope will be there but they will be kind of hidden you don't have to think about them you don't need to know about them they will just do the right thing for you out of the box so let me pick on one or two of those real quick if you don't mind like like modules going away or rest in peace whatever that was it's not they're going away it's that now you've got the way I read that is you've got ecmascript 6 modules so we don't need a specific angular module right exactly so if you look at the slide it says angular module and there's rest in peace and that's exactly what it means like we don't need proprietor apis to express things that we now have natively in the platform so with es6 ecmascript is going to have a native module system and I see that maybe not today maybe not next week but in the in the coming future everybody will migrate over to use this module system because it will just make things much easier it will make interoperable better and it's just something that we need to do for angular if if we want to make it s succeed long term like if we keep on just playing and creating this like propriety apis it's going to be really hard for you to integrate thirdparty components that will be built in the future but by us uh embracing these new standards we are going to be in a much better position to work with other code in the angular two version I just want to clarify one thing really quickly and that is um with the es6 stuff if we want to work in es5 then we're either going to have to have some polyfill or some build step that handles that for us then correct and we we actually are working very closely with the Tracer team Tracer is a project from Google that allows you to write es6 code and transpile it into es5 code so that you can get the future JavaScript running in today's browsers and the Tracer already contains a polyfill for the module system so the module loer is already in a very good shape um initially we started with a required JS and commonjs polyfills but now we have a proper polyfill for the es6 module loader so that that's uh what will'll probably end up using so you mentioned things like in the slide uh DDO for directive definitions and you've got controllers as well on that slide are those things becoming are they going away because they're just basically becoming classes or components in the new version yes uh yes that that's the case so really it's less of a going away than it is a a makeover right correct and and yeah like again if you look at the wording like we saying directive definition object is going away not that the directives or the concept of directors is going away know and like Mish kind of touched on this like many people think that when we started building angular we had like this Grand Vision and we knew all the features ahead of time that we wanted to build but that's not the case at all you know angular evolved over the last five years and Community feedback has been big part of this Evolution so just one example is just the component system uh when we started with angular there were no components in angular we just had templates and controllers and we were so happy that that everything just worked but then as we were starting to build bigger and bigger applications we were thinking like well you know we are using this thing over and over again it will be better to just package it up and we have these directives already and it kind of does it but and I I can't build a component but I have to do all this work I have to use the compiler I have to fish the template what if we just edit it into the directive and we did it by extending the direct to definition object so you can say oh I need this template and I need all this featur and I need the The Binding to just work and then we had a component model but really it was a afterthought and like I'm saying this at the risk of being flamed on Twitter but that that's really the case like we just learned as we were building angular and we realized this is a useful feature and now with angular 2 we are analyzing all these patterns that how people use angular and try to build APS that are specific for the scenarios so you don't have to think about oh I have directive that has this 20 possible options and for me to use it in this scenario I have to use this five so instead we're going to have concept that will just do the right thing for you out of the box so things will be just simpler well I think the last big one in that slide and then I'll turn the mic over these guys is uh dollar sign scope it said rest in peace to that as well but obviously there's still going to be something similar to that in NL to can you kind of elaborate on that yeah M do you want to tackle that one yes I'm going to tackle that one so when you have an expression you need to evaluate it and something and the scope is kind of with the hash which you evaluate but it turns out it's much more efficient or much easier to think about it if the controller itself becomes the evaluation context you know why does the controller have to put things onto a scope why can't the controller be the scope now it turns out that historically we have tried to do that in many different forms and this is how the engine controller came to be and it at one point was the scope then we changed it and became the separate thing then it published on the scope then we said the controller was as a scope and finally after so many iterations we kind of Hit Upon Us with a combination of components that really the component is the scope again this is what goes back to what Eiger was saying is that we're just trying to figure this out now this is not just yet another iteration we have tried this in angular Dart and it fits rather nicely so we have some good data points that basically are telling us that yes this is finally the the right thing and when you mentioned that that the component becomes the scope a lot of things get simplified in terms of how the Expressions get watched how you can verify things and so on so we really think this is the right approach I wanted to make a comment and then let the Ang other guys react to it so my comment like eigor kind of touched on this that the videoos kind of being delayed created some weird reactions from the community and I saw a couple reactions I thought were a little weird like uh people really freaking out that the syntax was so weird like so so distinct and like I heard things like they shouldn't even have called it angular and I'm like well it's I mean they were saying that like it was a bad thing but then they also complained that the migration path they're like there's no migration path like and they were really really mad about that when there was it was never confirmed that there's not a migration path path if anything all I heard eigor say was we once we know exactly what 2 is we'll have one and I thought it was weird because for me a migration path means that you're going to give me some time to let the old angular and the new angular live together on the same page because I can't rewrite my entire app so for me a migration path means I have some time to migrate and I thought it was weird that those two complaints were like contradict each other because the new anular is so different that's what will enable me to have a migration path like that's what will give me the time to where I don't have to do an entire rewrite because the syntax from the one doesn't look anything like the other like that's what will make it so you can slowly migrate as opposed to completely halting all progress to do a complete rewrite from 1.x to 2.0 like and I thought that for me the distinctness of the syntax and the new Concepts were awesome because it will make it possible for people like me to start writing new stuff in 2.0 while letting my 1.x stuff still exist on the page like so I was actually pretty pumped about the different syntax what do you guys think well hey this is Brad I think that's a good interpretation and maybe a good way to think about it also just I mean think realize change is hard like we're always in awe that so many people care about this thing we don't know how it happened but when we first came out with angular one we had similar reactions everyone was up in arms that we were extending HTML syntax and that we were doing things that looked like magic in the browser with dependency injection and data binding and it took folks a long time to acclimatize to this and the sort of innovative nature of folks here on the team hasn't changed and so we're going to always push the envelope but I think the question is how can we make this change at a rate that's digestible and is something folks can assimilate in places that they've based their livelihood on in in angular 1.x time frame and so you've also said that yes wait I think we've said it too we can't build the migration tools the migration story to the angular that's not finished and we will work on this and so if we can ask anything of the community is to be involved help us understand what you need and uh give us a little time to develop 2.0 and then build our story for migration from 1.3 and if I could just jump in here real quick is my career pretty much has been entirely around ecmascript as a flash developer and now a JavaScript developer is this has actually happened before so this is a real Deja Vu moment for me because starting with as1 which is you know very much like JavaScript as we know it now and then moving into action script 2 which was class based there was a lot of the same kind of push back and you know this is hard and we're going to have to change our apps and we're going to have to learn a harder way to program but as a whole on the flash platform is it made for a better language and more robust applications more stability and it was a good Thing Once people kind of stepped back took a deep breath and moved on and so I see it as just a natural evolution of a platform and this historically has happened many many times across many different uh languages and platforms is that changes hard but I believe that ultimately it is worth it so there's a couple questions I get quite often and I'll say them in a nicer tone than they've been asked to me toning it down for children what is up with the crazy syntax inside of the HTML with the square brackets and the parentheses and the pipe and all that kind of stuff yeah I can uh comment on that so first of all I wanted to say that we think that HTML should be the starting point of everything so we're not actually creating a syntax that is not HTML and if you look at the HTML spec brackets and parentheses are actually valid HTML now we think we might have to have a a backup plan for um secondary tools that won't allow you to put brackets in there so something that's going to be old text based but we want to support us uh the both of them as well the other thing is we want it to be a syntax that is web designer friendly so things that you're familiar with today and allows web designers to just add things to the page will still stay but there's a couple of things we had to change we don't really have a choice in and this is has to do with web components the syntax that we have today is not web components friendly and while it sort of kind of works it doesn't fundamentally work and this is the really the motivation behind this changes so it's not like we are just changing it for the heck of it because we think the other one is different or prettier it is that we actually have motivations with web components the last thing is if we're going to go through the process of changing it we wanted to make sure that when you look at a template you can clearly distinguish between a string literal and an expression so today when you look at a template and there is it says you know Fu equals bar it really isn't clear whether bar is a literal that is going to be displayed to the user or it is a expression and this all fits into the IDE support because if idees want to clearly annotate and color code your template they need to know what are literals and what are expressions and if you have an expression they would should be able to allow you to have a click-throughs and Etc and today if you look at something like uh NG clude The Source attribute there is a literal if I remember correctly or is it is it literal I think uh but the other ones will have a expression and this is not obvious like you have to know the semantics of individual directives before you can really reason about the template itself and so by standardizing it and making it so that you can reason about the template without actually knowing what directives are present or whether a particular thing is a web component or not it actually makes everything simpler and it allows for better IDE support so these are the motivations for all these changes so I have one quick follow question on that this is actually my own personal question if I'm doing like an NG repeat I saw we do square brackets NG repeat pipe and then the thing you're iterating and then the close the brackets if I understand it correctly you can't put a space on either side of that pipe right so that's part of the syntax yeah so is that something that I imagine I'm just thinking ahead tooling would probably be able to help with and say look you know you made a mistake here let's get rid of those spacing and because I know it's a different syntax than people have seen before it is and it's actually not even clear whether that syntax is going to stay cuz there are we have some more ideas that we're toying around with one of the issue we were facing for example is how do we hint to IDE that a new variable just came to be so for example if you look at andine repeat you know you say item in items item is a new variable that wasn't valid before the repeater but now is a valid variable that ID canow allow you to click through uh and should be able to verify as well and so how do you hint to the IDE that oh by the way I'm declaring a new variable without ID actually understanding that engine repeats declare new variables you know so if you have somebody third party who decides to write a new repeater syntax they need to be able to hint to the IDE that these in the process of writing this repeater syntax there's new variables are being created cool thanks yeah as mishko mentioned the whole ID story is it's one one of our like long-term goals um we would really like to help large teams build even larger applications this is the trend that we see at Google when we started the angular apps were you know small and medium Siz but now we are really growing into like super complex Enterprise apps and for these apps having good tooling story and tooling support makes a lot of sense so this is the the whole scalability factor is a big theme in angular 2 and this templating changes are just part of the bigger picture so one other question we're getting on Twitter is uh really looking for help to port 1.x to 2.0 enterpris is worried that they are so different and we've we've talked a bit about not having a clear migration path until is finished or close to it but do you have something that you can tell people to kind of alleviate this worry a little bit I think the thing we we've said it is we will have a path and help give us some space like I think we don't have a particular thing and I think we don't want to tell you to do a particular thing and have it be wrong and so stay tuned we'll make it public as soon as we know I'll let other folks chime in if You' got other ideas I's like to add that when we describe these new Concepts and syntax people have this idea that they're going to have to rewrite the application from ground up and that's nowhere close to what is going to happen here what you're going to what's most likely going to happen is you're going to have a set of instructions that says you know if you used to do a in the old system you will now have to do B and for most part you know many of these things will be able to be replaced by kind of a smarter Rex you know like oh yeah this thing becomes that and this thing becomes this kind of a thing makes sense so we also don't want to just tell people like lies right like the point is we're making other two as good as possible and then we're going to build a bridge from 1 three up to two right we don't know what that looks like because two isn't done yet so what we really want is your help in making two awesome in figuring out what things you want out of two and then we can figure out what the steps are in between but until we have that figured out we're not just going to say things so I think that's that's really a good way to go and there's there's a risk in no matter what you say and this is where you know I've been doing this for 20 years and we see this in multiple products and you've got a risk of if you tell people too much about what isn't quite there yet then they will call you out later because it's not exactly what you said and if you don't share enough of what you're thinking about early people will then charge you with well you're not being open and transparent so there's a balance and no matter which way you go you're DN if you do damn if you don't so I get that but in the same sense what I keep telling a lot of people is if you have feedback tell the angular team get that communication back to them and provide the feedback so they can uh use that in a constructive way don't just whine about it or you know talk in the back room in a bar with a beer um you know get let these guys know what's going on and on that mind do you guys have a preferred channel for people to provide feedback yes um so we are very active on GitHub uh we have a new repository under the angular organization called angular angular um you can file issues and proposals there we will you know look at those and have further discussion there the other way we can communicate is so we publishing our weekly meeting notes so it's a Google doc we share it on Google+ after pretty much every meeting and you can chime in see what we up to and and comment on the doc so it's not just reading what we did but you can comment in the doc and tell us if we missing something or we should consider something that we haven't thought of all of our design docks and all of the research docks uh that we put together are also open and public so we are really not trying to hide anything from the very beginning angular has been a very different Google project for better or worse you know we we always worked out there on GitHub and then pulled uh angular into Google whereas many teams do it the other way around and we found that this way we can build a better product by involving the community early by getting the feedback by getting the help it really makes angular much better and yes it's super risky for us to talk about the future of angular and it stirs a lot of controversy and there is a lot of pain involved but I still think that in long term this openness will make the project much better than if we like prepared angular 2 behind the scenes and then had a big reveal hey this is angular 2 Happy migration just suck it up this is what it is so for for what it's worth I think it's the right way to go I I appreciate and like the transparency and also understand that while I may not agree with every decision you make that it's not my call to make so you guys you know we want your feedback because we learned from a experience that we have some really good ideas but sometimes we miss things and people from Community come and and tell us hey it's not going to work in this case or have you thought about this in this other way and we're like wow we really haven't thought about it this way that's really cool and you know then you start having this broader perspective on things and eventually you end up with something much better than if we were just sitting in a single room and just give you all the answers to all the questions you might have I have to say that uh it's very heartening every time that you did say we've been looking at the way people are using this and that's why we're making the decision we're making so it's not well what do we think since we spend most of our time building angular and not necessarily building apps in angular though I I know that you guys do some of both you know it's it's heartening that you are talking to people looking at the way people really do use things and then saying well how can we simplify this how can we make this easier how can we lower the conceptual burden for new people coming into the framework I think that's really cool yeah absolutely you know people often think that like we know everything and we have all the answers but that's not the case you know learn no I'm sorry we learned from much other you know we learn from the community and it's been amazing for years for myself uh just working with all these people out there and uh sharing ideas and coming up with new ones so I would like to preserve that we've asked you guys like 45 times today what does the migration pass look like and so what I'm about to ask sounds like that question again but it's not I want to know if because I know that a two is an unknown but is there do you guys know enough about what it will be to give us some pointers Maybe not today but in the future about what could I write my code like today that will probably make that easier like an example is the way that you inject things into like an anular controller John Papa uses like a way different way to do injectables than I do is there's some things and the answer can be no that will make it like that you foresee like there's different style guides that will make it easier to upgrade potentially in the future I'm working with John on his style guide and and we are improving it and I'm providing him for the feedback so that's a good starting point using the controller ass syntax will likely make things uh easier for you and I'm trying to be very careful because I don't want to say you know do this because 2.0 will be much easier because maybe tomorrow somebody from the community will tell us hey have you thought about this thing and we'll change everything and then whatever I say today will not be true anymore and you will come to me in a year and like hey you told me to do this and it's not working anymore so I'm trying to be very careful and really like the best advice I can give you is just build the best angular 1X app you can today build an application for your users that they will enjoy and they will benefit from and once 2.0 is more stable and we have some more concrete things to talk about then we can figure out you know the whole migration story and best practices and kind of stuff awesome that's exactly what I wanted to know thanks man I have kind of a not it's half question half statement it's kind of what I gathered from this discussion today and that is it feels like what you're saying is it's a mistake for somebody to go and say oh I'm about to or I've just started building an angular app and now I want feel like I want to put that off and wait for angular 2 and you're saying that that's going to be a mistake absolutely yeah 1.3 is the best starting point for 2.0 if you are starting today that's where you should start you can use a different solution but if you want to use angular 2 eventually I think migration from something else to 2.0 will be much harder than going from 1.3 to 1 to 2.0 just because the concepts many of the concepts are just preserved and the migration will be more natural and we will have a migration story for you so as a followup to that I go ahead and take your advice I start building or I continue building my 1.3 app what will life be like for me in 5 years let me take this one I think I uh I summed it up in the Q&A at NG Europe very well where I declared I am horrible at predicting the future I I invite you to go watch the Q&A for my special story about my involvement with Steve Jobs and Tim berners Le on that that said I think like the way Igor kind of put it is that we learn so much along the way and there's no way we can know I think you know things Beyond 6 months here at Google seem like science fiction to us like at the same time we're planning for 2.0 we're going to get there with everybody involved and so the best way to know the future is help us make it awesome love that answer all right well do we have anything else that we should talk about here any other questions you guys are hearing before we wrap up the show so I think the the big things that are kind of sticking out though is you know we've heard your guys thoughts on what's coming with 2.0 and kind of talked about the migration path to death but in 2.0 uh we heard you talk about at script and things and components what about other kinds of features I mean what's the main theme that's kind of coming out of to is it mobile is it you know what what is the theme that you guys are focusing on so we declared this in a blog post maybe eight months ago where we started out on 2.0 and originally there were a couple things supporting web components is a big one we want to be taking advantage of es6 that was a big one and we've since added atscript on top of es6 and typescript and then mobile yes this is another big theme so if you we captured this I think pretty well in the keynote that we delivered and we've tweeted that out so you can go check it but those are the big couple ones there will be more and you know we may discover some more things along the way but if you want to know what it's about it's we talked about simplification performance mobile those are our big so what about material design I I got to tell you it kind of snuck up on me one day I wasn't looking and then I saw it and it it looks awesome is that something that's going to be there for 1.x and for 2.0 absolutely we're designing it for 1.3 because we can't wait and we have so many teams here at Google that want to use it and we hope a lot of external folks will too the big thing about material if you haven't checked it out is that it's more than just a wiget tool set it includes animation interaction design a full endtoend package about the way you need to think about UI and it's designed to be responsive so you can build apps that scale from the desktop through mobile and the ux concept actually extend to our smaller form factors of Google to things like watches and cars and whatnot and so we're incredibly excited about it you're starting to see some of Google's apps developed in it already and you know the new Android L release is going to embody this fully so come join us another big thing that we're putting into this besides flashing animations is support for Arya and I think for the first time we have a hope to make it much easier for developers to make accessible apps that is really cool so I I've got one last question came from Dan Wallen why are eigor and Brad so dang awesome how can anyone know that I'm not qualified to answer that it's unknowable they use awesomeness supplements in the Google cafeteria yeah when is angular gonna be on Project X I just wanted to embarrass Brad eagor and Dan W all the same [Music] sentence awesome all right well I just want to let everybody know that if you do have questions you know uh I think Brad pretty well summed up where you can go and ask those you can also add comments on the adventures in angular website so if you go find this episode you can comment there as well and really looking forward to uh what's going to come out in angular 20 and the coolness that's already in eng 13 let's go ahead and do us some picks Aaron do you have a pick for us there is a project I found that was pretty sweet it's called Julius JS it is a c-based voice recognition library that they're compiling with M scriptum to allow you to do full voice recognition in the browser like in JavaScript regardless of what browser you're in it's pretty epic Julius JS go check it out awesome Joe do you have some Pi a pick for us uh yeah this is uh particularly timely with this discussion that I'm right in the middle of and getting close to finishing working on a course for plural site on what's new in angular 1.3 and it'll be pretty comprehensive working with another author as well to talk a lot about the changes bind wants and animations and validation Etc so little self-serving but I'm feel like it's pretty topical based on today's discussion so that'll be my plural site course on angular what's new in angular 1.3 Hey Joe is that with Deborah Kata it is with Deborah she is awesome author she is very good not that you're not awesome oh come on we all know Joe can use all the help he can get you got it all right John what are your piics so obviously the picks we have to do are the you know the NG Europe videos as Brad says are going to be out some of them are already filtering out there but my angular pick would be something that Brian Ford has helped me with recently and that's the bind Two controller feature that looks like it's in angular 1.3 uh but Brian was so kind to help me try to do a backport to some angular 1.2 stuff so it's an awesome feature if you haven't read about it definitely check it out in the angular docs all right Lucas what is your pick my pick is the angular material design um I just been digging on this week I think it's just phenomenal so it's um just really excited about the tech and excited to see uh more of that just in the future what it holds very nice my pick is there's a system out there called grasshopper it's a phone system for uh businesses and entrepreneurs I actually went out and uh set up a voicemail system for the show it's not quite ready to launch but pretty close here in fact um I can give out the number now and I'll have it ready next week so if you have feedback or voicemail that you want to put in the phone number is 1877 223 0342 and so you can just call in ask questions stuff like that and we'll playback questions as we're ready to answer them on the show or feedback if you have it um really appreciate that so so that's my pick mishko do you have a pick for us yeah so the way I uh keep the stress down working with these awesome people around me is uh I go running and uh I finally found a headphones that I like they're called Aftershock and they're bone conducting headphones and the cool thing about them is that you have nothing in your ear so your sweat doesn't get into them Etc so if you guys are into running I I recommend those I think you just spent some of my money that sounds awesome yeah you wasted my money man eagor what what's your pick I have two actually so for the past week I've been dog fooding Android lollipop and and guys this thing rocks like I've been using Android for the past 5 years and I felt like I had access to awesome data but the UI was not quite there with lollipop things are changing and I can be excited more about my mobile it's like I just touch it just to touch it it's so awesome and it really blew my mind and speaking of mind for the past few months I've been kind of like training my mind and and working on having better better control over myself and I found guided meditations through headspace.com very useful so if that's something that you think you could find useful and you want to better maybe control your stress or just be better person just check out headspace.com cool Brian what are your picks so my pick is our angularjs blog post about NG Europe and angular 13 one of the cool things about that post I think is that it links to kind of all of the various documents and things that we've put been putting out so if suddenly angular 2 stuff snuck up on you this just links to just a wealth of different conversations that we had and kind of our brainstorming and thinking out loud and how we arrived at some of these different things and I think it's really good the whole angular blog actually should be my pick because there's a lot of good stuff on there all right Brad what are your picks I like this I think incredible infographic that I saw on Twitter just this morning and I think if you search for minimum viable product you'll see this image but what it is is the explanation about how to think about strategy and release because you can't release all of it at once and most teams tend to look at which features should go into a minimum viable product and what they draw is this nice pyramid about bottom you have features it should be reliable it should be usable and it should connect with my emotions well and what you should do is build not a slice through the features but build a slice from the the bottom to the top of the pyramid like go check it out it's originally uh apparently tweeted by j o p is the Twitter handle cool well thanks for coming guys I think this will really help to kind of clarify where angular is going and get some folks excited for what's coming up next thanks for the opportunity to be here it was really awesome thanks 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 check out mad Glory they're a small shop with experience shipping big products they're smart dedicated we'll augment your team and work as hard as you do find them online at madl glory.com or on Twitter at mad Glory 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 cash live visit c a c h EF l y .c to learn [Music] [Music] more [Music]