Telerik blogs
top image

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.

Brad Green @bradlygreen

brad-greenEngineering director at Google where I manage AngularJS and GreenTea (CRM). Also, I have 2 children and 4 chickens. Chickens are easier.

Todd Motto @toddmotto

Todd Motto profile picture
Todd Motto is a Developer Advocate at Telerik based in England, UK. Todd is also a Google Developer Expert, runs Angular and JavaScript training workshops, speaks at conferences all around the world, contributes to Open Source and is heavily involved in the Angular community.

Show Notes


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?

BG: Yeah. There's actually a couple of different things, and if you're in any sort of modern web framework, whether it be Angular or Ember or React or any of them, most of them come with some help for starting, with some kind of language transpiler, be it Babel or TypeScript or something else. And usually what folks want out of this is an upgrade to the latest JavaScript and the ability to use that in current browsers and older browsers through transpilation. And so Angular actually supports straight ES5, ES6 through Babel or TypeScript, and TypeScript with the typings on top of JavaScript. Now this is just one of the tools that people may want to use, because if you have any sizeable project, you're gonna need some sort of task runner like gulp and you're gonna need some kind of CSS processor. And all of these things, take time to download, and configure, and make sure that you can deploy from it. And so for this reason, we've started a command line interface project that we call the Angular CLI. And our intention is that it's in a very ready state by the time we come out with Angular 2 final. Although you can go and check it now.

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: And I'm assuming this helps a lot with things like ES5, ES6 and the future of JavaScript where you can go up a level and not break backwards compatibility with folks.

BG: Yeah, that's right. So the thing that's I think really not obvious is that all of your today's JavaScript, it works in an ES6 transpiler, because ES6 is a superset of ES5. And all of that code works in a TypeScript transpiler, because TypeScript is a superset of HTML5 and HTML6. So all the things you already know work and you can just add things like ES6 classes and the FAT hour syntax, and spread operator, and all those fun things a little at a time. And similarly with typings, you can add types a little at a time and get those benefits incrementally, which is very different from other language ecosystems. I think it's this really interesting thing that's going on in JavaScript right now.

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.

EC: I was just gonna say, from my point of view, that's actually a really big deal because what you're talking about is tackling the issue of having a blank page when you start your app up, and then waiting for all those JavaScripts to load and parse before you actually see an interactive application. So what you're saying is, you're doing server-side rendering to eliminate that while keeping the client-side interactivity as well.

BG: That's right. It's great for the desktop, but it's critical on 2G. If you've got a really thin pipe, you definitely need this. And then for SEO, and if you wanna have application preview scenarios, like if you wanna have a... Twitter can give you a little app preview, or Facebook, to show what your screen is like. They want to interact with a static view of your app and they don't want to run a JavaScript engine.

BG: So we've done that in node, we're actually working with the Drupal team on building this for PHP so we can run it inside their environment. We would like to build it out for many more server-side environments: for Java, Ruby, Python, and we're looking for partners to help us on some of these things, but... Some early talks with some of them. So then, after the server side pre-rendering happens, the question is how fast can we compile the template and run it. And then, how fast can we do deltas, changes to the application as it's in its running state? And so, the thing that we're doing for the compilation is, in Angular 1 we would load your HTML template with Angular markup, and then we would interpret it. In Angular 2, to make this way faster, we've got a version of it that we're almost ready to release, where we actually just compile the code for this as part of a build step. And so this has two effects, one, is it's dramatically faster. It's incredibly fast. It's like the difference between an interpreted and a compiled language. And we actually get to generate JavaScript that can be inlined by the virtual machine. This can be the difference between something that runs slowly and something that runs 50 to 60 times faster than that slow category.

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.

Then the last thing we did was, for the change detection strategies that we work on in Angular. And this is one of the things I think we became famous for is that you can use plain old JavaScript objects, you don't have to subclass from anything. And we made that 10 times faster in Angular 2 than in Angular 1. And for scalability to very, very large data sets, we have what's called 'push model'. And push model allows you as the developer to just tell us when something's changed so we don't even have to check, so even faster than 10x. Or if you're using observables or immutable JS or some other sort of model that would allow us to know when things have changed, we will automatically only update things in the model that's changed. So this, again, dramatically improves the speed, but [also] scalability. It's not related to the size of your document any more, it's only related to the size of how many pieces of data are changing in your model.

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?

