The crew talks Angular 1.3 and 2.0 with Brad Green, Igor Minar, and Miško Hevery.

Special Guests: Brad Green, Bryan Forbes, Igor Minar, and Miško Hevery.

 

So, does this podcast make my butt look big?

Hey, everybody and welcome to Episode 16 of the Adventures in Angular Podcast. This week on our panel, we have Aaron Frost.

Hello.

Joe Eames.

Hey, everybody.

John Papa.

Hey, from sunny Florida.

Lukas Reubbelke.

Hello, from Phoenix.

I'm Charles Max Wood from DevChat.tv. And we've got a few special guests. We've got Miško Hevery.

Hello.

Brian Ford.

Hello.

Brad Green.

Hi, everyone.

And Igor Minar.

Yes. Hi there.

So we kind of did an impromptu extra episode here. It will 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 1.3 and Angular 2.0 and just 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 the community understands what we're looking forward to in the new versions of AngularJS. Do you guys just wanna give us a brief introduction or a brief discussion over what's coming in Angular 1.3 and 2.0, and where you’ve seen some confusion, maybe?

Sure. I can start. So with 1.3, we just released it about two weeks ago. And 1.3 was a big mountain for us. We've put in quite a few good features but main one was really a lot of work we’ve done on performance. We have wanted to [inaudible] some of the misconceptions about Angular, and show that Angular can be actually pretty darn fast. And many of the things we're doing in the abstractions we have in the framework are pretty solid. And I think we’ve proved that pretty well in 1.3. So performance is one of the huge features. There's a whole bunch of other ones that we've done. The form validation and the way the forms binding work. We've done stuff on accessibility and a ton of features that just make developing with Angular easier more enjoyable.

I should mention that we covered a lot of these things at ng-europe last week. And we'll have all the videos up on our site by the end of the day. But you can find them out on YouTube right now under the ng-europe account. And I think a couple of things to look for are not just the things we have in 1.3. In our keynote we talked about it. But there's a deep dive that Brian and Jeff did. They talked about specifically how much faster particular pieces are. And some of developer ergonomics bits we’ve added just to make it nicer to work with Angular. There are some things outside of Angular Core that we’re even just so excited about. One of them is Material Design. This new UI toolkit and interaction design patterns that we’re supporting as a separate library. And then there's some fun stuff with our partners that we talked about supporting mobile [inaudible].

I think it would 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 and what's coming to 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. There's the bind once features, there's the ngModelOptions, there's ngAria, ngMessages. Am I missing any other main features in 1.3?

It's really the performance and the work we done on binding. There is a lot of stuff we done around defaults. So many features we’ve had in Angular were optin before, and now they are just available to you without you having to know about these. Are you thinking about something in particular? Is there something that you particularly like about 1.3?

My favorite feature is Bind Once.

[Chuckles] Tell me why.

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. You got to know Angular a little bit better than maybe people will typically have known it after a few months. So with Bind Once, it's easy for somebody that’s really new at Angular to still be able to [inaudible] to get a performant piece.

I would like to challenge you on this because 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 the parser and the dirty checking, it actually turns out that the whole one time data binding is not as relevant or as impactful as people would think. And where it brings some advantages is that it reduces memory consumption. So at this point, that’s the main benefit of one time binding.

If you use one time binding, you shouldn’t be using it because you want a performant app. You should want it because you know that these bindings on a page will not change or you don’t want the memory to be tied up because of something that will never change. So it's a good way to reduce memory consumption. But there are very few cases when you can truly benefit from one time 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. Now, I don’t have to do that. [Chuckles]

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 to comes out?

Can I mention something real quick about that, Chuck?

Yeah.

So at Domo, we have a large app. We talk about how large it is and a lot of it is in 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. So far, the app is working. The only thing that broke surprisingly was the directive that Papa just mentioned, which is the Bind Once directive doesn't work anymore. And so, 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 migrations is going to be super painful, to be honest with you.

Yeah. This was one of the goals with 1.3. We didn’t want to make breaking changes that would make migration very difficult. If you look at the migration guide, there are breaking changes, but all of them are very small or cases that people don’t typically see in their applications. We still wanted to document them just so that if somebody uses in a particular scenario, they how to migrate, but even though the migration guide might look kind of scary. For the most app, it should just be upgrade to the latest version and things should work.

