078 AiA NG Beta with Brad Green, Miško Hevery, and Igor Minar

[Music] this episode is sponsored by hire.com every week on hired they run an auction where over a th tech companies in San Francisco New York and La bid on JavaScript developers providing them put the salary and Equity up front the average JavaScript developer gets an average of 5 to 15 introductory offers and an average salary of over $130,000 a year users can either accept an offer and go right into interviewing with the company or deny them without any continuing obligations it's totally free for users and when you're hired they also give you a $2,000 signing bonus as a thank you for using them but if you use the adventures in angular link you'll get a $4,000 bonus instead finally if you're not looking for a job but know someone who is you can refer them to hired and get a $1,337 bonus if they accept a job go sign up at hire.com adventures and angular ready to master angular Oasis digital offers angular boot camp a 3-day inperson workshop class for individuals or teams bring us to your site or send developers to our classes in St Louis or San Francisco angular bootcamp.com this episode is sponsored by teller the makers of Kendo UI Kendo UI integrates seamlessly with both angularjs 1.x and 2.0 it provides everything you need to integrate with angular GS out of the box bindings component configuration directives template directives form validation event handlers and much more and yet Kendo UI tooling does not depend on angularjs so if you want to use it with angular or not that's toally up to you you can check it out at ki.com this episode is sponsored by digital ocean digital oce is the provider I use to host all of my Creations all the shows are hosted there along with any other projects I come up with their user interface is simple and easy to use their support is excellent and their vpss are backed on solid state drives and are fast and responsive check them out at digital oan.com if you use the code angular Adventures you'll get a $10 credit hey everybody and welcome to episode 78 of the adventures and angular show this week on our panel we have Ward Bell hello John Papa hey everyone Joe E hey everybody Lucas ruy hello I'm Charles maxwood from devchat.tv a quick shout out if you're interested in freelancing that's the next conference I have coming up the end of February get your tickets now so you can get the early bird pricing we also have three special guests we have eag Minar hi there uh mishko heavy hello and Brad green hi yeah I think we all know who you are so we'll skip the introductions but for those that don't know they are basically kind of the guys that are running the angular core team and uh created angular for us so we're real grateful there's been some big news since we had you on last uh do you want to talk real quick about the the beta and some of the other things that you've got going on yeah I don't remember when we were on last but on December 15th we announced beta I think a lot of folks have heard about it and we were really intending this to be the signal for folks to start development because you know our criteria was that we kind of stabilized the apis and then we'd actually tried it out on a bunch of internal Google products and we've launched some that we'll be launching more soon and so we got good confidence that this that people can actually be successful developing on it and I want to clarify something when you say developing on it does that mean experimenting with it or using it in production well it depends on who you are and you know there's there's some things that might uh prevent you from going live so you know if you're an angular one shop and you want to do the upgrade path and include angular 2 with it you know the download size of both of those might be too big and we you know we're working on total payload size as one of our our key initiatives and we'll we'll solve that soon but um as far as apis and ability of angular to be highly performant that's ready to go so you say ready to go and yet this always brings up the question and you must address it what can you say about projected release and if you can't say where're you know what date it is how would you um tell people who have to make business decisions how they should think about their choices our goal is definitely to shape angular in 2016 and we keep on well don't ever sell it man our goal is possibly potentially to it's gonna happen this year hopefully sooner than many of you are expecting but we don't want to disappoint because in the past we had the experience with setting deadlines and just making uh it impossible for us to reach these deadlines and then we disappointed many people so we're going to ship it when it's ready and it's going to be sooner than most of the people are expecting I don't want to put any pressure on you guys eor but we on the podcast team have a pool going that we announced on our last episode and we have money laying on when the ship date will be so no offense but you know do we have money laying on this we never I don't know we discuss money I I borrowed your credit card Joe but uh okay yeah I I so uh you're being very vague are I I'm just wondering because you know there's this conference coming up in say May and you know I was kind of hoping to see something a little Beyond a release candidate by then well let me just say specifically the things we must do and this has been our strategy forever is to like be really clear about well what does it mean for us to be final and there's a couple five things that we enumerated in our blog post when we want beta one of them is we need to be smaller and we've got a goal this year to be dramatically smaller even smaller than angular one but for angular 2 we want to reach basically the size of angular one so that you can have a similar download experience at final the second bit the new router is working for folks the apis work we would like to be more ergonomic and we're looking at some better apis around that there's a couple things that we want to finish in the developer guide we want to make the es5 documents and fors working on this with us make sure that it's people are able to be successful through the dep guide on those things yeah get going Ward well you're holding up to release yeah I'm all that stands between angular 2 and release I'm the I'm the block couple other things what else animations interal oh animations and i&n yeah and then we're good and we're making great progress on all those things and we'll have some updates in a month or two on on all that stuff yeah so I'm just looking at your blog post and just iterate there say reducing angular 2's payload making the angular CLI doing the component router a little more Justice some animations and then localization and IET yeah cool no no no giant big things like we know how to do all these things just executing on it now I saw some I don't know if was a blog post or a comment or something like that about because somebody wrote some article was react versus angular 2 and one of the things they talked about was payload size and there's a whole bunch of people pointing out hey the payload for angular 2 has not been adjusted yet they're still in a very you know early beta type payload not a late beta type payload size so then I later on I think it was in that same conversation or maybe it was later just something else was a a tweet somebody had said but I heard the quote about a Hello World app and there was a really tiny payload size for the angular library in that you guys heard that SPO size is that that's our goal we are the source of that rumor but I I think it'd be better for us to talk about the things we're doing to reduce the size yes we we want it to be very small and our our end goal by the end of the year is that you should really not pay for much of a library at all and that will be generating code and just what you need for the use cases that need supporting but may e or you can talk more about specifically what we're doing but before you do that I just want to stop and say I think it's it's interesting we start talking about the beta and immediately we go to well when's it going to be final and nobody actually went yay beta so so yay beta I mean none of the none of the rest of these guys will be satisfied with anything left but you know right I actually think that's a good point sh because one of the things again I keep coming back to is the person who has to make the decision today and okay that's great that there's an end goal uh the end of the year but if you were saying this is the signal to start development what should I be looking forward to in in a progression of betas what is my risk uh I know there's got to be some risk of breaking changes but how do I manage that risk what's your advice to somebody who's looking at the project perhaps they're facing down others who say yeah you know skip this angle then go to some other framework what you know how do you give somebody who has to make a business decision confidence about how to look forward to 2016 so with beta one of the one of the things beta means to us is we really want to start supporting people that developing on of pangular and for that for us that means you know no breaking changes without notification or deprecation strategy uh having clear migration uh instructions but really like if you look at the list of things that we still need to do uh for final there's nothing major there like if we if we make changes to the API it's going to be minor stuff we tried really hard actually to make all the major breaking changes before beta so that after beta we just doing polish and just you know minor auxiliary changes to the apis but not changes to the core apis and I think that's very important for developers so for for us beta really means U you know we are shipping applications here at Google uh to production with angular and we actually every time we make a breaking change we need to figure out how to upgrade all those applications because at Google there is only one version of angula 2 that everybody uses and there's several hundred developers already using uh angular 2 so you know we're not taking it lightly we're thinking about developers building on top of beta and thinking really hard about every change that we need to make and if we do really need to make it how to make it easy for developers to get over the breaking change and we actually have some pretty cool plans about how to automate this whole process so that it becomes nonissue or something noncontroversial not something that wouldn't stop developers about and start making them worry about you know how am I going to deal this breaking change um I think it's important to realize that things evolve like if you look at the web uh the only thing that is still happening is that the web is evolving and with web all the libraries and Frameworks evolving as well and I think it would be foolish from us to think that you know once we stamp angular 2.0 that it's going to be final and it's not going to change at all so I think much better strategy is to prepare for you know how to deal with evolution of the framework forward and can we do a better job than what we did with angular one and from going from angular one to angular two so somebody asks you today uh because I know you've got this question Brad I saw it on Twitter the other day I think you answered somebody asked you today this question in one of two forms I'm starting a project now should I be using angular 2 and then the second question I've seen is I'm starting a project now that's delivering in March April May June July pick a month should I be using angular 2 how do you answer those things right now and this starting new projects this is a fine category for angular 2 now whereas before made it we said no you should only be doing angular one uh Green Field projects though great candidate for angular two the question rout would then be about shipping when should I ship it and I think it's only related to the the download payload size and if this works for your app then great to go and if not then maybe wait till we make it smaller you yeah because I'm running an app right now and it's a very sample app but I see angular 2 Dev in the browser and it's not bundled it's not nothing it's one Meg and you know this is obviously early data it's very raw Etc now but I imagine that's not the state you're going to be in just putting it right out there you're not going to be shipping a one Meg file right no no no so let's let's go back to the payload size because I think that's very important like if you look at angular today the hello world application is about 160k or 150 kilobytes minified in juip and that's basically Baseline that's where we are and we know that this is really bad uh if you look at the same application withm with ular one it's going to be something like 52k if I'm not mistaken and basically our goal is by the end of the first quarter be at the 50k Mark and that's gzip right that's gzip Beni yes gotcha gzip minified around 50 k we think we can do that by by the end of March uh and that would be good enough for us to say you know angle to is production ready but we have a goal that goes past the 2.0 Mark and that's the yearly goal by the end of the year we would like to get down to 10K 10 kilobytes this is a stretch goal we're not even sure if this is possible it's a little bit crazy but I think we have some evidence that shows that if we think out of the box and think about things in a very different way than what we how we are used to think about payload size and uh assembly of the application we can actually reach the 10 KOB cool thank you so I'd like to look at the other dimension like you know most business people don't care about Hello World they want to build you know build an app and and you guys have been using angular 2 for some time now internally to build uh Google apps so I think one of the other sort of business questions is is A2 capable of supporting a large serious application that has real demands so what can you tell us about the the kinds of applications uh that you're intimately familiar with that are they're using A2 today yeah so there's there's two real big apps that we've been lucky to work with one one is this is Google's internal CRM application that our 10,000 plus sales folks use every day it's called green tea you can't see it out externally but there's about 100 developers on the project and it's got 500 components written on angular 2 and we're uh it's zippy and nice and we're really happy to have them giving us feedback and they that they were the first and earliest adopter so we've been designing angular 2 and the apis to work at that this scale for a long time our other externally facing product not shipped yet is this uh other thing that Google makes money on called AdWords and AdWords is writing their entire UI on angular 2 now they have come a long ways not not shipped but not too far away and they have hundreds of developers um using angular 2 and this is another another step function in terms of the size of angular where you know all the nice cases for really big apps and reducing size is important they've got some really aggressive latency goals um and so things like lat like uh lazy loading and optimizing all of the components uh making sure that that you know every part of every page is going to perform well uh so we had that experience there so we're pretty confident this going to work really well in big Enterprise applications can you comment a little bit about what it's like to coordinate uh you know 100 developers around uh around angular 2 is that have you learned anything aside from like it's always hard to coordinate a 100 developers but I mean anything that people can take away from trying to work with angular 2 at that kind of team scale uh a couple things maybe so so one is that actually lazy loading is really your friend here because if you can compartmentalize your app into separate Hales then an individual development section can only load the part of their app they care about this is great for running your tests and great for managing your dependencies and just how much do I have to conceptualize in the whole project um another was around migration because these guys on PT they started on the previous version of angular and then mve to angular 2 like one of the big realizations after trying to do it a couple ways is like you got to migrate the services first and you know otherwise you're trying to build things your front end needs without the base being there you you sorry Brad you mean like the backend Services web services so the service layer in the browser because it was an existing app all of the server side apis already existed we just didn't have the business logic in services to uh in the angular 2 style to support them Services it kind of leaked into the controllers and now you're trying to have a clean separation between business functionality and the components yes and so make sure you've got Services written first for any kind of migration and then then build the component pages on top of it what language are you guys uh is your team are your teams writing it in so the team is writing in DS which is you know it's popular here inside Google I think for external folks it looks very close to typescript and the apis on angular are exactly the same so I don't expect you'd have a different experience we also starting Pilots with typescript here at Google and the first teams are just being boarded as we speak so when you guys are building these apps or these other teams are building them I imagine releasing angular 2 is different than releasing angular one right when you guys had angular one you didn't have this H history of massive experience and millions of people using it already what have you kind of learned along the way as you're putting out angular 2 that's kind of changed which I me it's very different now right now you're kind of expected that bar is really high so what have you had to deal with as far as what's been challenging there well we had we had a funny little Kur fuffle where we we took down a lot of Google developments once well because a lot of people depend on angular but anyway I mean so different on angular 2 because you when we started we we were nothing nobody cared about what we did and now everybody cares and they're in our business and micho laments those days when I could just make changes freely and the m was not a thing and upgrades was not a thing people didn't have opinions people didn't have opinions it's far better now honestly like the end resulted way better having all these other input sources yeah back in the days like it was just me and mich arguing about stuff in a very interesting way um and you know these days it's like we get so many opinions and we we get just flooded with opinions so like one learning from angular to is do not start a discussion unless you have an opinion already because you're just going to be flooded with lots of opinions it's much better to propose something and then have people either create cont proposals or tweak the original proposal then start Greenfield because it's impossible to do Greenfield brainstorming at the scale I think that's the biggest learning that I my learning is that people have opinions about syntax but nobody cares about semantics but reality the thing that matters tax is something used it is on that exact note I was just listening to somebody the other day who was saying I chose uh I don't know if it was a relia react whatever it was because I looked at angular two and I liked it except I couldn't handle the syntax and I was like really that's the reason you turned away it's I hear that man you know I think it's freeable it's your initial gut reaction that tells you something about it you know whether or not you'll be successful or not at it I think you do have to think deeply about what is what does the actual end result mean which is why Mich goes like semantics over syntax and that's the little syntax you know we do spend a lot of time thinking about syntax making sure it makes sense and it upset the least number of people but it's not the whole story right actually one one cool thing about angular 2 which we can talk about is that the way we build angular syntax really doesn't matter that much what matters is the semantics and with angular 2 if you want to custom template syntax you can actually do it it's not that difficult to take a piece of angle and replace it with a your custom piece and all of a sudden whoa you have your custom syntax uh the only thing that matters to us is that the syntax is semantically compatible with angular which is not that difficult like if you you look at many of the templating languages out there like I think compatible well that's really good to know because I wanted to get started on the latsch templ but after you that's how he going to write the that's how I'm gonna write it in LA CS there we go so you know um one of the things that many of us have found when we' G to go out and talk to folks is we really want to get them excited about talking about angular 2 but we stumble at the door with the tooling that's in front of it what can we expect to have happen there I mean some of it may just be education because every body stumbles trying to figure out how to how to use these loaders and stuff like that but how do you guys see what's the future look like yeah so this is definitely the problem that we are looking at and and working hard on solving and to to understand what's actually happening is there there is this fundamental shift in the web technology happening because there are several new apis and specifications been implemented by browser there's the EOS script six with with lots of new syntax that is new to to developers we have new module system um we have uh we're introducing typescript um which we hope that eventually will actually become more than more than just uh open source project uh we hoping that it's going to become part of the EOS script standard uh in some way or shape so there are many things that are happening in developers like need to absorb all these changes at once and that can be overwhelming lot of like you say a lot of tools to configure to get all these things working together right right there are lots of tools that you need to use because most of the browsers don't actually support all the specification apis that we need so we be using transpilers to write the code in the new way but still running on browsers that we have today uh which requires extra tooling extra configuration build systems and test systems it's pretty complex so here's what we are doing we are working with different partners to simplify the whole tool chain um the the best example is the typescript team which we work very closely with and we are simplifying everything so that you know if you're using mpm if you're using um angular there is very little configuration into the other box to use typescript to transpile either your typescript code or even es6 code if you choose not to use typescript you can still just write es6 code and have t typescript transpar to to is five we there are other examples of these Partnerships happening but more important we're also taking all these tools and and integrating them into a project we call angular CLI and angular CLI is is a common line interface for building angle applications um the goal here is really to build a tool that will allow you to start your project expand your project test it build it deploy it all with a single tool where all of these other tools that you need to get all this stuff done are already integrated for you uh if you choose to customize stuff that's okay if you want a custom test Runner if you want your custom um SAS processor U CSS processor you can you can do that but out of the boxes should just get some good experience that you should be able to customize more of you you did mention early on in the conversation it's probably worth re-emphasizing that somebody who's coming at this from equiscript 5 you know they've been programming a JavaScript the old JavaScript way and we're going to make sure that they can continue to program with or too in that fashion if they so choose right yeah did I mention there's a guy named W working on docs for that yeah yeah uh you know uh they want to hear it from you man they don't want to hear inste their goal that people should be able to stay with PS5 if that's their their desire we are focusing on TP scrip end of things because we see a lot of advantages of it and it's just es6 if you want to go to that but yeah if if folks want to stay with what works in all the browsers today without a transpiler es5 is the way to get so I've got a followup question on that we I've seen the Syntax for es5 and compared to typescript I would say it was hard to objectively say that it's anything other than you know certainly it's more wory and I would say it's you know a pretty decent step down is there any work specifically going to be done on that to make it a little bit easier or is it what it is because that's as it's going to get an S5 yeah the work has been done already it's called is6 that's that's a great Point seriously like you know es5 version of angular is not more worthy because angular is more worthy in es5 it's because es5 is more worthy than es6 so if you want code that looks better that is uh is less verose use6 or attach and if you really want to look at the es5 just transpile it back down es5 then look at it right well I certainly hope that very few people decide to author a lot of angular 2 and es5 just because I think this is a great opportunity for people to move into the modern day the important thing is to realize that this is not angular doing or you know angular is not creating es6 and TP script these things are happening regardless of angular and you can choose to either stay with es5 and angular will be there for you or you can go to this new language that we think is much more much better and will will make you more productive and once you learn it you will get better version of angular with it yeah man we could inter we could take out the word angular this whole conversation that we're having right now and insert Aurelia Ember whatever you want it's the same problem yeah and my experience has been that it's the stumbling around with transpilers and the whole complicated build system that gets in the way before I can get started with my application that makes me feel like hey too much to learn here why can't I just go with what I know for a while and I think that's why he's building angular CLI yeah I think that's I think that's part of your answer to this question yes but but we're still going to teach people how to how to roll an es5 what do you guys really see the usage percentage of the CLI being like near 100% of the people who are doing angular 2 will be using the CLI or less today today is very little we don't have metrics yet uh we're not pushing the CLI yet because the in the current state uh the CLI is uh I call it a prototype it's an experiment what we did is we partnered up with the Ember CLI team to get off the ground quickly and build something that does the basic stuff you know scaffolds your projects allows you to add more components to your project provides you build system uh Library load development server uh has a testing buildin and has a deployment to GitHub pages and Firebase uh built-in but there are still things that are missing we don't have optimization pipeline set up and there are you know many things where Ember shows up and it's kind of weird where if you don't have the background and understand the partnership between Amber CLI and angular it's so you know you would be surprised that you see Amber in your common line so there are these things that still need to be fixed up we have a plan for this and uh we actually planning to get the CLI into shape we could uh replace most of the documentation that we have uh today developer guides to use CLI by the end of this quarter so Switching gears a bit Lucas and I were having this conversation about the designer story for angular 2 so you might have like things like inline templates uh they're considered best practices by some people and other people not such best practices so do you want to go the declarative route or imperative context uh how do you see that playing out with angular 2 any recommendations besides mine and I mean this comes down to how much HTML do you want inside your JavaScript yes that's a very very valid question Bo I don't know where this came this idea that that pinline templates are the best practice uh it certainly is easy to write line templates in es6 because you have the actic so you have Uline strings it might be convenient for the purposes of of our documentation to inline all the stuff you can kind of visually see next to each otherly I wouldn't want to be editing a very large file HTML file inside of JavaScript because well the editors don't understand the the structure get better web kind of has this mode where realizes that it's HTM of a string and funy fancy key strokes you can get that right but like in general it's just better to have an that's dedicated that looks at the extension kind see know what it's done so I think for for most large scale projects I think having a proper separation of HTML and JavaScript is probably the proper way to go it's also better when you have so small projects that it's probably I'm the developer and I'm the back end and I'm the ux designer and I'm all these people but if we you if we are on a bigger team where I actually have some uh some ux designers on it it's much nicer for them to deal with just the template in the HTML aware tools that they already know and you you can go from their prototypes straight into the development workflow without changing anything in angular which is like for big team and and being inclusive of all your roles I think it's very nice to have external temps now what about things like NG Temple cach that existed in the plugin for like angular one so how do we handle things is that where angular c will help us out moving forward we're not have to load our HTML and CSS in every page yeah sure so so the long goal is that you would compile down your application and during the compulation process we actually move the templates into the inline templates but even going a step further which is we actually generate all the source codes necessary to create them so when the you know when this new world were angular in h world is about 10K big or something in that range happens the idea is that what we Shi down to the browser is all one huge javascri file that has all the primary assets inline into them whether small Javas one small I'm sorry Javascript file depends how big the app right where all these assets are inline in both stylesheets and HTML obviously images will stay separate yeah because we want this balance right and that's guess where I'm curious of where this whole tool is going to end up we don't want to load every single file individually everywhere meaning every component's got CSS and HTML and so on but we also don't want to be loading one massive file as you said so by you break things down but for point of view of the performance you want to uh download as few files as possible and with hdp and so also what you want to do is you want to skip the necessary compilation phase so angular to and so you want to perform the compilation offline and just ship the final product which is looks almost as handwritten application code that somebody read in vanilla JS where all the things are hooked up and no compiler is necessary no expression part on and this is actually how we want to the the code size the payload size with the offline template compilation as we what we call it we'll be able to just take the HTML turn it into JavaScript code and then throw away the angular compiler and not ship it down to the browser because it's not necessary there anymore so this allows us to remove big chunk of the code base and just don't ship it to the client and we can do the same thing with Di and with some other pieces of angular and this is part of our strategy to reduce the code size and before people get too worried about us Cod generating too much stuff we actually measured and it turns out that the code generated stuff is smaller than the stuff we are dropping so than the actual templ yeah we're not going to be generating like megabytes of code K so I'm looking at a couple apps I've built lately with angular 2 and these are just apps I'm kind of building out I'm working on a course for angular 2 get moving and I've been doing some samples and some hackathons things like that one thing has become very painful for me right now is while I'm really used to angle 2 and I've gotten over the tooling side of things my own workflow it's hard for me to find a good way to put UI components in place uh you mentioned animations aren't ready yet that's one of the things on your list but what about just UI components like if I want to make sure angular material in version one was awesome is there a platform or a strategy for getting that ready so the same the same folks who have built the angular material um one are now working hard on the angular material 2 Suites and they're also shooting for initial set of those in a couple months so we're going to we're going to be seeing the you know early parts of their efforts like you know very soon but then something we think very usable in a couple months sweet so I don't have to stay with bootstrap no well you can't like and actually there's there's a couple different versions of bootstrap components for angular 2 already done I just saw a prime faces version of components for angular 2 so you there are a lot of other options you don't have to go you know material design although we love it here uh there are going to be a lot of different ways you can do it the the ouo folks have announced for angular 2 the Kendall UI folks um you'll have options sweet so we are going to see the see all the control vendors get involved with adapting tangular too I think all the ones that I've seen and there's a new suite of fabric UI stuff out there from Andrew Connell and I think they're going to be doing angular 2 version as well so yeah lots of great things to rely on this is somewh delicate issue because there are enthusiasts and then there are um people who are as we say from Missouri and that's about observables some people just can't wait to see observables and some people are just shaking their head so what's the angular position on observables and how to how to make these audiences comfortable because we've been talking about it a lot on different shows and and and I can tell you that many of us have had our challenges trying to wrap our heads around observe in a way we never had that kind of trouble with promises so how long did it take us to adopt promises overnight well the script was invented in 95 promises were like in 2002 so what's all right I'm gonna I'm gonna call BS on this one right away all right because you look at the apis of promises and observables and you just look at it and promises are vastly simpler than observables and they don't have as nearly as many options so you know I think there's still there's a whole lot of developers that haven't even quite grasped promises I know I can teach promises I always could always could to people who had never seen them before in an hour or less and I'm not sure that I could do that an observable now I'm not knocking observable I'm just sort of laying it out there that I think it's not fair to say that these are these are the same animal they're quite different animals I'm just wondering how you're going to put people in you know what what's the position uh overall from Ang we like observables for events or events that are are happening more than once definitely observables is the way to go one thing that we are experimenting with is you know could we use observables exclusively and on these promises this is uh you know controversial and right now we're keeping doors open in both ways but you know back to my question promises if my memory Source very well were created in' 70s there was a big Spike of interest in 80s or 90s and then finally like 2012 uh the JavaScript commun to realize that this could actually be useful to solve problems that we've been having for two decades then prises took off observables and similar position except that observables are much more powerful and with that uh the API surface is uh significantly bigger I think the challenge we have is how do we explain that to developers that the bigger API surface actually worth it and if you start thinking in terms of observables you'll be actually much more productive you will have much more flexibility you will be able to do things that you cannot do with callbacks or promises the the thing that I've seen that convinces people is like the simple cases it looks way worse but when I'm trying to write real code where I have to do retry and cancellation all these things it's whoa it's a lot less code and way easier to read now talk to anybody who buil a real time dashboard that tries to aggregate multiple streams of data uh that are you know coming in and there are the data sources are unreliable you need to reconnect to them it's almost impossible to do this correctly with promises or callbacks yeah everybody's kind of on board when it comes to streams I think we can all all all knot our head at that it's the use of it for crud that becomes challenging for people who have gotten used to promises and and I and I yeah so I want to jump in a little bit too on this because I think um I've been doing zbl now with with angular 2 and it's it's really been my first foray I'll be honest with rxjs and Cal angular to and the struggle I've had is not the happy path I've been using it exclusively now for getting my data and doing things with events the struggle I personally had is when I try to do what I call real world scenarios is I don't just call HTTP and it works sometimes I get errors back and where do I bubble those errors in the surface or in the component or I use an async pipe and then figuring out how do I handle exception handling with observables and that's been I found that that's not very straightforward at least to me so I think that's an area e you hit it on the head is how do people show people the value in using these and that it's actually G to be helpful and I don't know the answer to that right now I I think you're totally right and I think there's a lot of work to be done to make you know debugging and and error handling better but honestly like if you look at where observables at today compared to promises observable are already in much better shape we have a specification for promises that doesn't allow us to have Global air handling uh and you know d39 is discussing this only now whereas with with observables um you know observables and a specification and error handling capabilities there are much better and to say my experience has been painful the exception handling side I've actually kind of enjoyed the other side is I've actually kind of enjoyed using obals to get the data back and to send data around my app app in angular 2 so I do think people will adapt to them but on the other side I think there's a friction we have to be aware of that not only you're learning angular 2 but now you're also learning this new thing yeah is our responsibility to remove this fiction yeah but you guys don't own RX let's be clear right it's not a Google thing observables aren't your thing it's just something that you're adapting and saying this is useful and angular is that correct yeah but we collaborate with the folks on the people working on our apps a lot um on a daily basis it's probably worth pointing out for our audience that um you can always take an observable and go to promise on it in your back in business or just substitute a then for for uh subscribing it's usually almost the same so uh we have to help people get there and it's it's not that it's impossible I I I'm not knocking observables I'm just saying it's it's a hill to climb and we need to face it and figure out how to get people up the hill so let's talk about angul so I agree it's it's been um I spent a lot of time there but you mentioned the router a little bit eagor I believe it was you who mentioned it or maybe it was Brad we're talking about things that have to kind of round out and get ready for the release can you tell us about kind of what your plans are for the router and why you feel like you need to do a little bit more work there yeah I can definitely talk about that a little bit the biggest challenge I see is um if you look at how we configure routes today and how we generate links to all these routes you know things work I feel like the capability wise and feature wise the router is pretty solid like we have all the right features you know we can tackle scenarios that we could not even imagine with angular one so all of that is good I'm sure you know people come across bugs and will fix those but but uh architecturally and conceptually I feel pretty good about about the router one thing that bugs me is that the way we express the configuration and how we create links it's a slightly errone maybe slightly is a a very very soft way to put it I I think we can do much better now the question is how to do monitoring and one of our goals with angular 2 is you know make it tooling friendly make it so that we can analyze things statically and do as much work as possible up front so that we do very little work at runtime and this allows us to you know get perance and create smooth uh smooth feeling applications I feel like with we we can do better in this area so especially in statically analyzing the links and statically analyzing how different parts of applications are interconnected and this is something we're exploring like could we create an API that doesn't rely on constant strings but rather we have symbols or objects with methods that we could use for generating methods I there there's a proposal that is on GitHub that kind of solves this problem but that proposal is running problems with LA loading like if you get all this tooling and static analyzability how do you do lazy loading in such work in such world because as soon as you do lazy loading you don't have a single compilation unit you're basically breaking application to multiple entry points and multiple compilation units and that kind of affects Auto completion and all the static static properties of the application so before we decide what exactly we want to do with the routing we decided to tackle the lace loading first so our strategy is you know figure out how to do la loading in general uh how to De it you know end to end starting from compilation all the way to to loading and and uh joining the code and making the code interoperate in runtime and once that is solved which is what we working on now we'll go back to the router and and look you know how does the the router fit into this new world where the laser loading is properly defined as rules and let's apply these rules to the router to be clear lazy loading works and we're using it in production into various apps what eag is talking about is making work end to end with your package manager the router and so things just can happen for you and you don't have to do it see that if I hear you right then Brad what you're saying is that you could just Define your app and your routes and your app just by nature of how the router component works is it would automatically figure out how to L you load things for you have to do nothing yeah well one of the goals on our 10K plan is to load routes lazily so that you don't pay uh upfront cost of downloading your entire application when you just want to render one screen so much sense to me because uh so many of the routers I've seen in the past required a lot of configuration all the configuration up front and made it very difficult to change what's available later whether it's for lazy loading or because authorizations changed uh and you wanted to open or close certain features so the fact that you're starting from that larger problem and working back to the router just makes so much sense to me it does and you know as somebody who just just last night I was working on a routing example for a certain documentation example uh it hit me as I was trying to explain how to do routing with angular 2 well I get it and it works the number of things that I have to configure and I'm not just talking the route config I'm talking about the different things I have to import like the router link the router directives the router providers uh and then the different options on Route config I'm still making mistakes along the way especially when I do like nested routes for example I've seen I've done this three times it made me feel good the other day a very respected friend of mine who's very good at angular 2 made the same mistake of I had a route and I actually pointed it to itself and I know that doesn't work but somehow because I got so confused in the route configuration I did that and of course the aor was like dude what are you doing so I think the problem isn't isn't that the router's bad it's that to do routing well you have to tell the router a lot of information and right now it's a lot of manual strings as you are pointed out but if there's a way to make that simpler or better I'm all forward I think that'd be great for everybody yeah that that's definitely a goal like if you look at the evolution of angula 2 we started with more verbose but very explicit non ambiguous syntax and then slowly shaped off stuff as we got experience uh with with the semantics of the code AS Mish mentioned you know we are really focused on the semantics the syntax can always be improved you can change syntax a completely different syntax if you want to the sematics are very difficult to change and especially when it comes to migration and we see this you know very clearly with angular one going to angular two the syntactical changes are not a big deal it's the semantical changes between the two that will be the biggest challenge for for us and this is what we a focusing GE for speaking of syntactical changes uh I just my day wouldn't be complete eager unless I I heard you say the term banana in a box on this podcast I think it was you who uh coined it wasn't [Music] it oh we needed that definitely needed that moment yeah Victor sapkin is our functional programming fre expert no I I I I think both are true so he was the one who introduced the two-way finding syntax and we need to be very careful about how we talk about the we finding because I see people being confused about how we how we talk about it we have a syntax that allows you to express One Way finding both directions let's call it that way and and thex looks like a b banana no it's banana in a box if you can put a box inside a banana you're welcome to try you know what I hear aong I I think we need word to be theer and sing song oh goodness okay long like history and functional programming where there's a banana operators and like it's it's if you want to geek out just look into banana stuff un functional programming you will find interesting SS I can see that John was gonna have a dance we're gonna have to make a conference and let's be clear the square brackets is what we're talking about right square brackets and the curly parth parenthesis yes whatever they are so I have a question that I like each of you to answer one after the other and that is what is the myth about angular 2 that you encounter that you would like to explode each of you gets a shot at that question uh you know the funny one I get all the time is that uh the angular team might be going away it's not really specific angular to but you know well that's true isn't it you want to say why well I don't know why I think like people well I think people are wor they want to know can I rely on this going forward well what what makes them make I don't know well okay so like look Google's a big company and like not all of our products live forever and so they may look other things that we've done like oh that thing went away there's no more Google Reader uh which we're on this team all very sad about but we're a big company and so they look at that and like well look some products went away we may not have angular forever so who else wants to crack at that question the myth about angular to you wish go Google doesn't use angular oh I heard that one yes yeah oh godbody angular that's a good one right it's not because there are certain Google products that don't use angular therefore Google doesn't use angular right right we know we have not converted every single line of source code to angular here yet you know it would be actually much easier for us if Co it not use angular because we wouldn't need to do all these upgrades and migrations like you know in a weird way I kind of wish that was the case but uh it's it's far from true it's you know we have 3,000 applications or something crazy there's a lot like all the like most of the big internal stuff we use like green tea like our our Bugan eyes runs on it and all of our HR tools and uh hiring tools hiring tools the whole cloud cloud google.com the whole thing it's external facing and but let me just plug um made with all of the world so let me invert that for a second and say if Google's got such an investment and angular to why is it bothering and why is it working so hard to develop an angular for the public to use which is a tremendous burden right I mean that's a lot of support good question that's easy because that's fun for us we get to do it so Google do pays you to have fun oh okay it was a good question to answer don't ruin it I mean we're glad you're doing it but it's like why are they G why are they working so hard to make it easy for me who does not work for Google and John who doesn't and all they right why are they making it so working so hard to make it easy for us to use angular there are many answers to this um I think when people ask this question they think that maybe we we are plees in the cogs of a machine that get thrown this way and that in Google it's kind of us who decide to do these things and I don't know I've been here for a while people trust me to do things things and we get to do this this nice thing but the thing that we like about it and I mean eor mishko can jump in is that we get tremendous feedback and having a platform that's built with the input of the world is so much stronger than one that is purely you know inward facing where group think can dictate that it's good when it's really not yeah and I think we are so lucky to be in this position where we are really on the boundary between the internal world of Google and the external world of Open Source JavaScript development and angular is a result of fusion of these two worlds because I don't think we would be able to build angular if it was purely open source project that would be just hacking on open source uh know free time uh and it would also not be the same thing if we just build it internally and exported it like you know here's the code base you know go go ahead and use it it's really the the fusion of the Two Worlds that brings the magic and and makes angular work and now you know through angular we created all these great friendships and Partnerships with with other teams like T GP and RX Amber and you know lot lots of other people that helped us influence where angula is going and you know how it's evolving and how it works internally and I don't think it will be possible to do it in any other way than we are doing so I have a related question on kind of where things are heading towards for you guys and that's you guys mentioned these other teams you're working on and react is another one right I assume you guys talk with them yep react has a thing called react native and you're building mobile applications whatnot that's pretty cool is there going to be like an angular native or where are you guys leaning where do you want to point people towards to build angular two apps for mobile so we we've been working most closely with a company called terer who those the guys who make the Kendo UI components for angular and other platforms but they they have a platform called native script and they've been building this a top angular 2 so you can build the same sort of services and components that you do but all with an actually front and rendered with Native UI components and they've developed This and like we they have a lot of good examples and it's to my knowledge ready to go we we've also been working with the react team on react native and that's not as far along but I'd love to see more Investments and E maybe you got some friends working on this also yeah yeah so so we we have there are folks working on the react native angle of this there are different Frameworks or there different ways to build native apps and I think there will be rational reasons why you might pick either of them depending on your needs you know where where the I don't know if I'm somebody can slap me that I'm incorrectly categorizing these things but you know one aspect of this is the nativescript guys built a lot of their framework to make it possible to build one app that runs great on multiple deployment plat platforms you know IOS and Android and I think Windows mobile will come up as well whereas the the react team is much more about hey we're going to provide a platform specific API that you can use to build an IOS and Android app I think there's there's reasons you might pick either of them yeah we had uh TJ and Burke on both this show and the JavaScript jabber show and we actually have a react native podcast on the devchat.tv network so if you go to reactnative radio.com you can check that out I actually kind of send the react team a bunch of Christmas cookies and Christopher over there it hates me because I told him I was doing this and they never showed up so I still nice so one of the questions I'd like to talk about is I think that a lot of people when they learned angular one there was sort of an implicit guidance into architecture design it was very light it was very un relatively unopinionated even for angular which tends to be considered a fairly opinionated framework or at least moderately opinionated and I think that with angular 2 it seems like there's less guidance in the architectural like build things here put things here put this type of logic here and here what are your thoughts about that comment it's coming I would actually say that in angular of two we're going to have more opinions or more recommendations than we had in angle one like just if you look at angular one we didn't have a package manager that we would say like this is the package manager that you know we stand behind and you should be using or we didn't have a module orderer that we were saying like this is the module order you should be using we left all these things uh open because at the time when we were building Engle one there was no clear winner it was not clear what is the best for application and depending on the scenario on the company and the team that you were building the application with the answer was different in angular 2 many of these things have Sol defied you know there is uh just one main package manager out there for JavaScript which is mpm the module loader and the syntax how you express imports and exports have been specified in the Eos script specification so right now we have just the syntax the modu load is still on the way but we're not not too far from there so now that we have many of these you know fundamental issues resolved in a standard way we have much better Foundation to build the rest of the recommendations on and uh the reason why we haven't had any strong opinions about how to build angle to Applications was because we needed to give a developers some freedom to experiment and see you know what is the best way to create my directory structure what what is the best way to you know what kind of patterns to use uh I think by now we have a pretty good idea of what works and what doesn't and a focus before angula 2 final will be on writing down these recommendations and building them into angula CLI and and building the rest of the tooling around these recommendations okay now Joe I know you and so I think you meant some something different from your question what do you think I meant asking are we going to promote traditional oo style architecture or a more functional reactive app architecture that's a great question to ask as well like I said I I think that's the question you wanted I know the question Joe's asking we've had conversations about this so you guys and I have so I know that this is uh something that you guys do have heard me talking about before but I'm just curious to hear you know where you guys are at in this because I do think that uh you know architecture matters right and we definitely have been living in this o world and now uh more reactive architectures I don't know if it's taking the World by storm so much as it's really showing up in a lot of places it's really being talked about in a lot of places and we've been having this debate ourselves here uh on this podcast as to whether there's a throwing the baby out with a bathwater thing going on but I mean we're interested in you in whether you guys are I think that's a great question BR so do you folks have a position on that or are you going to be agnostic about that yeah so we are supporting both and we've actually designed angular specifically support I have some opinions and you guys jump in like everyone here should opinions but so I think we haven't seen any big apps done in functional ractive style I would like to see some big apps done in functional ractive style since we haven't seen them I can't say wholeheartedly yes you should do them this will happen to you if you do it you know at the same time in the micro examples that we see uh there are a lot of nice properties of you know the functional reactive Style in testing and data flow and debuggability and but you know because we've and at the same like I think Victor sack in our team which eer highlighted as our expert um he has some nice blog posts on you know when to pick one versus the other and like I think it's actually not going to be a uh I'm purely one or the other but I think it will be a mix and kind of in the leaf nodes it makes a lot of sense to have States and in the core of my app maybe I would love to have an immutable state that I deal with functionally but the jury's a little bit out and so we are supporting both um we will have a bunch of blog posts I've seen a lot of other good people using Redux and other architecture Styles and things built on RX specifically to do functional Style with angular 2 um so I'm excited I'm excited I remember when we moved to objectoriented programming there was a lot of evangelism and uh and help we need to give people I think we'll need to help people get to the thep style I think we should also be fine with a large application is because uh you know when we say large application we mean you know hundreds of developers and hundreds of thousands millions of lines to yeah that's right so like on green tea no we're not using any reactive programming yet cool excellent answer you know one of the things I've I've been asked about I'm sure you guys have been asked about we go from the sublime back down is angular one angular 2 migration now some people heard the message some people haven't heard the message and some people those people who have heard the message about the NG upgrade and the tools would like to know are those in a ready state are they scheduled for dramatic change or or just incremental Improvement so what's today's story about uh upgrading for mag one so the limitations are so so angular one if you want to upgrade we can upgrade any kind of component or service by wrapping it into angular 2 the kind of limitations that you have to deal with there is that any one Dam element is really owned by either angular one or angular 2 uh so things like um a directive that only kind of augments existing element clearly that cannot be migrated in automatic fashion you can certainly make a copy of it and rewrite it and have two copies of it running inside of inside of angular one and angular two the other area which is kind of limitation is that Ang does support the dollar compile function or any kind of a similarity but short of those two those things mentioned the upgrade story Works nice it is something that we recommend you try give it a look and we we're actually working with uh several external and internal teams to gather some more best practices because we do want to be able to hand people some recipes and things that would be helpful like you know with green tea we learned hey do your services first we want to have a similar set of nice things that will be helping people get along faster and easier and you know it's just another um thing in that your toolbox that you can certainly try converting the lead components over to angular 2 there's no need for upgrade right the upate really comes into play where you get into situations where you need to use the same component from both angular one and angular two for whatever historical reasons right and so it's just nice to have this extra option but you can certainly um just you know start with the leaves or start with the the root of the application and just convert that one the other one after the other there you don't need you can just do it consequentially so think about like is good at breaking C circular dependencies so that you don't have to be stuck going forward when when you're mixing angular two inside an angular one that's right so can you kind of just explain to people real quick the the difference between what NG upgrade and NG forward are uh so NG forward is a community effort whereas NG upgrade is a core team effort uh NG forward uh I believe it teaches angler one the Ang 2 syntax but you keep the Ang one semantics whereas NG upgrade actually allows the two Frameworks to Coexist on a page and allows seamless uh kind of back and forth collaboration uh for the two Frameworks so out there there's a whole large community and I honestly don't have any idea how large community is but I imagine you guys do and you hear from them all the time will we hear from you guys this year at conferences or in others out there and do you have anybody on your team is kind of taking lead on the developer Outreach yeah so we person so Jules kemer joined our team uh late last year and she has been working on figuring out which conferences we're going to be at and it's gonna be a lot more than we were in the past years we've been kind of hiding out and while we we went to angular specific conferences last year we really want to go to places that maybe haven't heard the angular 2 story maybe not even the angular one story and you know hopefully you you'll see us um maybe not the whole team but we do want to send folks to a bunch of the the places that we've not been in the past can you be more specific than that ah okay um I we have a big list we need to get it published it's gonna be public yeah yeah we'll publish our list are you going to fluent uh I am going to fluent yeah I think I'm gonna be in the keynote so I'm excited about that okay NDC how about that one I don't think it's on my list man all right here's the most important one because this is by far the best conference out there conference and I totally surprised you with what I said didn't you didn't I you did you threw me off Joe are you going to that conference we we've been there in the past I think like Brian's been or mich's been Brian I also been it's kind of cute the first time you hear that conf but it gets old I just love going on water slides in between talks yeah Joe Joe gives his talks in his swim trunks yeah yeah yeah this is a much this is a much less important one but are you by chance going to ngom yes what is oh I'll tell you later we'll tell you when you're older right so so my question is I think people are pretty used to hearing announcements at some of these conferences especially some of them like angular connect or comp and with the beta being out there are there going to be any big announcements or big surprises at any of these conferences or is it going to be pretty much just here's the progress we made and more or less what you expected since it's in beta I it depends on if you read our meeting notes or not I think he's just sneakily trying to ask if final is going to be ready for enom no yeah so we will surprise people who who aren't paying attention to all of our completely open progress oh okay it may be very surprising to them uh but if you read read GitHub like nothing we can do can be a surprise because it's all you can see every move we make I suppose that's true all right almost every almost every discussion that that that happens in there it's really it can be overwhelming to try and stay on top so just don't read it and then it there'll be a lot of surprises yeah it'll be super nice all right well I know that uh some of some folks have said they have to go soon so let's go ahead and get to the pic John do you have some piics for us I do there's an awesome new npm module out there that I want to tell the whole world about because the owner of it is so proud of it it's an awesome inmemory web API up on npm and the author is actually our famous Lord Bell it's so if you need some kind of end memory web API to run with definitely check this thing out I'll put the link to it inside of the show notes it's called A2 in-memory web-api there's not enough dashes in that name Ward I know throw in a or two maybe some underscores I'm working on that I'm trying to see how long we can make a name it's a tradition at my company come up with very long name if you're going to promote it thank you John um then U by all means contribute it needs a lot of help but it's a start I appreciate that yeah I just went into beta last month oh wait that was something it actually just got written this weekend so but it truly is really really cool I'm actually using it to put some core together and I guess it's my other pict because I'm very excited to announce that I'll be writing an angular 2 course for plural site which will be coming out hopefully in February nice all right Ward what are your picks well I'm going off Tech Al together because last night I saw star he loved it never gosh I did anything but watch that instead of Star Wars I went to see Julia Gillard the first uh female prime minister of Australia as far as I know the only one so far uh speak and I was blown away by her talent and her skills as a presenter were spectacular I've never seen a a politician who could present that well her sensibilities were so great she's a total star so if you ever get a chance to see her speak and she speaks throughout the US often put her on your list Julia Gillard former prime minister of Australia all right Joe what are your picks all right so uh I spent the weekend at Bryce National Park and had a great time and so I'm gonna pick Bryce National Park as a my pick for today it's a really fun National Park got some amazing amazing geography to look at and a lot of fun hikes we didn't do too much hiking because of the amount of snow that's there in the winter but it is really really great National Park and does have a lot of fun hikes if you either want to go do more snowshoeing type hiking in the winter or go in the summer and while I'm at at I'm gonna pick a new board game I just played this last weekend that I really liked as well called stockpile that's one word St c p great board game easy to learn and pick up plays fairly quick plays like five people or something being a big board game geek that I am I play a lot of new board games and this one stuck out to me it's a great one oh and one more thing I want mention is that of course NG comp is coming up we've got a lot of awesome things that are planned and some amazing events involving of course the angular team themselves and lots of experts in the industry and we're always looking for sponsors so if your company is interested in sponsoring NGC get a hold of us as of right now that's the only way to really the only way to get tickets other than being accepted as a speaker the cfp is open right now so if you have any great ideas for an awesome talk on angular submit those in all right Lucas what about you so my pick this week is the GitHub or the project ngrx by robal it's absolutely fantastic just it's a Redux style project observable really easy to use just kind of inverted my entire Paradigm about how data flows in an Eng application and I'm writing a blog post on it now and then W and I can duke it out when that's done and live but also work by Rob on ngrx it's very cool actually I think it's very cool too so just because I uh take up the traditional side of these things doesn't mean I'm that curious all right I've got some picks the first one is I just want to let people know especially in this audience that uh I'm actually working things out so that we can do a live show at ng- NL now live means that I'll be there um putting crowdcast or Google hangouts or something up on the screen so that everybody else can join in so if you want to be involved with that then then uh go ahead and and jump in and I'm probably going to do a meet up beforehand I'm going to let the angular guys go if if you guys have a second to do some picks since uh it seems like you guys have to go to and then I'll finish up my picks uh I I can never pick just one so I saw this crazy movie called the Revenant which is not really my kind of movie but if you want to feel grateful about your situation in a first world country go watch that and if you want something technical there's an awesome article on the pony Fu website on service workers and uh uh and and how they can make things a lot better for load maps awesome so I'd like to make awesome job on for angular now I'm blushing picking it or yes I'm picking it okay I have two things I read this very interesting book called architecture of Open Source applications the premise of the book is there have been many successful open- Source projects out there that we should learn about and unlike architects of uh real buildings uh software Engineers don't really study history and don't look at you know how these successful projects have been architected we learn a lot about you know languages and and how to do stuff but not how things have been done in the past and what works on with it and basically this book tries to capture several very successful ofar project in a very objective way and show you know what worked what didn't I really like it uh the second thing I want to pick is iPad Pro and the apple pencil I tried it I played with it I played with a with a paper app and it's amazing like really really cool stuff I always like to doodle but uh I Tred different tablets different things iPad or Android tablets in the past and nothing worked well uh paper was always better but now with the with iPad Pro on the apple pencil wow this is so powerful I'm still highly skeptical but uh you can prove me wrong we'll have to compare notes n com okay all right so my other pick that I was going to do was just the people that have have been working with me for a while to get all this stuff done Mandy I think we mention her probably in like every third show but uh she's worked with me for a while she's the one that helps line up a lot of the guests make sure they know what they need to do to get on the show edits the podcast she does a great job with all that stuff and so uh a big thanks to her and then um I've also got a developer that's been working with me for the past two or so years um and he's helped me put together most of devchat.tv and the conference sites and everything else uh his name is federo and uh so a quick shout out to him as well uh just because he's done a lot of work that you all have benefited from and uh I really want to give him some credit so uh so yeah so those are my picks and uh I don't think there's anything else so we'll go ahead and wrap up the show we'll catch youall next week posting and bandwidth provided by the bluebox group check them out at Blue box.net bandwidth for this segment is provided by cash fly the world's fastest CDN deliver your content fast with cash fly visit C A CF 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 adventuresin [Music] oh