Q&A Session With Google’s Angular.js Team Including Transcript and Angular 2.0 Questions

BRAD GREEN: Wait, wait, we’re going to take local questions too, right?

HOST: We are.

BRAD GREEN: OK, good. Just checking.

HOST: But maybe I’ll just ask them and then I’ll immediately answer the question and if you want to add anything, [LAUGHTER] you can.

So if you have local questions, we’re going to just alternate so this front row right here, just come up here and sit down and we’ll– maybe AV, if you have another mic, you can bring it and so we’ll just kind of swap from online and local so come sit in this front row, and we’ll just go in the right order, OK? So question number one, we’ll take from online and the question is, will Polymer and Angular ever merge to create one JS framework to rule them all? And the answer to that question is– just kidding.

BRAD GREEN: Well, so one of the things you saw during this conference in Misko and Rado’s demo is that we work with Polymer out of the box. We’ve taken a lot of time to make sure that Angular works with not just Polymer but any library that creates web components and so this being the main theme behind Polymer, I might say we did it.

IGOR MINAR: Yeah, we actually spent like half a year trying to make it work and then we realised that if we want to get the performance benefits and also the control that the application framework has over everything that’s happening in your application, the architecture that Polymer chose to use was not the best fit for us.

So we decided, we made a conscious decision that while we will make it work with web components in Polymer, we will choose slightly different architecture, because of our slightly different goals. We really focused on building applications and not necessarily just components.

MISKO HEVERY: So I also would like to add something to that, which is that Polymer is about– not all of it, but a big chunk of Polymer is about creating polyfills and bringing these standards to the framework and it’s a slightly different goal than what an Angular has which is to build applications. So they’re complementary, but they’re not the same thing.

IGOR MINAR: I would also like to add that we have very good relationships with some of the people on Polymer and like [? Adios ?] [? Money ?] has been very useful and helpful in just brainstorming stuff.

So it’s not like there is this like ugly competition within Google between Polymer and Angular and I really appreciate that.

HOST: OK, thanks for adding so many things. That’s all the time we have for the panel tonight. [LAUGHTER]. Just kidding. We’ll take a question from the first guy right here.

AUDIENCE: Hi, my question is about the new router. You mentioned a little bit that it, would be possible to support lazy-loaded routes. What about the other features that are provided in UI-Router Extras, like Deep State Redirect, Sticky State, things like that?

BRIAN FORD: So that’s a great question. I actually don’t know what those things mean in UI-Router. [LAUGHTER] I’m not an expert on UI-Router. Do you want to briefly give me an example of one of those things?

AUDIENCE: Right. So with UI-Router, you can define nested states and you can jump from kind of one state tree to another and maintain a state when you route back there. It’s like you could have divs side by side on a page, navigate, activate one div and come back to it and you’d still have your state exactly as it was when you returned.

BRIAN FORD: So yes, I do want to be able to do that. There’s already a way to do it, but there’s not like super nice APIs and super nice docs on how to do it. So yes.

Like any question that’s, can the new router do x? The answer is usually yes, but there’s not like a super great writeup on how. The best thing to do, actually, is just file an issue in GitHub saying, hey, how do I do this and actually, if you look, there’s tons of issues that are tagged as use cases and some great discussions there.

As I implement features, and as I add more examples and improve the documentation, I close those and then if someone comes back and says, wait, wait, wait, what about in this case, then we reopen it and we talk some more.

Great question, though.

Thank you.

AUDIENCE: Thank you.

HOST: Thanks. OK, this next one– and maybe this is just a recap– but considering how different Angular 2.0 is from the original, what kind of upgrade paths have you planned?

BRAD GREEN: We did cover this a bit and if it wasn’t clear, the plan is that you can either migrate wholesale and we’ll provide some guides and tools for it or you can do it incrementally, where you get to mix and match Angular 1.0 and Angular 2.0.

HOST: OK, next up.

AUDIENCE: All right, Misko, in your speech this morning, you were showing a lot of examples of the new syntax and I saw a couple of places, and I’m a little confused about sometimes you would use a pound sign to represent a reference to a variable and then it looked like at some place else there was like a var underscore and so those two different things looked they were doing the same thing. I was wondering why the different syntax?