So having said that, if you want to make your application significantly faster for your users and you want to be on the latest code, definitely upgrade 1.3. There's 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 them. So I will 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.

And other things we've mentioned about cleaning up some of your forms code, this could be very nice. The way you report user’s errors can be much nicer with 1.3, the Aria bits we added. And then if you're interested in taking advantage of the new router that we’d be building. And the Material Design components, those are all things that you’d get in 1.3. So kind of like what Igor was saying, if there's apps that work fine and you're don’t wanna 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 don’t mind, I put this out at Twitter to see, “Hey, what kind of questions can people come up with?” One of the first questions got here which is related to this topic is if, “If I'm just starting with Angular, where should I put my time right now? I'm guessing 1.3 since 2.0 is not out?”

Yes. Absolutely. 1.3 is the version we want people to use today. It's the best Angular we have. It's fully supported. We had a dedicated team of people working on it, listening to bug reports and fixing issues. There are features that are still coming to 1.3. So like some people say that 1.3 is dead or is obsolete, that's absolutely not true. We have so many applications here at Google, just at ng-europe we announced that we have over 1600 applications at Google built with Angular. And these applications are moving to 1.3 – most of them, not all of them, but to keep 1.3 going. And if you're starting with Angular, 1.3 is definitely the way to go. 2.0 is still work in progress. It's a moving target. It's early to spend significant time on it, unless you want to be part of discussion in shaping the future of Angular, then you should be welcome to be part of this.

Just a follow on 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 that we will work on as we get closer. As we get some real bits implemented in Angular. And as Igor said, real development should be with 1.3 but come join us on the discussion around 2.0, if you wanna help shape that.

I do have some concrete ideas for how we'll be able to migrate out from 1.3 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.0 as in Angular 1.3 or an Angular 1.3 compatible module. Some other things is like we're going to continue working on Angular 1.3 and we'll be fixing bugs and trying to see what the best practices are there. And one project that I'm working on is called AngularHint. And so, I'm going to continue adding more kind of checks in there that try and tell you whether or not something that you’re doing is like a bad decision architecturally.

If it's something that I can detect.

I wanna know more about that because I'm building something like that for my own stuff.

You're building something like what?

Like an Angular Hint. Like a linting tool. So I’d love to talk to you.

Oh, okay. Just an aside, I presented about this at ng-europe, but it's a runtime hinting system. So one of the interesting things is it can detect more things than something like JSHint or JSLint’s code. And there's a whole talk that I gave about that. I don’t wanna spend too much time here, but I think this is something that I can continue to extend, as we figure out what the ways that Angular 2.0 is going to be different than Angular 1.0. 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.0 will be.

So the question that I have is I think 1.3 is excellent, just the performance and the new features. And somebody coming in to AngularJS now, is I would definitely recommend to start with Angular 1.3. It's never too late to start building awesome things right now. But from kind of a pragmatic business case stand point, are there any concerns starting with 1.3 if we're building an application that has let’s say like a five-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, did 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 you’ve got a long life cycle project, should you start with 1.3 now or are you better off holding off or making another decision?

And I think where this question comes from is a lot of enterprise and business type developers, they've got managers and leaders looking at them saying, “Hey, if we're going to bet on this thing…” because they are used to the world they can build an app and let it live for five to ten years. Now in a way 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. And we have a lot of similar apps at Google. We kind of maybe have a couple of different categories of the way we deal with them. 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. So that's how things work today. So even if you're on 1.2 or you decide to go on 1.3, these things will work. As Igor said, we’ve got a team who is going to continue to support 1.3 and fix bugs. And there are even some kind of sizable features that will come in, that are still aren’t done yet.

