And finally, Codecov. Codecov is code coverage done right. Reduce technical debt by visualizing test performance and faster code review. Codecov is highly integrated with GitHub and provides browser extensions. Learn more at codecov.io. It also is free for open source projects, which is super awesome.
So, while we're going through the show today, if you have any questions, if you're watching live, then you can use the hashtag, #jsAirQuestion on Twitter. And I have that open and I'm looking at it and we will answer those questions, during the show or at the end of the show. We'll answer as many as we are able to. So, ask away.
KENT: And I am your host, Kent C. Dodds. And we have three amazing guests today. Brad Green.
KENT: Igor Minar.
IGOR: Hi, there.
KENT: And Misko Hevery.
KENT: And we're super excited to have each one of them here on the show with us today. Before we get into our subject about Angular, I think it would be a great thing to have each one of them introduce themselves. So, Brad, why don't you go first? Give us a little intro to yourself.
BRAD: Sure, yeah. I'm Brad Green. I'm an Engineering Director at Google. And I work on the Angular project. And these guys tell me what to do.
KENT: Awesome. Igor.
IGOR: So, hi, I'm Igor Minar. I'm a Software Engineer at Google and I'm one of the leads on Angular.
MISKO: Hello, I'm Misko and I'm a tech lead on the core of Angular 2.
KENT: Great. Thank you for your work. So, let's go ahead and I think a good starting point for us is just the general question, what is Angular?
KENT: Cool. When you're talking about platform, can you actually expound a little bit more on that? On how Angular is becoming more of a platform? Like, do you mean that it's gonna be more than just web technologies? Or what are the actual use cases that you're hoping to see Angular be kind of a part of?
BRAD: Yeah, so, Angular 1, architecturally, we were tightly coupled to rendering from the DOM. There was no good way to plug other renderers, other template engines in. Like we know, if you're successful, you probably have a bunch of different platforms you need to develop for. And to be able to share code and expertise across those development targets, you know, this is not an easy thing. But we think web tech has really gotten to the place where you can reliably deliver to all of these platforms, maybe with some different renderers. Misko, maybe talk about the split we did in Angular 2 to allow pluggable renderers and templates. Could you explain the idea?
MISKO: Right, So, in Angular 2, we wanted to make sure that you don't need to get hold of any over the DOM API, when you're developing an application. So, the injection system was beefed up. The markup was beefed up. And all these things were really done so that you don't have to get hold of the DOM. As a result, your application can run really in any environment, whether it's a server or web worker. And the renderer, we have a default renderer which renders the DOM, but we have other renders. For example, one that serializes across wires, so you can actually have the application running a web worker and then there's the UI. And it turns once you have a running serializer across the web worker, there's actually no difference whether the application actually might be running on a node and can serialize it to the browser as well. We have other renderers. For example, for React and NativeScript which actually allow rendering to native widgets and native ui.
KENT: Very cool. So, can you, since we're kind of on the subject of platform, can you talk a little bit about Dart? And how Angular 2 and Dart work together?
KENT: Since we're continuing on this topic of languages, can you talk about why TypeScript is important to Angular development?
BRAD: We just did an interview on Microsoft Channel 9 with Anders where we talked about kind of the history, but Misko, you were most involved, talk about how we started with languages.
MISKO: Metadata, yeah, etcetera. At first, we started with this idea add script, but luckily we met the TypeScript.
BRAD: But we were gonna write our own language. That's right.
MISKO: So, yes. So, yes, but we met up with TypeScript, and they just said "Well just add the thing in there for you and you can have all the benefits that you want." This is the reason we started down this path, but it turns out having type systems is very important because it allows large teams to work together. If you have a team of 20 or 30 people working on a particular project, it's just not possible for everybody to keep everything in their head. So, it helps if you give things names which are types. It helps if there's a formal verification system that says the thing that you made is actually the thing that you have. And so, it's really an enabler for large-scale teams. Once that happens, it's also an enabler for refactoring. What Anders likes to say is without types, you end up having right-only code base. That is, you can write code and have large code bases, but everybody is afraid of changing anything once things are up and running. With the type system, it becomes a read/write code base. It's not only that you're writing code, but you're also rearranging it as well.
BRAD: Yeah, that's for developers, but we actually benefited ourselves from writing Angular in TypeScript.
MISKO: Right, we did benefit as you pointed out...
BRAD: We found bugs. (laughs)
MISKO: We found bugs. A lot of team members, I think what Brad likes to say is "Now I actually understand what I'm working on." (laughs)
BRAD: Because you can actually traverse the code base and find the source. It's nicer.
IGOR: We often talk about the benefits of the type system for big projects and big teams, but I find that even on small projects, it's beneficial. Especially, many small projects. Just keeping all of them in your head and understanding how they work is just not feasible. And also, when you are starting, you just need to explore what kind of APIs are available, if you have type system, you can get much better tooling support and the tools can help you explore the API surface, understand how to wire things together, tell you when you make a mistake. So, it's beneficial for both beginners working on small projects, but also experienced developers working on large projects.
BRAD: Right, I think for the individual experience, my IDE gets to help me a lot more to find out what is this API I need to use. Whether it's an Angular API or a DOM API or whatever it is.
MISKO: It turns out you've been using a subset of TypeScript all along.
BRAD: It just works. Things just work together.
MISKO: And you can slowly introduce the types, as you see fit.
KENT: Very cool. With that in mind, is there any plan to upgrade the Angular 1 code base to be TypeScript?
IGOR: We had some thoughts about this, but it's a big undertaking. We really want to get Angular 2 out of the door and help people migrate from Angular 1 to Angular 2. We don't see that it would have the impact that it would be worth justifying the cost.
BRAD: Yeah. We have an export of the types on Angular 1. So, people can get a lot of the benefits from Angular 1 using TypeScript, already. And us, rewriting it in TypeScript, probably doesn't give you much, if anything more than that.
KENT: That makes sense.
IGOR: With TypeScript, there is a way to have external definitions of the type surface, system surface. That already exists on definitely typed which is a repository of these type definitions.
PAM: I thought it was interesting when you mentioned how people seem to understand the project better in TypeScript. And that sounds like something I've heard from the community about learning Angular 1 or learning Angular 2 is that they find Angular 2, a lot more understandable. Not even necessarily because of the TypeScript part, it's actually, I know, the components part a lot of people really like. And the... what the hell is or "what the heck is a directive?" question.
BRAD: Misko, would it work?
PAM: ...a little more understandable. What do you think about how you've made, like how are you making Angular 2 more accessible and understandable for your everyday developer?
MISKO: So, we spent a lot of time simplifying things.
BRAD: We got to see all of the things we had laid out that grew organically over the time of Angular 1.
MISKO: A lot of things in Angular 2 just happened to be the way they are because they organically...
BRAD: In Angular 1.
MISKO: In Angular 1, yes. So, Angular 2, we wanted to really just take a look at it and simplify it as much as we could and I think we did a really good job.
MISKO: And, you know, let me add to it. The other thing that might not be obvious is that Angular 2 is a lot more toolable. And so, companies like WebStorm which provide their IDEs can give you a lot more help navigating through clicking through the HTML, getting back to the components and the related formatting for it, etcetera. And so, you're gonna see a lot more rich kind of experience with Angular 2 and the IDEs.
PAM: How do I have an echo?
KENT: I just muted the Angular guys. Sometimes this happens in the middle of the show. Apologies to our listeners. I feel really bad, but maybe Brad, if you could mute and unmute yourself, that'd be great. Thanks.
PAM: When you mention, the key phrase, that there's one way to do things, that sounds like "let's establish conventions." Do you think that... because that's one of the things I don't know what your experience is w Kent, but I haven't seen, I don't know if there are a lot of conventions around Angular 2 yet or if they will develop. I'm thinking about like in Ruby world or even in Ember world where there is a right way to do something. Is that something you would want to see in Angular 2? Like is that a goal?
IGOR: Yeah, it is a goal. As Brad mentioned, the scope of Angular 2 is bigger than the scope of Angular 1. In Angular 1, we built the core framework and have people basically figure out how to use it. And the best practice information evolved over time as we got more familiar with different use cases and as the whole ecosystem evolved. With Angular 2, we have a lot of experience with building large applications. You know, with Google and also outside of Google. And we're taking all of these experiences and building a style guide for Angular 2 which is gonna be part of the documentation. All of the examples and tutorials are gonna reflect this and it's gonna be built into the CLI which is gonna help you bootstrap your project. And generate all of the scaffolds for you. We are working with John Papa and Minko Gechev on this and there's gonna be a single style guide that's gonna be recommended to the whole community. And one thing to realize with the style guide is it's really a recommendation. There's nothing in the framework that prevents you from using the framework in a different way. This is just a recommendation for you to get started, to learn from the best practices that we know of today. And if you find that in your company there might be some reason for diverging, then you should feel free to do that.
BRAD: But we're coming with a bunch of experience about building apps already. Like internally at Google, we've built a bunch of Angular 2 apps. We've see a lot of the ways points get put together. The thing that is also great, in addition to the CLI, which will setup your directory structure and initial code, the way it works with the conventions we lay out in the docs, Minko's also building a linter that will take as many of these things and give you real-time feedback as you write the code. "Am I following the conventions or not?" It's optional, but it seems pretty cool.
IGOR: One thing that's part of the style guide is explanations as to why there's a certain recommendation because that gives you insight as to why is this best practice and is it applicable to use the script.
BRAD: So you can make your own decisions.
PAM: A bunch of those things you just mentioned, is that CLI out or?
IGOR: The CLI is currently in alpha. It still being developed and the style guide effort is undergoing. And we are slowly taking the stuff from the style guide we have today to move it into the CLI.
IGOR: A lot of feedback we get is that Angular 2 seems complex, but when people dive in they realize it's not Angular 2 that is complex. Angular 2, as you mentioned, the whole component system is very simplified compared to Angular 1. The friction really comes from the setup of the tooling and dealing with all of the new stuff that is in browsers that is corrected to polyfills and that needs to be set off. We see this as temporary state until the browsers implement many of these features and over time, you will rely less and less on polyfills. However, what I also see is visitors online comes up with new standards like async functions, developers get really excited about them and want to use them. So, while we say that many of these things are temporary, I see that over time they're relying on tools won't exist, but it's just gonna get smoother.
BRAD: I don't know the details. I think it's orthogonal to ESLint. This is more about style.
IGOR: I don't know the implementation details. My understanding is that nglint which is an already existing project. You can google it. It's Minko Gechev's project. My understanding is that it's built on top of TypeScript language services. He has a rule-base system where he verifies if the AST diverges from the expected rules.
BRAD: So, it is actually used with some plugin to the TypeScript language system that Chuck, on our team, is working on. One of you know about what he's doing. Misko, you created the issue.
MISKO: I'm sorry, the metadata?
BRAD: Metadata, the language services, the structure you're working on?
MISKO: So, Chuck is working on a collection of services which allow us to, there's two benefits we get out of it: first of all, we can adapt the tooling, so, IDEs like Visual Studio can provide the completion and just lots more insight. It's not just Visual Studio, but really any IDE that uses TypeScript services, including like even if you have it setup for VI, Sublime or anything like that. The other benefit we get is that we can, by collecting all this data, we can then run the compiler offline and generate the source code of the application and then ship it to the client. The benefit there is that one, it's shipping out less code, we don't have to ship the framework. And actually the stack message, the error message becomes a lot more useful because instead of having this meta stack trace that talks about, generically, how the framework does things. Now you have a stack trace that directly points to a specific line or will generate a code which will refers to a specific line in the template or CSS or the comment over there. And so, it's a lot more insightful as to what's going on. I mean, you can actually put grade points on a specific if check rather than just generate grade hoards across all GNU section.
IGOR: The cool thing about this is that basically we take all of the HTML code and all the metadata, translate it into code and once we have that we can do minification on this code. So, while templates and metadata can be hard to minify because the framework needs to be able to read them, once we process them, we generate instructions in the form of code and that code can then be minified and made much smaller.
KENT: Very cool. Yeah, that actually kinda touches on the thing I wanted to talk about next which is performance. Performance has a lot of different vectors. Minification being one of those. What are some of the things that Angular 2 is doing to make performance awesome?
MISKO: What we've done with the code generation, But during the codegen, we create code which in technical terms is called monomorphic code. Turns out the VMs love monomorphic code. It can optimize it very well. So, by doing that, we can get really amazing performance. Not just in terms of runtime, but also in turns of startup because you don't have to boot...
BRAD: Cold start.
MISKO: Cold start, sorry, in terms of the cold start. And in terms of how much we have to, memory pressures as well, and how much we have to actually shift the browser. So, all of those are kind of great benefits in performance. The other performance we're looking is we spend a lot of time just making sure we can render things fast. We got it down to essentially one line, piece of line that basically says, "if previous value is not equal to current value, then" reference to a DOM element dot subtext the new value, right? It's hard to imagine how this line of code could be shorter because the new value is literally the expression you placed in there.
BRAD: One point to compare and only if it's stripped, do we get to update.
MISKO: And you know exactly where to write because the general rule is code, so it's not like we have to go to hashtag lookup or anything like that. We know exactly where to write the information. To be as flexible is obviously fast. You look up the code and you go like, "Well, it's just checking and then writing." So, I can't imagine how we make this shorter or rather faster.
BRAD: And there's very little to do because there's just not much to check. There are a bunch of other things we're doing for performance. So dropping the compiler, generating the code, changing the change detection output, but also exploring some other routes because it's not just about the rendering performance, it's also startup speed and how much do we interrupt the UI thread. And so, for startup speed, we've been working with a bunch of external folks. Patrick Stapleton and Jeff Whelpley on Universal where we can render on the server for a very fast initial startup speed. And then working with Web Workers, so we can actually offload Angular into a separate process and not interrupt the UI thread and make things always responsive for the user.
MISKO: I'd add actually one more thing to it which is that by default, we run the good old change detection, right? The thing that people have come to love which is very friendly towards other libraries etcetera, but we are setup in a way that we can actually run other strategies. So, for example, if you choose to make your code in immutable, you can flip a couple of flags and make the framework take advantage of this thing.
BRAD: So, there's even less work for us to do that.
MISKO: There's a little less work. And the important part here is that this can be done on per component basis, right, rather than on a global basis. So, you can have this hybrid application where you say, "For the top level, actually, I really prefer the change detection because it's simple to reason about. But for the lease, for example, I'm gonna choose an efficient, immutable algorithm or something like that." And it also supports Reactive/Flux style programming model as well. So, you do have a lot of choices. So, I guess to summarize like we can, the stuff we do, we do faster. We give you a bunch of other options, in terms of how to detect changes and we allow you to offload stuff onto different threads.
KENT: Sounds like you've opened it up to a lot of additional experimentation and exploration, as well. That's awesome to hear.
PAM: So, on a different tack, it sounds like you have lots of thoughts on performance, (laughs) but what about moving across platforms? So, shipping projects on mobile and you talked about the ability to ship to all these different engines, but what does that mean for people thinking like, "Okay, Angular 2, how do I put it on mobile?"
BRAD: Yeah, well, there's two kinds of routes. So one is what we'll call mobile web and you may have seen some of the studies recently, where folks like FlipKart, have gotten a tremendous amount of engagement by just focusing on their mobile web story in this progressive web-app style application, where my app when I first surf to it, for the user it looks like a website, but it becomes more like an installed app as I use it. So, on first download we use service workers to cache the data and the codes. So, that the next time I come to it, it's already there, very fast. And this is where people actually make money. It's very hard for me to get my app installed. Most apps on the AppStore or PlayStore never get installed, ever, not once. But people are still able to make money by driving people to their websites on mobile. So, this is where we really wanna help people build into this problem space. We take advantage of Angular's much more minimal memory pressure. You use much less memory, faster change detection, offloading some of the work to web workers, if you've got an intensive application. So that you can have a completely native performance experience over there. And we've got a team actually focused just on this. It'll have starter code, it'll be part of the CLI, it'll get started quickly, go down that path.
IGOR: Their performance is very good.
BRAD: Their performance is very good on that, yep. So, those are some of the options. And I talked a little bit about desktop with Electron and Windows Universal being the target shells that you can use over there.
KENT: So I think Pam actually wanted to talk about Rx. Is that right, Pam?
PAM: Well, I found it really interesting to, I'm a big fan of the RxJS project, and you all use it in Angular 2, is that correct?
PAM: And it seems timely since listeners, you can tune in next week and you know, hear about RxJS. So, I kinda wanted to ask what you all, why did you use RxJS in your tool chain? How do you think it's beneficial?
IGOR: I can take this one. So, in Angular 1, when we were dealing with the problem of synchronous programming, we looked at is there something better than callbacks that we can use and expose us APIs and we came across promises. And promises really solved the problem of one-time events that are asynchronous that need to respond to in some way and handle errors. One of the big selling points of promises was composability. So, you could setup chains of events that happened in some succession and all of them are synchronous or potentially synchronous and basically you can setup complex applications in this way. In Angular 2, we had more and more needs of repeated events, not one times events, but things that happen over and over and over again. And promises are not great for mulling these kinds of situations. So, we looked around and somehow I managed to come across Jafar Husain from Netflix and Ben Lesh and I saw their presentation. And it totally opened my eyes because I saw all the problems we were dealing with and we couldn't solve well with promises were really well-modeled through observables. And Ben Lesh was, at the time, starting the RxJS project. So, we talked to him and basically came to the conclusion that RxJS 5 would be a perfect fit for what we are trying to build with Angular's framework and expose observables as if we're using APIs. Combine that with the effort, to standardize observables (mumbles) and make it part of the language, it made us feel really good about relying on this kind of APIs, as public facing APIs.
IGOR: This is the composable impact of observables, just like promises, it was much easier to reason and recover from errors or at least, handle errors. With observables, you can do that same thing, in much more complex situations that we see more and more frequently in complex applications where networks connection is slow or fails or you have various errors that popup during the runtime and you need to deal with them in some way that doesn't crash the application and you don't need to tell the user to just restart.
KENT: I'm really disappointed, but not because of your answer, your answer was great.
PAM: Yeah, that was a weird lead in.
KENT: Yeah, that was a weird lead in to what I was gonna, what I'm disappointed about is that we're coming down on our time and we do have a couple of questions on Twitter that I think we should probably get to because we care about the people. So, if anybody is watching live, you can ask on Twitter with the hashtag, #jsAirQuestion. If there's anything that we didn't cover that you'd really like to, make sure that we cover it. I'm gonna go ahead and lead into that, unless there's anything in particular, that you all want to make sure we cover.
BRAD: Let's hear it from the twitterers.
KENT: Yeah, let's go. So, I'm not sure if I'm pronouncing your name right, but I think it's Evgeniy Oz. He asks, "Will Firefox and Safari be supported before RC1 or after?"
IGOR: Before. We already run tests and I think there are a few failing tests in Safari, right now, and we need to fix those, but definitely before RC.
KENT: Very cool. And actually, just to ask more broadly, what is the browser target for Angular 2?
BRAD: So, it's all the evergreen browsers, of course, but IE9+ and then Android 4.1+
IGOR: We're going with the limitation that IE9, we don't expect great performance in some situations. It's just not feasible. There's only so much we can do, if the engine is very slow, but the code itself will work.
KENT: Awesome, yeah, those people need to get off of IE9. That's pretty much all that we can say. (laughs)
BRAD: Actually, I mean, just to be really clear, It's not that everything in Angular will work on those platforms, but the core will. So, like our material design we're targeting the evergreen browsers for that.
KENT: Okay, yeah, and I imagine web worker stuff and whatever service workers that's obviously not gonna...
BRAD: Yeah, that's IE10 and above.
KENT: Larry King asks on Twitter, "Thanks for everyone's great work on Angular 2. Any updates on status of 1) animations and 2) minimizing Angular 2 payload for mobile?"
BRAD: We talked a little bit about minimizing payload. So, we're dropping the framework by going to a compilation stuff. But we're going to be looking past that to reducing it further, through a bunch of techniques. One is by tree shaking. I don't know, either of you wanna talk about some more points?
KENT: Nik Mad asks, "Any planned support for migrating from Angular 1 to 2?" So, we didn't actually cover this, but I think lots of people are interested.
BRAD: Misko, you built these piece.
MISKO: Right, so, there's an ng upgrade and a polyfill which allows you to, it's not a polyfill, but some kind of magic, that allows you to run Angular 1 and Angular 2 components side by side on the same webpage. You can mix and match. You can inject Angular 2 components in Angular 1 and vice versa. Angular 1 is not great with 2. Obviously, the services can be injected across boundaries, etcetera. So, the idea is that we would migrate a component at a time, from Angular 1 to Angular 2.
BRAD: So, you have options. You can either do a big bang migration or you can do it a little bit at a time, if you wanna spread it out and continue shipping.
KENT: Do you have any success stories about people upgrading so far?
IGOR: We are currently running several pilots. We're figuring out applications bigger teams have taken ngUpgrade and migrating from 1 to 2. Once we have more data, we plan to publish a blog post and share the experience, but we're not there yet.
KENT: I think that's all of our questions from Twitter. So, we'll move ourselves into the tips and picks. We'll let Pam go first because she might drop out due to battery problems. So, go ahead, Pam.
PAM: Sure, yeah, my poor computer is making lots of noise. So, I have a tip. Git tips are always fun. So, I tweeted a little earlier today about using I often use Git rebase interactive to clean up a pull request. And so for a long time, I always used S for Squash and then suddenly edited my commit message afterward and then I discovered F for FixUp which also leads into a pick. I tweeted about that and someone linked me to Git Tips which is a nice repo of Git Tips which is always fun and you always learn something when you read someone else's tips. It's kind of like trying vim tricks and stuff like that.
I have another pick, too. My friend Luna has a How to Make Programming More Accessible series that she just started blogging about including making open source projects accessible to new contributors which I know Kent, you're a big fan of. So, you should definitely check out her series for ideas on that.
KENT: I am a big fan of making things easy for beginners. So, thank you. Great, so, I'll go next and then we'll let our guests go. So, for my tip, I'm a big believer in not confining our conversations to one-on-one conversations. It can be really easy to actually just make your conversations public. So, if you have a question about "how do I write a test for this thing?" Like have a conversation over a hangout on air or something. Have it recorded, so that you can make it public and everybody can make the world a better place that way.
My picks are, first, I wanna pick PayPal. I work for PayPal. I work from home. I totally love PayPal. I think they're awesome and they let me do this podcast and I think that's great. So, thank you, PayPal.
And then, my second pick is Soft Skills Engineering. This is a new podcast from Dave Smith and Jamison Dance about everything else you don't hear on other podcasts about soft skills. It's really, really good. They've had five episodes now and episode four is Should I Build My Personal Brand? And it's actually a terrific episode. I recommend you check it out. So, great, that's my tips and picks. Let's go with Brad. What do you have for us?
BRAD: I'll go really local and low-brow. If you are using Angular 2, then the latest version of WebStorm has some amazing abilities in giving you Intellisense in the templates and in your code. It's really cool.
IGOR: I came recently across this really cool web application called Flat.io. F-L-A-T-I-O It's an application for collaborative editing of music sheets. I'm trying to learn piano and I was looking for something where I could build my own sheets and this popped up, it looks really cool. And it's really slick. And when I looked under the hood, it's built with Angular which was the best prize.
MISKO: One or two?
IGOR: Angular 1.
KENT: Awesome. And Misko.
MISKO: So, I just discovered this morning, this amazing service called, it's run by Financial Times and they have a CDN with a URL which ends in something like powerful.js. And what the service does is it looks at your browser agent and says, "You're running Chrome or Safari or whatever, you need these sets of polyfills." And just magically delivers them for you. So, you include one thing and depending on what browser you have, the payload might be an empty file or it might contain, a large set of things that you might need for your particular platform. So, I think that's awesome.
KENT: Actually, on that, WebPack 2 is requiring a promise polyfill. And so, like lots of people used to use WebPack to polyfill promises conditionally and now that WebPack, actually, itself requires a promise polyfill, they're looking for alternative ways do that and polyfill.io can do that for you. It's awesome. All right, so with that, I think that is our show.
Let me just give a quick shout-out' to our silver sponsors, O'Reilly Fluent Conf, Auth0, Trading Technologies, and new sponsor SparkPost. SparkPost is actually going to be... what we use for our newsletter which you can sign up for at jsair.io/email. And hopefully we'll get a newsletter out this week. So, do that, it is gonna be great.
BRAD: Bye. Thanks for having us.
KENT: See ya.