MISKO HEVERY: So, you’re right. There’s two ways to do everything and this comes down to that there’s the preferred way, which we call the shorthand, which either has the brackets, the parentheses, or the pound sign and then there’s the alphanumeric, or what we call canonical way, which has bin dash, on dash, or var dash but they are absolutely equivalent.

JEFF CROSS: Well, I think one thing we’re doing. I don’t think there’s like inside the framework to be done, other than the way modules are organised. It gives us more flexibility in loading separate modules at run time, rather than having to compile them together and to view specific binaries.

Igor, do you have anything to add to that?

IGOR MINAR: Yeah, really the code loading and getting all the asset files into the browser, that’s where the biggest impact is. We don’t necessarily need to do anything special, except for providing tooling that will make it possible to take advantage of the benefits of HTTP/2.

HOST: Cool. All right, you’re up.

AUDIENCE: OK. A big feature of Angular 2.0 is to load modules dynamically and I think, we were looking to see that talked about in this conference. Could you talk a little bit about how that’s going to work?

MISKO HEVERY: So the module loading is going to happen on the router boundaries. So when you navigate to a particular URL, which has a particular set of subviews that get loaded, those subviews will be able to be loaded dynamically and the way this is going to be done is because each component will have its own injection system.

BRAD GREEN: I think they want to see some code

HOST: He guesses.

MISKO HEVERY: Yes, so actually, I have a design doc that I need to actually work on with [? Igor ?] starting Monday specifically on this stuff.

BRAD GREEN: We’ll produce some code soon. I think that’ll help clear it up.

HOST: I think he also wants a hug. He waited like two days to hear it, and that was not very good. I’m just kidding. [LAUGHTER]

HOST: Aaron.

AUDIENCE: Get over [INAUDIBLE]

HOST: There you go.

[LAUGHTER]

HOST: Aaron will lazy load anything for you.

MISKO HEVERY: But just to make it perfectly clear, it is very high priority for us to have lazy loading because of our internal customers so this is going to happen.

HOST: Sweet.

[APPLAUSE]

HOST: You guys are working on lazy loading for 1.x as well, right? You want to talk about that?

BRIAN FORD: Yeah, so right now, after you’ve bootstrapped your app, there’s not really a great way to register additional controllers or services. There are some libraries out there that like patch Angular global APIs and like do sneaky things to get a hold of the injector but I’m working on a proposal right now to make it so there’s kind of a first class API for how you do this so this isn’t like a module loader itself.

I’m not reinventing RequireJS. The idea is that you could use something like RequireJS with this API to more easily lazy load parts of your app.

BRAD GREEN: And that’s for Angular 1.0?

BRIAN FORD: Yes.

IGOR MINOR: And just to add to that, it’s not like we don’t consider lazy loading to be unimportant for Angular 1.0. it’s just the architecture we have, if we just hacked in lazy loading without thinking about it too much, we could introduce issues that would be very hard to debug. So while there are other solutions, third party solutions, that allow you to lazy load code, by using those, you actually lose some of the guarantees that you have in the current system, which can make your life very unpleasant and this is why we are very hesitant about how we introduce this into Angular 1.0. because just the system wasn’t designed with this use case in mind.

HOST: Cool. You’re up.

SPEAKER 2: Hey, I was actually just recently talking to our internal folks, who are the experts on this, because we’ve noticed some issues with JavaScript based sites and their answer was, can you please ask the questions in a public forum because you can imagine SEO is a very sensitive topic and whatever advice we give, we want to make sure we’re giving in public and when I say we, I now mean like the people who actually know something rather than me.

So I would ask you to please post on the Angular user’s forum and ping one of us on the team. The more specifics you can provide about the exact issue that you see, the better help we have in getting people to work on this and we should have a more specific answer very soon but please ask questions about it and do escalate to somebody on the team if you’re having a specific issue and the team has promised to come up with better guidance shortly.

HOST: OK.