At Google, we have maybe a couple different categories of apps. Some are, like we talked about earlier, apps that run fine, they don’t have a dedicated team, that are going to actively develop than this. Basically just bug fixing because it serves the need. And some of these are internal apps and maybe some of these are lower traffic external apps. Then there are the projects with active development. And these are candidates for possibly upgrading to 1.3, but never moving to 2.0 because this is going to be, 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 2.0. 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 and state looks like a little bit more. So in this category, “What should I do right now?” If I'm thinking, yes I have an active development and I will wanna go for 2.0. Really, like we've said, there is only 1.3. 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 when you have questions. And then there will be other forums. And our GitHub repository is on angular/angular is the place where you can see a lot of this activity and weigh in on the issues that we raise there.

So Brad, I have a question. You're talking about longtime support for 1.X. Do you foresee like a 1.4 release eventually? IS that kind of long term or is 1.3 kind of the end with some addition of a

couple extra features?

I think too early to tell. There is a possibility of 1.4, but I don’t wanna comment to 1.4. We definitely want to add features to the 1.X branch, and some of them are pretty significant. Like we're looking at better internationalization for example. I'm not sure if this will require change in the core. If it will, we'll probably go to 1.4. If not, maybe we'll just keep on bug fixing 1.3 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 some of our 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. I suggest maybe go check out the ng-europe talk that folks did. We're actually going to need to update, we're going to pull in this new router that is our 2.0 router back ported to 1.3. And there will probably be some changes in 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 something Google is doing and we'll support it.

I would just add to the question about, “Should I use 1.3 when 2.0 is coming?” If you really are excited about the stuff we're doing in 2.0, I think 1.3 is the best starting point for you right now. Even though we're going to change APIs for sure, many of the concepts will remain the same. So if you are building applications, if you're starting now, and you will want to eventually use Angular 2.0, Angular 1.3 is the closest thing you can start with today. So that's just to add to the 1.3 and how important it is for us.

That leads really nicely into another question we got on Twitter and that is “If I'm going to learn Angular, what impact will 2.0 have on me and how can I prepare?” So what is different? What are we gaining? What are we losing?

I think the motivation behind 2.0, there's two parts: first we wanted to make sure that we play some nice little web components. We think that the web components are kind of the future and we wanna support them both as Angular becoming web component if you wanted to do it and there's also Angular consuming 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 wanna 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 people asked for features, we kept adding them and so on. Now if you can step back and look at for example how we get the components etcetera, 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 can kind of step back further then say, “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 are just going to be re-arranged in a more sensible way. And basically, you'll be able to describe your application with a more limited vocabulary which is always, in my opinion, a good thing.

I have a question about that. Can I still describe it the old way, not using the AtScript stuff? Can I still write it like the way I'm used to? How is 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 lot of reason to do different things. And forcing people to do something is just a recipe for disaster. So if you wanted to build your in ECMAScript 5, by all means, you can do so. If you wanna build it in TypeScript or CoffeeScript or ES6 or any other common 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's 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 same way.

Also get asked quite a bit about AtScript and whether it's something that's 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 with Angular. So if you want to have a language that has optional type system, and meta data annotations and you wanna use it NodeJS, you will absolutely be able to do that. So we're not building something Angular specific as a bigger purpose.

I'm going to paraphrase what Igor just said. And Igor, correct me if I'm wrong. To use AtScript, I don’t have to use Angular. But also what Miško said is, I don’t have to use AtScript when I'm using Angular 2.0 either. Neither one of them are 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 have been coming online too, which is great because I wasn’t able to make ng-europe. There was a couple slides in there about features that are “rest in peace” some RIP 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 are gone. It's that, “instead of using this feature, in Angular 2.0, you'll use this instead.” Is that correct, Igor?

Yeah, that’s correct. I kind of wish that this would work out better. I think that the delay of videos being available costs some kind of confusion and early premature reactions. Because now when I look back at the slides, I'm like, “Oh yeah, that looks pretty weird.” But if you listen to the video, like, yes, we are saying that $scope is going away, but there are reasons for it. And we have a good replacement story. And so it's not like we're crazy is going on and killing features. We actually are just simplifying the APIs. And many of these concepts like Scope would 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 modules going away or rest in peace or wherever that was. It's not that they are going away. It's that now you’ve got, whatever 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 [inaudible] module” and there's rest in peace. And that’s exactly what it means like we don’t need proprietary 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 coming future, everybody will migrate over to use this module system because it will just make things much easier. It will make interpreters better. And it's just something that we need to do for Angular if we want to make it succeed long term. If we keep on just playing and creating this like proprietary APIs, it's going to be really hard for you to integrate the part of components that would be built in the future. But by us embracing these new standards, we are going to be in a much better position to work with other code in the Angular 2.0 version.