BG: We do. Yeah, yeah. So this was interesting, this was an intern project. We weren't sure if this would have any good results, and it's been way beyond our expectations. And the idea is that most machines, even most mobile devices in emerging markets, have multiple cores on them. But JavaScript is a single-threaded environment where we use the sort of asynchronous event queue as a way to process multiple streams of things coming in, like typing and moving the mouse and all those good things. But you can take advantage of another core through this web platform feature, called 'web workers'. Nobody does, however, because it's very hard. And from the web worker, you don't have access to the DOM or a lot of the window properties, things that you'd want to get at to do real work.

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.

BG: Yeah, Redux. So, we're very excited about this functional programming tool called observables, which is slated to be a standard in some future version of JavaScript. Because what it lets us do is have a standard way to process streams of events, and actually have a much more robust experience on the web and with NativeScript. Because what you can do is, unlike in the techniques we have on premises, you can, for a data stream coming back from the server you can say, "Hey, the user actually did something else. Let me cancel that so we can lower the performance requirement." Or, "This connection seems flaky. Let me do a retry on that." And there's really no good ways to do this in JavaScript currently. And we kinda live with that on the web. We're just like, "Eh, it didn't work out, just reload the page." But on the mobile experience, users don't have to deal with that, because they have ways to professionally deal with the error conditions and the unexpected cases, so we're excited about that part.

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?

24:57 BG: ngrx, that's right. A couple other differences. So one is the... Like the templating language that we builт is just HTML, and so that means you can use it in any HTML tool that exists. And it's also nice because it's declarative. So if you've got designers on your team or integration test-specific folks on your team who may not be able to understand the intricacies of the way you've designed your JavaScript, they can just look at the template and they can actually reason about it, because it is declarative. It's like the difference between saying, "Center this item on the page," versus in scripts, I would have to say, "Well, find the height, the width, and divide by two," and it's just a lot easier to follow a declarative language. And so I think it's much more inclusive for multiple roles in a team, so it maybe more appropriate for bigger teams.

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: Yes, yes, we've talked about integrating the two, and I think there's no reason not to. We need to have probably another couple discussions about it, about how to do that bridging. But yes, I think the idea would be like this lofty vision I just painted. This would be something that we could all get together on - anybody building JavaScript, whether it be for native deployment like NativeScript or for web-built targets or desktop-built targets, we should all share the same core infrastructure, and particularly anybody using TypeScript and probably ES6 could benefit from this.

EC: Yeah, we just did a show previously on JavaScript fatigue, which is all these new things and there's a hundred different tools to tackle the same problem. So I think there's gonna be quite a few people out there that are keen to the idea of having one CLI to rule them all, so to speak.

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.

TM: Yeah, I think it's just a big architectural shift because I think there was a lot of front-end developers who came to Angular, like myself, from a website and jQuery background and playing JavaScript applications to building Angular who are used to this concept of pages and then you look back four or five years, and you look at all the first kind of wave of Angular apps as Angular started to gain popularity and everything was like huge views and like NG this everywhere. I think nowadays it's, if you're obviously looking at Angular 2, so the restructure is a lot different to be able to get your application in Angular 1 to that position where you can begin upgrading Brad's team's tools, so you can't... I guess you can, can't you Brad, you can put NG upgrade in forward into what we call a messy Angular 1 application but to have that base structure in a very Angular 2-style structure, would make things a lot easier for people to adapt.

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 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.

EC: And I'm gonna throw a shameless plug in there and let people know to stop by We have excellent folks like Todd Motto and Cody Lindley always blogging about Angular, Angular 2, JavaScript and there's plenty of awesome resources.

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.

Ed Charbeneau is a Developer Advocate for Telerik
About the Author

Ed Charbeneau

Ed Charbeneau is a web enthusiast, speaker, writer, design admirer, and Developer Advocate for Telerik. He has designed and developed web based applications for business, manufacturing, systems integration as well as customer facing websites. Ed enjoys geeking out to cool new tech, brainstorming about future technology, and admiring great design. Ed's latest projects can be found on GitHub.

Related Posts


Comments are disabled in preview mode.