BRAD GREEN: So Angular 2.0, we didn’t actually say it at this conference, but Angular 2.0 is intended to support evergreen browsers. We don’t have the matrix for our mobile browsers yet. I don’t know, Igor, have you finished research? No. We’re still figuring it out because they’re not all evergreen and there’s some variations that we want to make sure we’re covering that well and so probably a little bit beyond evergreen for that but so it’s IE11.

HOST: Cool.

BRAD GREEN: And 12, yeah.

AUDIENCE: Hello, Hi my name is [? Saul. ?] So I was just wondering if we were to start a production app like today and we wanted to use the best thing so that we’re able to be ready for Angular 2.0, what would we use? Would we be using the new router today, 1.4 or 1.3? What would we be using? And then second, well, let’s say we’re using ES6 on 1.x app, is there a good style guide to follow?

HOST: Could you add just like two or three more questions?

[LAUGHTER]

BRAD GREEN: Yeah, well, if you’re getting started today, you have to use 1.3, because that’s what’s out there.

BRIAN FORD: And yes–

BRAD GREEN: As far as ES6, I don’t know the answer.

BRIAN FORD: Oh, and yes, you should use the new router.

BRAD GREEN: I forgot that.

SPEAKER 3: And all the animation stuff too.

[LAUGHTER]

BRAD GREEN: So I think we have a request for John Papa, where are you, about ES6 and best practices. I’m kidding.

IGOR MINOR: So we’ve also seen some projects from the community, where they show how to use ES6 with Angular 1.0. and if you search for some, you’ll find them and I think, Miho also showed some of this stuff earlier today.

HOST: OK, any updates on Batarang? Are you working on a dedicated debug tool for Angular?

BRIAN FORD: So my time is split between like a million different things. I’m very good at coming up with new ideas

HOST: So Brian does all the work, Igor meditates. What do all the rest of you do?

IGOR MINOR: I just want to add to that, that I actually screwed up because I was supposed to reach out to the author of ng-inspector and talk to him or her about whether it would possible to unite and build just a single extension for debugging Angular but I forgot about it or got distracted or something.

I was not paying attention to here now.

[LAUGHING]

So if the author is listening to us, would love to talk to you and see if we can just get together and build just one extension. We care about this a lot but there’s a lot of stuff we’re working on. So this is one area where we need help. Thank you.

AUDIENCE: So I saw in the code base you have things like star for each in the markup. Are those things that developers can create?

MISKO HEVERY: Yes.

HOST: Wonderful. Yes, everybody.

MISKO HEVERY: So in Angular 2.0, we took the concept directive and we split it up into use case. The use case is you can have a component, which are something you’re familiar with. You can also have a decorator, which is kind of a component minus the template with a couple of restrictions and there is this new one called the view port, which is things for if statements, for each switches and so on, which you can create yourself as well.

AUDIENCE: I had a second question. So you’re using TypeScript now. How heavily do you lean on types internally? Are you primarily using types for external APIs? Are you using types in every method? Is it mandatory? What are your feelings on types?

HOST: It’s just when they script, that’s when they use types. Next question. Just kidding.

MISKO HEVERY: So we are nothing as much of a diligent job as we should here on types. The goal is that we would type all public APIs. So when we generate the documentation, you would have that information so that you can easier call and work on, etcetera.

Within Angular itself, which is the private APIs we rely a lot on– it’s not reflection, what is it called? Inference, thank you. Rely a lot on inference but the external API is definitely going to be type, because we need it for both the definitely typed output also for documentation, and also for Dart folks. So it has to be.

HOST: OK, next question from reddit. I love webpack, but working with modules in Angular and webpack is a bit hacky. Will Angular 2.0 work better with webpack?

BRAD GREEN: Who knows what webpack is?

BRIAN FORD: Am I really the only that knows what it is? So webpack just uses like CommonJS, doesn’t it? So it consumes that. So we actually just landed better support for CommonJS in Angular 1.0. So I assume that greatly helps the situation. It also includes, if I understand correctly, like a loader, like something client side that helps you figure out when to load stuff and so this is something that I’m looking into, both this and RequireJS and AMD for this API that I’ve been working on to improve lazily injecting in Angular 1.0.

