On this episode of Eat Sleep Code, guests Brad Green and Todd Motto talk about Angular 2. Brad Green, Engineering director on the Angular 2 project shares what’s in the Angular 2 road map including the new Angular 2 CLI. Performance improvements, model change technologies and web workers are discussed. Cross platform development with Angular 2 including desktop and mobile using NativeScript are also included in the discussion.
Engineering director at Google where I manage AngularJS and GreenTea (CRM). Also, I have 2 children and 4 chickens. Chickens are easier.
Ed Charbeneau: Hello and welcome to Eat Sleep Code, the official Telerik podcast. I am your host, Ed Charbeneau, and with me today is Brad Green. Hi, Brad.
Brad Green: Hey, good morning.
EC: And Todd Motto is also joining us. Hey, Todd.
Todd Motto: Hey, good evening.
EC: I've brought these folks on the show today to talk about Angular 2. Brad Green is here from Google. Brad, why don't you go ahead and let folks know what you do at Google and what you work on with Angular 2?
BG: Yeah. So I am an Engineering Director here at Google, and I've been working the Angular project for the past, almost six years now, and was one of the project originators along with Misko Hevery and some other folks. And we're excited to roll out Angular 2. We're in beta now and we're getting towards final not too long.
EC: And we also have Todd with us. Todd, give us a quick intro. We just had you on the show last week, but folks tuning in for the first time might not know who you are.
TM: So I am a recent addition to the Telerik team. I'm a developer advocate near London, in England, hence the accent. So I cover the European side of things.
EC: And today, we're gonna discuss Angular 2 in detail. And we're gonna kick things off with some of the tools that you use to build Angular 2. Because things are changing in that regard, especially with the introduction of TypeScript and some of the CLI and whatnot. Brad, you wanna give us some info on what the new tooling is like?
EC: And one thing I find really refreshing about the Angular tooling is that you're working along with other companies such as ourselves and Microsoft 'cause TypeScript is a Microsoft thing that you guys have adopted. I think that's really cool, to see two big companies like that reaching across and working together on something like Angular 2.
BG: Yeah. So we originally kind of were building our own type system on top of a Google transpiler that we built, this pseudo language called AtScript. And it was about that time TypeScript was starting to get big and somehow we found each other, and we worked with the TypeScript team. They actually built in all the features that we wanted that were sort of a delta from TypeScript. And it's been a great partnership. You can see it's, I think, in our community, in Angular 2 when we survey folks, it's the most popular thing that people most say that they're going to target in their new development in Angular 2, second by ES6 through one of the transpilers that does that.
EC: What are the some of the benefits that you get from using TypeScript?
BG: It's funny. We were in, kind of, the untyped camp for a long time. A lot of our folks came from the Java background, and had a bad experience with having to satisfy the compiler by putting types on everything. And so we were really kind of in the, "Oh, we don't need types, we don't need those stinking types." And then we got to using them in TypeScript, and we had a very different experience than we had in Java. And then… Nothing wrong with Java. Like there's a lot great positives to it. But sometimes you end up having to, if you have a typing system, meaning you have to type a lot at the keyboard. But TypeScript is this optional thing where you don't have to add them everywhere, and wherever you add them, they actually give you a lot of leverage in the IDE and in other tooling where they will first of all, find bugs for you. We actually found several bugs in the Angular system, and we were kind of surprised because [those were] very high levels of unit tests and yet we found stuff.
Another secondary benefit that we were kind of a little surprised about is, our team felt that they understood the code base better because the types give you a really nice way to traverse and understand where the dependencies lie, because they're specified explicitly. And with the IDE help, they allow you to jump around through the source code really, really quickly without any searching. And then we get a lot of the things that you get from, again, with the IDEs and other tools, that you get from other type languages like really solid re-factoring, and ability to see the documentation for any class, and ability to jump through to source definitions and fun things like that.
EC: Yeah, we're talking about increasing the benefits of the building side of things and the performance of the developer. What are some of the things that we get out of the box that help us with performance in Angular 2 on the application side?
BG: Ah, yes. Well, this is one of the primary goals of Angular 2, that we would really nail the performance story, in a way that I think we've never seen on the web before. And so we've redone everything to the core and there were some… We have some struggles in Angular 1 and there's a lot of things you can do to make Angular 1 applications fast. But it's kind of on you, and we wanted to make things fast by default out of the box. And so we looked at a couple of the scenarios. And there's no just one scenario in the world of performance. You don't get to be fast by doing one thing. And I'll carve it into maybe a couple buckets. So one is, how fast can I render that first view? And for that, we have worked with some of our partners to build the server-side rendering story, where in Node, we can actually run the whole Angular and we've decoupled Angular from the rendering environment.
So we can actually render it without a browser, generate all of the HTML and CSS, combine it with the data that you have on the back end, and then just ship down that HTML CSS view and not have to wait for the application or the framework to load. And so users can see their first view of the application, start consuming it, start actually interacting with it while the app is downloading. When the app is fully engaged or it's sort of woken up, we will replay those events that… If a user's been typing or scrolling, or whatever they're doing to the UI, we replay them to the application so that they can do the mutations on the data as they expected. So that's phase one, do you have a question? Sorry.
The other effect is that Angular gets much smaller. We're actually doing code generation not just for the compilation but for dependency injection and change detection and for our expression per se. So we get to not only make all of that super fast, but drop all of those pieces of the framework so you don't have to download them as part of your application startup time.
EC: So when you're referring to some of the change-detection technology, one thing that comes to mind is people talk about the virtual DOM with React. Is that a similar concept then?
BG: A little bit. So React, they made this virtual DOM technique popular, and it has a lot of nice properties. But your application scalability in any virtual DOM system will be limited by the size of your document 'cause it's proportional. So it'll be this thing where, "Oh yeah, it seems fast," until your app gets very large, and then there'll be nothing you can do about making it faster. And in Angular, on the other hand, you can have as large a document as you want. And when we build our data models, we do a map between the data that you have coming back from the database, or are generating yourself, and the DOM element that it maps to. And so we don't have to diff the DOM, we only have to diff the data model. And this is the equivalent of doing a whole bunch of string comparisons versus just comparing a couple players. It's incredibly faster but it's really much faster at the machine level, and with the push model that I just mentioned, it drops most of the work away, there's almost nothing for us to do. So you can think of it like, there's the DOM diff-ing, which is I diff the whole document, and then there's model diff-ing which is what Angular does. And what we only have to know about which little bit of data has changed since the last refresh.
EC: And I also noticed looking at some of the documentation, you guys have support for web workers in there as well, is that correct?
Now Angular 2 provides this abstraction layer that you can talk to Angular and get at all of those features. But if you configure the bootstrapping in Angular, say, "Please use a web worker" then we'll move most of Angular and all of your code into a web worker. It can run off the UI thread and you can make sure that UI thread remains as responsive as it can, 60 frames per second. Never slows down in scrolling. And you can be doing as heavy lifting as you need to be, either processing data coming back from the server or doing garbage collection or what have you and the user will never know. The nice thing about the way we do web applications is it's this event-based model and so we've just moved the source and sync of the event consumption to the other side of this web worker. And we handle all the communication between the UI thread and the web worker thread on behalf of the developer. So a lot less work for people to do.
EC: So all these things add up to an application that has more of a native type of experience. And speaking of native experiences, Angular 2 isn't just for the web anymore, right? You can actually use Angular in node-based applications. One example might be Telerik's NativeScript. I know your engineering team and ours are actually working on some implementations there.
BG: Yes. So, we've been working with your NativeScript team for quite a while. And so when I mentioned that we've de-coupled the rendering layer from Angular where we can render in NodeJS or on the other side of a web worker, we worked with you to replace Angular's renderer with the Native UI on iOS and Android and use the Telerik one.
Now, we also worked with you guys to replace the templating language. We can now use, because of the work you guys have done, Angular developers can use Telerik's templating language to describe the way the application will work and I think this gives the Angular platform a lot of growth potential without us having to make any other core changes. People often ask, "Well, you're doing Angular 2 now, will there be an Angular 3?" And this is one of the reasons I say, "Well, maybe not." Just because we have this capability to replace renderers and template languages without making core changes to the framework, and so with nice partnerships like this, we can go to a lot of different platforms.
EC: Yeah, because NativeScript uses XML, so being able to switch out that template allows you to transition from HTML to XML…
BG: Yep, exactly.
EC: Which is really interesting to have it pluggable in that way, it's really extensible.
BG: Yep, that's the plan.
EC: This could actually lead us to building other types of applications as well, like desktop and mobile web and whatnot.
BG: This is another interesting thing that we've started to prove out, where we can move Angular to the other side of the web worker. If you build an application using Electron from GitHub, which is the way people built like the Atom editor, the Slack built their desktop client this way. We can do this special thing with Angular where we move, again, Angular into… Out of Chrome, which is the way you do rendering in these apps, and we can move it into the Node process, which again gives your UI incredible scalability, like it can remain always responsive. But it also allows developers to directly get at the desktop local services. So, you can do things like do native Windows authentication, you could talk to the database directly from your services. You don't have to go through HTTP and you can even talk to hardware. So, if you wanna build medical devices or other sort of sampling things using the same thing you've invested in for learning the web and for mobile, now you can build all these things for desktop in the same way.
EC: So Todd, you've been an Angular developer for a while, what are your thoughts about transitioning from Angular 1 to Angular 2? Have you tried any demos or anything to see what it's like and what the process would be like?
TM: Yes, I had a couple of questions lined up for Brad. So I think throughout the past, however long since React has been alive, it's kind of been a head-to-head. Аnd this isn't specifically an upgrade sort of question. So people will say, "Okay, we use Angular 1" or you use React and React Router and all this kind of stuff and Flux. But I think if somebody stood in an elevator with you and sort of said, "Okay, should I go down the React route or should I go down the Angular 2 route?" How would you sum up to people? Because I watched the Fluent talk that that you gave, and I think if the React community had a glimpse of that and they would kinda go, "Ah okay, we need to do some catching up now." I think Angular 2 had some catching up to do with React at one point, but now it's accelerated far ahead. So what are the main advantages for not going with React and going with Angular 2 and all its additional features?
BG: Yeah, so first of all, I consider theReact guys as my friends and they're very sharp and nice fellows over there. So I don't wanna throw them under the bus too much. [laughter] But they're kind of different things and I agree. Angular 1 was first mover, React leapfrogged it. In Angular 2, we get a chance to look at what's going on throughout the industry, React and other frameworks leapfrogged those things, which is good. Users get to benefit from this sort of learning and they are different things. React is just the renderer portion. Now, if you consider the whole Flux-style architecture, if you consider those things together, those parts aren't different. We talked a little bit about the difference in Angular's renderer, why we can do less work and it could be more scalable. The Flux architecture is actually fairly nice and you can use it with Angular, it actually works very well with Angular 2. It's a little bit hard with Angular 1.
TM: Yeah, with Redux.
And one of the guys on our team, Rob Wormald, has built a sort of Flux-style architecture on top of these observables. And so you get the benefits of both of these in an architecture that's kind of specifically tailored for Angular. Although you could take advantage of it in React also if you were in the React camp of folks.
TM: Was Rob's project the ngrx one?
Last difference is, the Angular team is… We've got very big customers here at Google who need globally accessible software, so we're building internationalization and localization into the Angular framework itself. And we'll make sure it works. You can do this in other frameworks, but usually there are multiple flavors for you to pick from. And similarly, we're building our own router that is built end-to-end to work with Angular and automatically do lazy code loading for you and work very well integrated. We're building an animations library that again is specific to Angular. We built all of this rich tooling, working with the TypeScript team to build it in. So end to end, it's hard to find a more complete environment than what we're building in Angular 2.
TM: So there's a lot of work to do. [chuckle] Well, I won't pester you on exact dates that you've got projected, but let's assume that Angular 2 goes live in the near future. What other plans will be on that? What have we got to look forward to, post-release?
BG: Yeah, that's funny, we did this off-site a couple weeks ago. We all went out down to the coast and talked about big ideas, 'cause I wanted this for our team, too, so that we weren't just looking at the release of Angular 2 as, "Well, what do we do after that?" There's actually a lot of enthusiasm on the team for this one topic, which I would call, kinda like making Angular 2 an evergreen experience. I'll describe what that is. We don't have it all figured out, but, internally at Google, we are responsible for actually upgrading all of the applications that rely on Angular. So when we have new releases, we bring that release into Google and then we actually have to make sure nothing breaks for everybody else. And so we have to upgrade them and work with them to make sure… This upgrade is a lot of stress on us.
And so we've been looking at how could we just auto-upgrade these things through scripts, because it's… I don't know, a third of Google's software developers, front ends, work on Angular. And it would be very nice if we could just automate this process. And if we can automate it internally, well why couldn't we automate it externally for people who use our statically analyzable templates and TypeScript where we have a lot of rich information about the intention of your application? When new versions of Angular come down, we would love to deliver them with the script that just auto upgrades them so that it's little to no stress when there are upgrades. And even if there's breaking changes, we want developers saying, "Absolutely, let's just go." We won't see people lagging multiple versions behind and if there ever were an Angular 3, then they'd just be like, "Yeah, no big deal. I'll run my upgrade script and get that."
TM: Is this sort of upgrades on an AST level, like Facebook do, or…
BG: That's right, that's right.
EC: Is this something that the CLI is aiming to facilitate?
BG: Yeah, and we'd actually like to solve things a little bit beyond the CLI. And I think, we're building CLI as a specific thing for Angular but we actually feel like there's… This is something that could be solved globally for all of the frameworks, just generally as a web build environment. Because they're not really unique problems. And so we're actually really interested in partnering with our other framework friends on building something that could work for everyone. Making it fast, reusing build artifacts. How do we make it zero configuration, incredibly reliable, very fast, and something that the whole community could build on together?
EC: This is very interesting. I know our NativeScript has its own CLI as well, is there any discussion with our group on CLI activities?
BG: Yeah, if you're a desktop developer on Windows or Mac, you're laughing at us right now 'cause these are solved problems. [chuckle] I think there's no reason we can't get there.
TM: Sounds good. I had a quick question on the future of Angular 1. So I know at the moment, you're kind of steering things towards Angular 2. Angular 2 obviously has small component architecture focus and then you have directives as well, whereas Angular 1 obviously used to be just top directive for everything and now we've introduced the component method. (…) But is there anything that's also coming, maybe Angular 1.6, or how far do we see and what can we expect?
BG: Yeah. Well, we do want to move people onto Angular 2. But we've said… We're committed to people who invested with us on Angular 1 and we're not gonna drop you on the floor just 'cause we've got a new hot thing going on. And so we said, "Well, we're gonna support Angular 1 and continue to making releases on it until the majority of folks have moved to Angular 2. And just to paint the picture, there's like about 1.3 million developers we think on Angular 1 and about 330,000 on Angular 2. And so it's not anywhere near the halfway mark yet. And so we're taking on ourselves to make this upgrade path easy and attractive to folks on Angular 1. And at the same time, we know some people may never move certain applications because they're like, "Well, the lifespan of that has got another two or three years, and the upgrade is may be not worth it." And so we want those guys to be happy, too. But at the same time, we are building towards the future. So like you said, we have this nice upgrade path where you can mix and match components. We've built the component-style declarations in Angular 1.5. And then we've just recently released the new router and so you can use that on both Angular 1 and Angular 2. And so incrementally being able to take on these newer, faster, more complete features of Angular 2 inside an Angular 1 application. The next two things that we'll see heading there are the new animation library, which we'll probably need a whole show to talk about but I think it's pretty exciting and the new internationalization facility.
TM: Yeah, I think the I18 and stuff's gonna be quite interesting. So that's gonna be available as a third-party module like the HTTP that we can include?
BG: That's right. That's absolutely right.
EC: Cool. So you're saying we can essentially use Angular 2 and 1 in the same application. So that provides a seamless upgrade path for folks that are on Angular 1 that wanna transition, where they can just kinda piecemeal in and pick pieces of Angular 2 to get started as they kinda morph their application from one to the other?
BG: That's right, that's right. Now, it's not free. You have to download both frameworks at the same time and de-bugging is a little bit harder when I've got both frameworks going on. So we did mean it as a bridge and not as something you rely on forever, like, "Oh, I'll just mix it with some Angular 2 and Angular 1 and away I can go." But it is an option, as you're thinking of planning an upgrade path to think about, like, "Well, okay, maybe I can continue my release schedule and not have to interrupt that while I'm transitioning to Angular 2."
EC: I think some applications are so large. If you try to come to an abrupt stop and then try to transition over to something completely different, you could seriously put some lag on your project and miss your milestones and what not. So that provides you a nice stop gap to get from one to the other, I like that.
BG: That's right. One other thing I'm actually really excited about in Angular 2 is… So unlike Angular 1, where it was kind of the Wild West and we didn't even know what a well-structured application looked like. We have worked with a lot of our community to figure this out ahead of time and we'll be releasing Angular 2 with a style guide. And because a lot more of it is statically analyze-able in our templates and if you're using TypeScript, there's some community folks who are actually making some of those style guide recommendations as part of a linter. So if you've got a big team and people are coming on with various levels of knowledge, you can really give them a boost by having this automated tool that every time I type and save, you can get linter feedback on, I'm doing this not just syntactically correct but idiomatically correct as well.
EC: So sounds like there is a big, exciting future here for Angular 2, lots of new stuff to learn about. Where's the best place to go find out new information about Angular 2.
BG: Well, I think it depends on what style of learning you like to do. Angular 1 docs, we always got ribbed for the quality and we've really invested a lot in Angular 2 and we're getting, I think you guys can judge us, but I think they're pretty good. So there's a tutorial that's pretty in-depth, you can go through and learn Angular 2. And we've just started on the sort of a cookbook example, so if you want to… Like, "I've got a Problem X, how do I communicate between components," or, "How do I do data driven forms," or whatever, you can go look at that in a quick session. If you're coming from Angular 1, there's also a nice, in the cookbook, there's a mapping of, "I know this in Angular 1, how do I do it in Angular 2?" And you can see that part of the cookbook also.
Our friends at egghead.io have done a very nice job on their videos, so you can go over there and check those out. If you like longer form videos, Pluralsight has some very nice Angular 2 videos as well. I think Udemy has a nice course, I've heard some accolades on them and there's others. And then there's in-person training. Our friends at Rangle and Thoughtram and a bunch of other folks, Angular… I'm gonna forget all of the guys and gals who are good to us in building things. And then there's a number of books. There's NG book and Manning has a bunch of popular publications. Packt has some good Angular 2 publications.
BG: You should definitely follow Todd. Todd has had a bunch of fantastic articles lately. Thank you Todd, sir.
TM: Well, thank you for the re-tweets, Brad.
EC: I appreciate you guys both joining me for the podcast today, really appreciate y'all's time. Thanks for joining me.
BG: All right. Thanks for having me.