I just wanna clarify one thing really quickly and that is with the ES6 stuff, if we want to work in ES5, then we are either going to have to have some polyfill or some build step that handle that for us then?

Correct. And we're actually working very closely with the Traceur team. Traceur 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 Traceur already contains a polyfill for the module systems. So the module loader is already in a very good shape. Initially, it will be started with a RequireJS and CommonJS polyfills, but now we have a proper polyfill for ES6 module loader. So that's what we'll probably end up using.

So you mentioned things like in the slide, DDO for Directive Definitions, and you’ve got controllers as well on that slide, those things, are they going away because they are just basically becoming classes or components in the new version?

Yes. That's the case.

So it's less of a going away than it is a makeover, right?

Correct. And again, if you look at the wording, like we are saying Directive Definition Object is going away, not that that directives or the concept of directives is going away. And Miško kind of touched on this, 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. Angular evolved over the last five years and community feedback has been big part of this evolution.

So just one example is the Component System. When we started with Angular, there were no components in Angular. We just had some templates and controllers and we're so happy that everything [inaudible]. [Chuckles] But then as we were starting to build bigger and bigger applications, then 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, and I can build a component, but I have to do all these work. I have to use the compiler; I have to finish the template. What if we just added it into the directive. And we did it by extending the Directive Definition Objects, so that you can say, “Oh, I need this template and I need the oldest features and I need the binding to just work.” And then we had a component model.

But really, it was an afterthought. And like I'm saying this at the risk of being flamed on Twitter, but that’s really the case. We just learned as we were building Angular, and we realized this is a useful feature. And now with Angular 2.0, we are analyzing all these patterns in how people use Angular and try to build APIs that are specific for these scenarios. So you don’t have to think about, “Oh, I

have directive that has these 20 possible options.” And for me to use it in this scenario, I have to use this, so instead we're going to have concept that will just do the right thing for you out of the box, so things will just be simpler.

I think the last big one in that slide, is the $scope, it said rest in peace to that as well but obviously, there’s still going to be something similar to that in Angular 2.0. Can you kind of elaborate on that?

Yeah. Miško do you wanna tackle that one?

Yes. I'm going to tackle that one. So, when you have an expression, you need to evaluate it against something. And the scope is kind of the [inaudible] which you evaluate it. But it turns out it's much more efficient or much easier to think about it if the controller itself becomes the evaluation context. Why does a 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, so this is how the controller came to be. And it, at one point, was the scope, then we changed it and became the separate thing, [inaudible] 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 the combination of components that really, the component is the scope. And again, this goes back to what Igor was saying there, 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 are basically telling us that say, “Yes, this is finally 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 gets watched, how you can verify things and so on. And so we really think this is the right approach.

I wanted to make a comment and then let the Angular guys react to it. So my comment. Igor kind of touched on this that the videos kind of being delayed created some weird reactions from the community. And I saw a couple of reactions I thought were a little weird. Like people really freaking out that the syntax was so weird. Like, so distinct. And I heard things like, “They shouldn’t even have called it Angular!” They were saying that like it was a bad thing. But then they also complained that the migration path, they were like, “There’s no migration path!” And they were really, really mad about that when it was never confirmed that there’s not a migration path. If anything, all I heard Igor say was, “Once we know exactly what 2.0 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, migration path means I have some time to migrate. And I

thought that was weird that those two complaints were like contradicting each other, because the new Angular is so different. That's what will enable me to have a migration path. 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. 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 exists on a page link. So I was actually pretty pumped about the different syntax. What do you guys think?