So the hope is that, yes, the situational will be better. I don’t have exact details right now but this is another thing, where, if you’re interested, please chime in on GitHub maybe with some concrete examples.

Did you have something?

IGOR MINOR: Yeah, this is a good example of technology that we don’t have experience– first-hand experience with and this is where the community can help us. You can help us show that supporting this technology is actually very valuable and you care about it and you can get in touch with us and then we can discuss what other necessary steps we can take because we cannot just understand every single technology out there.

There’s just way too many of them.

AUDIENCE: Hey, Owen, Angular 2.0 data persistence, there is a design doc. I think, Jeff Cross was sort of running that. Sort of wondering what the status is, sorry, of data persistence in Angular 2.0. Is it still a priority? Kind of up there along the lines like the router and that sort of stuff.

JEFF CROSS: Yeah, data access and persistence are still a priority. Offline is a priority. Our approach changed since writing the design doc and since a year or so ago. I think our approach now is more making sure the core is friendly to lots of different approaches and I’m working with lots of different backend frameworks and different front-end libraries to start experimenting with Angular 2.0 and see how well it plays with these different technologies, like Meteor, Firebase, Breeze, and a few others.

What’s that?

BRAD GREEN: Falcor?

JEFF CROSS: Falcor, yeah. So right now, I think we’ve got either implementations or good designs how to work with most of these and how to accept the kind of data structures they use for Async and I’ll be doing more experimenting and see if there are some common patterns that emerge that there’s still some area to add, libraries, or ways to improve on it but that’s a little bit how the approach has changed.

HOST: All right. If I decide to go the TypeScript route am I going to be forced to use Tracer to transpile my annotated code? Any chance I’ll be able to use Babbel?

BRAD GREEN: Jonathan, do you want to take that?

JONATHAN: Sure. Such a good question and this actually came up last night with people asking about TypeScript. So there’s kind of two parts, two answers to that question. The first one is, if you want to have full type checking on your code, running it through the TypeScript compiler and doing your type check that way, you’ll get the best results.

I just started talking with one of the Babbel guys about ways that the TypeScript team can collaborate with Babbel. So that is very fresh as of like this morning. So we’re looking at ways to work with other transpilers so that you can say, all right, I’ll check with one, but sometimes I just want to transpile and I don’t really want to think about the types and just get them out of the way. So we’re looking at possible ways we can collaborate.

AUDIENCE: If I were going to teach Angular to someone who had never seen it all, never been exposed to it, what version do you think would be best start with right now? And what pieces do you think would be best for them to start learning?

BRAD GREEN: You know, we have some good friends who write courses on this stuff. But no, so the question is, what version do I start with? I would start with the one that’s released, so that’s 1.3. but as soon as 1.4 comes out, that’s the one to start with. Is the question like how you start building these things?

AUDIENCE: A super beginner.

BRAD GREEN: Super beginner. I’d have to know what their background is, but there are many good online courses, Code School, Pluralsight, egghead.io, check them out.

HOST: All right, does Angular have any plans to support and adopt ES6 Generators, and Async 08?

BRIAN FORD: So I can sort of answer this. I actually use Async 08 in the test for the new router, because they’re super cool. So really, it’s more of a question of does your transpiler support it. As far as like, will we ever make it so you have to do this? I don’t think so but the cool thing about the kind of transpilier approach is that you can use any of these features that you want and as long as you can produce ES5 equivalent, everyone can agree on and everything can run together so I actually think that these features are really cool and you should check them out.

IGOR MINOR: So Tracer already supports all of this stuff. I don’t know what’s the situation with Babbel and maybe, Jonathan can talk about their plans with TypeScript.

JONATHAN: So that both Generators and Async 08, I think I mentioned earlier this morning, are coming in. So 1.5 is the next version of TypeScript and 1.6 is the following one, obviously. So 1.6 will have Generator and Async 08 support.

HOST: I think the question is also wondering, so Angular really adopted Promises and so a lot of the core APIs are based on Promises. Will the same thing happen with Async 08 and Generators?

IGOR MINOR: It’s a good question. So I’m personally sold on Observables and I would like to see them throughout the framework. One of the experiments we still have to go through is to try to replace all of the Promise APIs with Observable APIs and see if that makes sense. This is still in the early stages, so we don’t know if this is actually something that we want to do but I think it’s going to be a very interesting experiment and if it does work out, I think we could get a lot of benefits out of that.

MISKO HEVERY: I’d like to add something to it, which is that there’s two parts to this question. One is, what is Angular’s API going to be and how are we going to use it internally? And as Igor pointed out, we’d be thinking about whether we want to switch from Promises to Observables and there’s a second question which is, as a developer, can I use Promises or Async 08 and all the other stuff? And the second question is I think more important because that’s what you will be writing and we want to make sure that you have a choice to do all of the above.

HOST: Awesome. OK, right here.

AUDIENCE: Is server-side rendering going to be a thing in Angular 2.0?

BRAD GREEN: Misko, you have some thoughts on this.

MISKO HEVERY: I do.

IGOR MINOR: Be careful what you say now.

[LAUGHTER]

MISKO HEVERY: So we have a lot of things in Angular 2.0 to make it possible to run things on a server. To start with, we can, for example, run the HTML compiler in offline mode, ahead of– before you ship it to the client. We make sure that– we have this thing called a ProtoView, which is an intermediate representation of the compiled data set. That thing is written specifically in a way that it’s serializable, so that we can do it offline and we can ship it down serializable way. The idea of rendering at the server, because we’re doing work to make sure that the HTML compiler can run offline, which means out of the browser, you could imagine that it could run on a server and generate the code, because we can emulate Shadow DOM. Therefore, we can spit out all the HTML and because we’re doing the Shadow DOM thing and because we’ve made this other choice, which says that the index.html we never touch it all of the application actually runs in the Shadow DOM and because they’re projections, the Light DOM can get reprojected.

It’s too much information, I know. All of those things are I would say steps in the right direction. Where are we going to take the actual final step and put it all together? That remains to be seen.

BRAD GREEN: Maybe.

[LAUGHTER]

[APPLAUSE]

HOST: All right, since Angular 2.0 can run via Web Workers, do you think it wouldn’t be too far fetched to have multiple Angular 2.0 apps running in their own threads, providing view outputs when needed?

BRAD GREEN: Well, I don’t know if we have an answer to that question. But [? Yeger ?] here is working on the Web Workers thing. You want to talk about it?

MISKO HEVERY: I just wanted to clarify the question is not true.

SPEAKER 4: Yeah, we have some experiments outside of Angular, where we sort of see the value of Web Workers and as Misko pointed out earlier, we can run chunks of Angular on the server, which means not on the UI thread, which means we can also run them on the Web Worker. So I think the stars are aligning but there’s a lot of work remaining to be done.

MISKO HEVERY: I just want to clarify. The question said, since Angular can run on Web Worker and that’s not quite true yet. We are thinking about it really, really hard.

HOST: Hey, we saw a talk. It was in a Web Worker, man.

[LAUGHTER]

SPEAKER 4: We are talking to Glib too actually.

HOST: OK, cool.

MISKO HEVERY: So yes, we would very much like to have that happen.

HOST: It’s a way cool idea, right? OK, let’s take one local.

AUDIENCE: Hey, yeah, so this question was actually brought up in the podcast earlier today and it was something that I was thinking would be somewhat obvious and I thought that it might be answered in the ChangeDetection talk, as well too and it kind of was.

Just I’m wondering if that’s going to be easier or harder. Hopefully, easier.