I think that’s a good interpretation, and might be a good way to think about it. Also, just 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 1, we had similar reactions. Everyone was up in arms when 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 innovation nature of the 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 all their livelihood on, in Angular 1.x timeframe. And so you also said that yes, and 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 at the community, is to be involved, help us understand what you need. And give us a little time to develop 2.0, and then build our story for migration for 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 déjà vu moment for me, because starting with AS1, which is very much like JavaScript as we know it now, and then moving into ActionScript 2 which was class-based, there was a lot of the same kind of push back. You know, “This is hard and we're going to have to change our apps. 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 languages and platforms is that change is 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 [chuckles] 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 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 HTML spec, brackets and parentheses are actually valid HTML. Now we think we might have to have a backup plan for secondary tools that won’t allow you to put brackets in there, so it's something that’s going to be all text based, but we wanna support both of them as well.

The other thing is we want it to be 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 which still stay. But there's couple of things we had to change that we don’t have a choice in. And this has to do with web components. The syntax that we have today is not web components friendly. And while it's sort of kind of works, it doesn’t fundamentally work. And this is really the motivation behind these changes. So it's not like we are just changing it for the heck of it because we think that the other one is different or prettier. It is that we actually had 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 it says “foo = bar” it really isn’t clear whether “bar” is literal that is going to be displayed to the user or is it an expression. And this all fits into the IDE support, because if IDEs wanna 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 should be able to allow you to have click throughs and etcetera.

And today, if you look at something like ng-include, the source attribute there is a literal, if I can remember correctly, it's literal I think. But other ones will have an expression. 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 that 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 those changes.

So I have one quick follow up question on that. This is actually my own personal question. If I'm doing like an ng-repeat. I saw square brackets ng-repeat pipe and then the thing you're iterating and then close the brackets, if I understand it correctly, you can’t put a space on either side of that pipe, right? That’s part of the syntax?

Yeah.

So is that something that I imagine, I'm just thinking ahead, tooling will probably be able to help with and say, “Look, you made a mistake here. Let’s get rid of those spacing.” Because I know it's a different syntax than people have seen before.

It is and it's actually not even clear when that syntax is going to stay, because we have some more ideas that we're toying around with. One of the issues we were facing for example is how do we hint to IDE that a new variable just came to be? So for example, if we look at ng-repeat, you say, “Item in items” Item is a new variable that wasn’t valid before the repeater, but now is a valid variable so the IDE can allow you to click through and you 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 IDE actually understating that ng-repeat’s declare a new variable. So if you have somebody in the 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, these repeater syntax, there's new variables that are being created.

Cool. Thanks.

The whole IDE story is one of our long-term goals, 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 for small and medium size, but now we're 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 the whole scalability factor is a big thing in Angular 2.0. And this templating changes are just part of a bigger picture.

One other question we're getting on Twitter is, “Really looking for help to port 1.x to 2.0. Enterprise is worried that they are so different.” And we've talked a bit about not having a clear migration path until 2.0 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've said is we will have a path and give us some space. I think we don’t have a particular thing, and I think we don’t wanna 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 others chime in if you’ve got other ideas.

I’d like to add that we described these new concepts and syntax, people have these idea that they are going to have to rewrite the application from ground up. And that’s nowhere close to what's going to happen here. What's mostly likely going to happen is you are going to have a set of instructions that says, “If you use to do ‘A’ in the old system, you will now have to do ‘B’.” And for the most part, many of these things will [inaudible] to be replaced by kind of a smarter regex. Like, “Oh yeah, this thing becomes that and this thing becomes this,” kind of a thing.

Makes sense.

We also don’t wanna just tell people like lies, right? The point is we're making Angular 2.0 as good as possible. And then we're going to build a bridge from 1.3 up to 2.0. We don't know what that looks like because 2.0 isn’t done yet. So what we really want is your help in making 2.0 awesome, and figuring out what things you want out of 2.0. And then we can figure out what steps are in between. But until we have that figured out, We're not just going to say things.

So I think that’s really a good way to go. And 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've seen 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, “Why are you not being open and transparent?”

And so there's a balance. And no matter which way you go, you're damned if you do, damned if you don’t. I get that. But in the same sense, what I keep telling a lot of the people is, if you have feedback, tell the Angular team. Communicate and provide a feedback, so they can use that in a constructive way. Don’t just whine about it or talk in a backroom in a bar with a beer. [Chuckles] 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. We're very active on GitHub. We have a new repository under the Angular organization called angular/angular. You can file issues and proposals there. We will look at those and have further discussion there. The other way we can communicate is we're publishing our weekly meeting notes. So it's a Google doc that we share on Google+ after pretty much every meeting. And you can chime in, see what we are up to and comment on the docs. So it's not just reading what we did but you can comment in the doc and tell us if we're missing something or we should consider something that we haven’t thought of.