MISKO HEVERY: It should be the same or easier. So we are actually working on forms and we want to make sure that you can do the same exact kind of tricks like you can do today with the coloration of the forms and so on. Now the differences, we cannot use ngModel the way it is, because it’s bi-directional and we have changed a couple things and that particular paradigm does not work. But you will be able to simply annotate your form and get the data on the right location probably through Observables. The other point I’d like to make is that forms are in this very weird state in Angular 1.x, which is that, when you declare them, they’re declared in HTML and as a result, you can’t unit-test your controllers. So in order to unit-test your controller, you actually have to have the form present because the form contains information like what are the items in the selection whether or not a particular form is required or not and there’s many other situations like that, where you cannot actually properly unit-test a controller. So one of the things we’re looking at is, can we move this metadata into the controller so the controller is truly independent of the view and we can actually unit-test the controller. We can assume that if you have a username and password, we can assert that the username is an email address and then the passwords are equivalent and we can do all of this without actually having the HTML be present. So there’s many things that we’re doing to make this easier but the implication of it is that it is going to be different and I would ask you to have an open mind when you look at it.

HOST: Let’s take another– oh, never mind. Skip this one. Next person.

BRAD GREEN: We got to skip John.

SPEAKER 1: Just kidding, John.

AUDIENCE: Hi, everyone. So question.

SPEAKER 5: Hey look, it’s John from egghead.io.

AUDIENCE: So question, probably mostly for Brad. Considering developer salaries and the sheer amount of time that Angular has existed, how much money to date would you say Google has invested in Angular? And how do you justify that to your boss? Follow up question. How do you help us here justify to our bosses to spend time during work to contribute to open source and to help you guys grow?

HOST: Good question.

[APPLAUSE]

BRAD GREEN: OK, so two parts to this question. So the first part is, how did I, as a manager, decide to invest Google’s money in this? And part of the answer is Google actually invests a lot of trust in their management that they will do the right thing and we do it because not that we think that we always make the right decisions, but because we hire really smart people that are passionate about solving problems. And we have to experiment if we want to have good things and so I just happen to be in an environment where great things are possible and I think being in an environment where our work is not tied to the revenue is awesome because I get to do things like make partnerships with all kinds of cool companies and talk to all of you folks regularly. OK, second part of the question, which is, how do you guys justify to your bosses? Well, so I don’t know what your bosses value but the thing about it is a little bit meta but if you want to reap the benefits of open source the deal is you actually– some people have to contribute to it and really, it’s better if everybody contributes. So Igor’s example earlier of this -I forget what the name of the technology was for loading modules but we don’t know it. Your thing will not be supported, your use case will not work, if we don’t know what these things are. So my justification would be, if I did this, that this is a community effort and we have to be part of it if we want to reap the benefits from it.

AUDIENCE: Works for me.

[APPLAUSE]

HOST: Wait, and how did you feel when you realized you made the wrong investment?

[LAUGHTER]

BRAD GREEN: I will tell that story later after the conference. Things go up and down. We’ve had several times where we thought–

HOST: I was kidding.

BRAD GREEN: –oh, man, what did we do? Not right now.

AUDIENCE: So I haven’t heard anything about filters in Angular 2.0 yet. Is there a plan to bring these in? Or is there going to be a different solution?

HOST: They got filtered.

AUDIENCE: What is happening with filters?

MISKO HEVERY: It turns out we named them wrong. The filters are actually formatters in Angular–

BRAD GREEN: No, the filter is actually a filter.

MISKO HEVERY: The filter filter is filter, but the filter of the pipe is actually a formatter. So it’s really a formatter filter. You follow?

[APPLAUSE]

HOST: Now, it makes sense.

MISKO HEVERY: So actually, in Angular Dart, it’s actually named correctly, and it’s called a formatter. And then we were doing this in Angular 2.0, and we had formatters and then we were– actually, they don’t have it implemented– adjusted in Angular 2.0. but we knew what we wanted to do so we were like oh yeah, we’re going to do formatters and then Victor and I were starting to look at Observables and how we do ChangeDetection and structural changes and we came up with this cool thing and I don’t know what it is. Victor kind of gets excited about it.. and he has cool names like monads or something. I don’t know and we realised that these things are actually the same thing or rather that it was a more general case of the formatters. And so then we decided to rename them again. And now they’re going to be called pipes, because we cannot come up with a better name.

[LAUGHTER]

But they are very, very cool in Angular 2.0. they can do amazing things, you can have in both in a template and also in a component. So both the component author and the template author can add them on both sides with a binding, which is kind of interesting. They compose very well. They can do interesting things. It’s hard for me to explain but like, it’s going to be cool. Trust me on this one.

AUDIENCE: I look forward to it.

MISKO HEVERY: The other thing is, let’s see what was the other misnamed thing we did?

BRAD GREEN: Service [INAUDIBLE].

MISKO HEVERY: Yeah, so just so you know, I’m really curious what talk will [? Shia ?] give next year because we renamed all those things he was making fun of.

[LAUGHTER]

So there’s no template. There’s no filters. The services got renamed.

SPEAKER 4: Transclusion?

MISKO HEVERY: What? Transclusion is not there. It’s Shadow DOM, right?

AUDIENCE: Is there a pipe pipe?

[LAUGHTER] [APPLAUSE]

HOST: You’d be the Pipe Piper, if they used it.

[LAUGHTER]

Oh, that’s good. OK. I don’t see you in line. OK, oh yeah, he did make fun of ng-options. That one was pretty good too.

AUDIENCE: I got a really quick question for Jeff. What’s with the beard?

JEFF CROSS: I don’t know. I just stopped taking care of it, and this is what happened. [LAUGHTER]

AUDIENCE: Got better.

JEFF CROSS: Exactly.

HOST: He charges $10 per stroke, I learned yesterday. I owe him $30.

AUDIENCE: All right, so I wanted to ask you guys about Angular material and the animations. So Angular Material has been coming along. It’s pretty great, and components are awesome. NgAnimate is awesome, look at Auto Time. But if you read the material design spec, right, we have these defined animations down to the specific easings and specific direction flows. If we leave it up to the users to come up with these, then we really don’t have a true material design app. So is there any plans to incorporate Angular Material and ngAnimate to have these pre-defined animations, so that we have true material design apps?

SPEAKER 2: So on material design, on Angular Material, we work very closely with Google’s UX team and the folks who are defining all these things for material design and in fact, just this week, they were reviewing our components again as we’re approaching our 1.0 to make sure that we’re getting everything right. So yes, on the Angular Material side, absolutely. Our goal is to be completely identical to the specs that would make it really easy for developers to do the right thing by just saying nb-button and then it just magically happens.

SPEAKER 3: So in regards to ngAnimate, all that ngAnimate is is just a big black box that shoots out hooks. So with 1.5 and 2.0, it’s just making that better at detecting certain things and giving you the possibility to hook into that, right? So the next big thing is going to be that timeline feature and the timeline feature is going to give the material design aspects the capabilities to add those easing functions but it’s also going to give the capability for the users to override certain things, if that’s allowed. That’s the whole premise. It’s just a solid foundation for all of that.

SPEAKER 2: Thomas Burleson over here.

THOMAS BURLESON: So I wanted to add to that. Often in material design, you have experiences that are much more complicated than just a simple animation. So you have a sequence or a choreography of multiple elements. This is what ngTimeline is going to do. So until we get that more robust and sophisticated, you’ll have a challenge for seeing that material design. A little nervous.

SPEAKER 3: Yeah, what Thomas said.

HOST: OK, we’ll take one last local question.

AUDIENCE: Does Angular internally plan to continue to use Tracer? Or does TypeScript intend to output Dart or some combination of the two?

MISKO HEVERY: So right now, we’re running on tracer. It is true but since the wonderful TypeScript folks have made such an amazing product, are we going to be switching over to running in TypeScript? And they tell us that their compiler is very hackable. So we’re going to write the Dart generation off of their compiler.ast tree. So that should happen in probably a month or so, I don’t know. If somebody is interested in helping out over here, please.

HOST: OK, last question from reddit. How do you see Angular 2.0 competing with or at least coexisting with frameworks like React? And I’ll add Angular 3.0.

[LAUGHTER]

SPEAKER 4: We have no chance against Angular 3.0.

BRAD GREEN: Yeah, I think the new router will let you mix and match frameworks too. I’m pretty sure. I don’t know. I think we talked about this a little in our keynote in that we’d rather not be put in the place of comparing, hey,

HOST: Awesome. Give it up for the Angular team, everybody.

[APPLAUSE]