All of our design docs and all of the research docs that we put together are also open in public. So we're really not trying to hide anything. From the very beginning, Angular has been very different Google project for better or worse. We've always worked out there on GitHub, and then pulled Angular into Google, whereas so many teams do it the other way around. And we’ve 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 there's a lot of controversy and there's 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.0 behind the scenes and then had a big reveal, “Hey, this is Angular 2.0. Happy migration! Just suck it up. It is what it is.” [Chuckles]

For what it’s worth, I think it's the right way to go. 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, kudos to you guys.

We want your feedback because we learned from a past experience that we have some really good ideas but sometimes we miss things, and people from the community come and tell us, “Hey, it's 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.” Then we start having this broader perspective on things, and eventually 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 have.

I have to say that 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, “What do we think, since spend most of our time building Angular and not necessarily building apps in Angular…” though I know that you guys do some or both. It's heartening that you’re talking to people looking at the way people really do use things and then say, “How can we simplify this? How can we make this easier? How can we lower the conceptual burden for new people coming in to the framework?” I think that’s really cool.

Yeah, absolutely. People often think that we know everything and we have all the answers, but that’s not the case.

You don’t?

No. I'm sorry. [Chuckles] We learn from each other. We learn from the community. And it's been amazing four years for myself on just working with all these people out there and 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 is the migration path look like? And so what I'm about to ask sounds like that question again, but it's not. I wanna know, I know that [inaudible] is an unknown, but do you guys know enough about what it will be to give us some pointers, maybe not today, but in future about what could I write my code like today, that will probably make that easier? An example is, the way that you inject things into like an Angular controller. John Papa uses like a way different way to do injectables than I do. Is there something, and the answer can be “no”, that will make it, that you foresee like different style guides will make it easier to upgrade potentially in the future.

I'm working with John on his style guide and we are improving it and I'm providing him feedbacks. So that's a good starting point. Using the Controller As syntax will likely make things easier for you. And I'm trying to be very careful because I don’t wanna say, “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 it will change everything. And then whatever I will say today will not be true anymore and you will come to me in a year and you are 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 build the best Angular 1.X you can today. Build an application for your users that they will enjoy and that 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 the whole migration story and best practices and those kind of stuff.

Awesome. That’s exactly what I wanted to know. Thanks, man.

I have kind of a… 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 is it's a mistake for somebody to go and say, “I'm about to or had just started building an Angular app. And I feel like I wanna put that off and wait for Angular 2.0.” 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 just starting today, that's where you should start. You can use different solutions, but if you want to use Angular 2.0 eventually, I think migration from something else to 2.0 would be much harder than going from 1.3 to 2.0, just because many of the concepts are just preserved and the migration story will not show. And we will have a migration story for you.

As a follow up to that, I go ahead and take your advice and start building or I continue building my 1.3 app. What will life be like for me in five years?

Let me take this one. I think I summed it up in the Q&A at ng-europe very well, where I declared I'm horrible at predicting the future. And I invite you to go watch the Q&A for my special story about my involvement with Steve Jobs and Tim Berners Lee on that. I think 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 things beyond six months here at Google seemed like Science Fiction to us. 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 to help us make it.

Awesome. Love that answer.

All right. Do we have anything else that we should talk about here? Any other questions you guys are hearing before we wrap up the show?

I think the big things that are kind of sticking out though is we've heard your guys thoughts on what's coming with 2.0. And kind of we talked about the migration path to death, but in 2.0, we've heard you talk about AtScript and things and components. What about other kinds of features? What's the main theme that’s coming out of 2.0? Is it mobile? What is the theme that you guys are focusing on?

So we declared this in a blogpost maybe 8 months ago, when we started out on 2.0. And originally, there were a couple of things. Supporting web components is a big one. We want to be taking advantage of ES6. That was a big one. We've since added AtScript on top of ES6 and TypeScript. And then mobile, yes. This is another big thing. So, we've 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 we may discover some more things along the way. But if you wanna know what it's about, it's we talked about simplification, performance, mobile, those are all big.

What about Material Design. 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 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 widget tool set. It includes animation, interaction design, full end-to-end 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 desktops through mobile. And the UX concept actually extend to our smaller contractors at Google to things like watches and cars and what not. 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 release is going to embody this fully. So come join us. Another big thing that we're putting into this besides flashy animations is support for Aria. 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've got one last question. This came from Dan Wahlin. “Why are Igor and Brad so dang awesome?”

How can anyone know that?

I'm not qualified to answer that. [Laughter]

It’s unknowable.

They use “awesomeness” supplements in the Google cafeteria.

Yeah. When is Angular going to be on Project X? [Laughter]

I just wanted to embarrass Brad, Igor, Dan all in the same sentence. [Laughter]

Awesome. All right. Well, I just wanna let everybody know that if you do have questions, 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 what's going to come out in Angular 2.0 and the coolness that’s already in Angular 1.3.

Let’s go ahead and do us some picks. Aaron, do you have a pick for us?

There is a project I’ve found that was pretty sweet. It's called JuliusJS. It is a C-based voice recognition library that their compiling with Emscripten 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. JuliusJS – go check it out.

Joe, do you have a pick for us?

Yeah. This is particularly timely with this discussion that I'm right in the middle of, I'm getting close to finishing working on a course for PluralSight on what's new in Angular 1.3. It will be pretty comprehensive working with another author as well to talk a lot about the changes, Bind Once, animations and validation etc. So little self-serving, but I feel like it's pretty topical based on today’s discussion. So it will be my PluralSight course on Angular What's New in Angular 1.3.

Hey, Joe. Is that with Deborah Kurata?

It is with Deborah. Awesome author. She's very good.

Not that you're not awesome. [Laughter]

Oh come on, we all know Joe can use all the help he can get.

You got it. [Sad trombone]

All right. John, what are your picks?

So obviously, the picks we have to do are the ng-europe videos since Brad says they 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 with me with recently and that’s the Bind To Controller feature that looks like it is in Angular 1.3. But Brian was so kind to help to do a back port 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. Lukas, what is your pick?

My pick is the Angular Material Design. I think it's just phenomenal. So just really excited about the tech and excited to see 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 businesses and entrepreneurs. I actually went out and set up a voice mail system for the shows. It's not quite ready to launch, but pretty close here. In fact, I can give out the number now and I'll have it ready next week. So if you have feedback, a voicemail that you wanna put in, the phone number is 1.877.223.0342. And so you can just call in, ask questions, stuff like that. And we'll play back questions as we're ready to answer them on the show or feedback if you have it. Really appreciate that. So that’s my pick. Miško, do you have a pick for us?

Yeah. So the way I keep the stress down while I'm working with these awesome people around me, is I go running. And I finally found the headphones that I like they are called Aftershokz. And they are bone conducting headphones. And the cool thing about them is they have nothing in your ears, so your sweat doesn’t get into them etcetera. So if you guys are into running, I recommend those.

I think you just spent some of my money.

That sounds awesome.

Yeah. You wasted my money, man.

Igor, what's your pick?

I have two, actually. So for the past week, I've been [inaudible] in Android Lollipop. And guys, this thing rocks. Like I've been using Android for the past five 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’t be excited more about my mobile. It's so awesome. Really blew my mind.

And speaking of mind. For the past few months, I've been kind of like training my mind and working

on having better control over myself. And I've 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 a better person, then check out headspace.com.

Cool. Brian, what are your picks?

So my pick our AngularJS blog post about ng-europe and Angular 1.3. One of the cool things about that post I think is that it links to all of the various documents and things that we've been putting out. So if suddenly Angular 2.0 stuff snuck up on you, this just links to a wealth of different conversations that we had and kind of the 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 the explanation about how to think about strategy in release. Because you can’t release all of it at once. And most teams tend to look at which features should go in to a minimum viable product. And what they draw is the nice pyramid about [inaudible] 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 bottom to the top of this pyramid. Go check it out. It's originally apparently tweeted by @jopas 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.