The crew discusses ng 2.0 with Rob Eisenberg.

Special Guest: Rob Eisenberg.

 

Hey everybody, and welcome to Episode 9 of Adventures in Angular. This week on our crew, we have Joe Eames.

Hey, everybody.

John Papa.

Hey, from sunny Florida.

We have a special guest crew member, Ward Bell.

Hello, from sunny California.

I'm Charles Max Wood from Devchat.tv. And our special guest this week is Rob Eisenberg.

Hey from Florida.

Do you wanna introduce yourself really quickly, Rob?

Sure. My name is Rob Eisenberg and I have spent the better part of the last ten years of my career focusing a ton on front end development across various platforms. And one of the things I'm known for in a couple of communities is building frameworks to make frontend development elegant. And I've worked on XAML platforms, framework called Caliburn and Caliburn Micro. I've worked on JavaScript platforms. I'm known for a library called DurandalJS. And now, I'm currently consulting with Google, helping to design and implement Angular 2.0, and also the next version of Durandal which is connected with that. So that’s a little bit about relevant points about me.

One thing I wanna get out of the way just, because I know people are going to ask, it seems like there hasn’t been a concrete date set for when Angular 2.0 is going to come out, but do you have some idea of what things are left to do? Maybe we should just start out with what's going to be different, or if there's a different focus from Angular 1.0 and Angular 2.0.

In terms of timeline, right now if you are a user of Angular, you know that there's a lot of work going on at 1.3. So we’ve put a lot of resources into that, hoping to get that out imminently. So a lot of attention has been to get to that milestone. Now I can’t give you a date on 2.0 other than to say that we want to have it available as soon as we possibly can. And I think that as we reach this important release of 1.3, we'll then be able to solidify a timeline for 2.0 and hopefully the community will kind of get a sense of that after that point. So that's kind of, we're in a little bit of a transitional stage in terms of timeline right now, as we're coming out of the major 1.3 release, and then refocusing on 2.0.

So what are the differences between 2.0 and 1.3 or 1.2?

With existing version of Angular, one of the things that prompted 2.0 is that over the years of development and usage across applications, a number of shortcomings in the core of the framework have kind of surfaced. And some of these are such that there's no way to really fix them, without doing a rewrite. So first of all, with 2.0 there's going to be a number of core improvements such as a common example is dynamic loading; dynamic loading of controllers, of code services, all these kinds of things that this is much more difficult to do the right way, if not impossible in some cases with the current version of Angular.

The new version is much more sort of living in asynchronous world, and can bring anything in dynamically. So this is a core change and that’s a big new capability for 2.0 that stretches from understanding the shortcomings in the current version, but that we couldn't really just patch up. So there's things like that, mobile support. People do use Angular to build mobile apps, but it's not as fast, or in terms of animations, in terms of startup time, in terms of data binding performance…

When you say ‘mobile apps,’ are you talking about mobile-friendly webapps? Or are you talking about things like Ionic Framework?

Both. Really, any situation where the code of Angular is running on a phone or a tablet. And the big thing that comes into play here is issues of performance, because those devices are just not as powerful as your desktop. So there's a lot of work going in the performance in 2.0, but the use case that’s driving this performance improvements is getting a very slick mobile experience. So there's a lot of improvements that are happening in the data binding system, in the templating engine -these core components of Angular itself -- which we couldn’t really make in 1.x because there would be major breaking changes, but with 2.0, we can go ahead and make those changes, and the result is that the whole thing will be much faster in a lot of ways. It will be better for building mobile apps.

So there's a number of different things like that, touch animations and gestures, like I said, mobile performance, dynamic loading; those kinds of scenarios which to do them in 1.3, it would end up being like a rewrite to get some of that working the way it needs to work. And so that is some of the initial motivation for building 2.0. But there's other things as well to look forward in 2.0, which is we're looking really to the future in terms of how modules will be handled. When Angular was first written, there really wasn’t maturity in that area in the JavaScript world. There were a few things kind of floating around, but it was hard to sort of pick one that would be… there was no ubiquitous kind of module solution.

Are you talking about like AMD with RequireJS, that kind of stuff?

Yes. So some of those were kind of like floating around back in the early days, but it was hard to really know what would be popular at the time, and there was nothing like the ES6 modules at that time. But now, here we are in 2014, the ES6 module spec I think was just solidified yesterday or two days ago, something like that. There are transpilers, there's language like touch script, and there's Traceur and a number of other transpilers that will understand ES6 module syntax and convert it to ES5 code. They are a number of popular libraries like RequireJS and so on for handling modules.

So what we wanted to do is say, “Hey, this was something that back when Angular 1.0 was built, there wasn’t really a clear path for solving this aspect.” But now on 2014, there is. So let’s look at the future; let’s look at ES6 Modules; let’s look at the ES6 loader; let’s look at all these kind of things and see if we can reimagine the framework in terms of a more modularized JavaScript world. And that flows from everything from loading to modularizing your code to package management and all these kinds of things. So there's issues like that, that we're dealing with in Angular 2.0 to make it nicer.

Is that why you (‘you’ meaning the team) decided to do it in ES6?

Yeah, that’s one reason. Frankly, this is my personal experience is after using ES6, really it's just so wonderful compared to what's currently available in browsers. You get used to having lambdas. I mean, we use lambdas, we use classes. A lot of the design of Angular 2.0 right now is a classbased design. And this works really nicely with the dependency injection aspect of the framework, and having the syntax sugar of ES6 for building classes makes the code really nice to read.

I mean, you can obviously build the same thing using the same prototypes etc., but having the actual class syntax in their language portrays the intent of the code a lot better. So we're using that just for the use of it, but also again it's that vision of forward compatibility, because eventually, we want our ES6 code to run directly in the browser. Right now, we transpile it to ES5 code, but by writing it today, we kind of future proof ourselves against having to do another rewrite.

The question that I have, and I'm wondering if a lot of people out there is thinking this too, is I'm a developer and one of two states right now, and others might be here as well. I'm working on some kind of application in midstream, already Angular 1.2.x, when should I start to be thinking about 1.3 or 2.0? And then the other side of it is, I'm a developer who is about to kick into gear on the project; when should I be starting to consider 1.3 or 2.0?

So in terms of the current version of Angular, I don’t actually do development on that. I'm working on 2.0, but the release of 1.3 is coming pretty soon. I think anyone could probably see that, who follows it. So I would be considering 1.3 now.

I think I’ve just checked a release came as of this weekend, I think.

Yes. So if you got existing code and you are considering 1.3, or if you are 1.2 and you haven’t considered 1.3, I would be doing that right now. In terms of 2.0, what I try and tell people who are having to make a decision right now, or building things right now is to basically stay with what you are doing and what you're comfortable with. If Angular 1.0 is meeting your needs, then just keep doing what you are doing.

One of the things that we’re planning to have as part of this process is some documentation that shows the Angular 1.3 code, and then the corresponding Angular 2.0 code. So that anyone who does wanna make that migration or wants to evaluate whether it makes sense for them, can kind of see the two side by side. And that also let you leverage all of your learning or understanding of Angular 1.0 and easily translate it a lot faster because you can find these sort of little recipes that you already understand from the current version of Angular, and then kind of see how that looks in 2.0. And the key goal for this is that everything that you can do in Angular 1.0 today, you should be able to do in 2.0 at least as easy as you can today. But hopefully better, right?

So there's a lot of technical things I've talked about we’re trying to improve with loading and modules and performance and mobile, etc. but we also would like to make the entire API surface, the interaction with the framework, and the general building of apps simpler -- simpler to learn, simpler to do, less work. We'll flesh that out as things go along. But we'll have these documents that you can kind of see it. So it's kind of a guard for us as well, so that when we have the 1.3 and the 2.0 code side by side and when we look at 2.0 and we go, “Oh, man. This is much more painful than it was in 1.3. We've made a mistake here. Let’s see how can we address this in our design.”

So, it's for us too to help us in our design process, but also, it will serve as the sort of documentation of the community, so they can get a feel for what it would be involved in porting their app, they can visually see what kind of the differences are and what advantages it might be in terms of maintainability, learnability, these kinds of things.

So the backup though, I would say to most people asking this question is, stay with what you are familiar with today, and just kind of keep an eye on things. Familiarize yourself with what's happening generally in terms of web trends with ES modules and all the ES6 language features. And you might say that you might say that you might even writing your code today in ES6 using Traceur like us, so you can actually do… there's nothing to prevent you from building a 1.3 Angular app by using Traceur. And then you’ve already got a bunch of your source code sort of in ES6, and you can follow the same strategy that were following ourselves in terms of trying to be future proof with their source code in that way.

I’d like to ask you a clarifying question about that, Rob. When Angular 2.0 does finally release, there's nothing there that says… nobody that’s consuming it is going to need to write ES6 code, right?

That is correct. You can write ES6, ES5, I suppose you could write ES3, but you can write CoffeeScript, you can write Typescript. There's nothing that we’re doing really is going to force you down that path.

But doing ES6 is a great idea.

Yes. And you'll really get the nicest experience by using Traceur, because of some the slick things we’re doing with the way dependency injection works and the annotations we've added via Traceur. You can do all that stuff with API directly, and were working to kind of make that really nice, so it's elegant in other languages. But if you use Traceur the way that we’re using it, you are going to get the nicest experience that way.

I'm a little confused on one point because you are talking about even ES3, and I thought that one of the distinguishing features… not features but one of the characteristics of 2.0 was that it ran in ES5 browsers and beyond, that it wouldn't work for ES3-type browsers or strange ones like IE8. So can you clarify where that boundary lies?

Sure. I guess it's a little confusing from a language perspective in terms of like syntax features, like classes and lambdas and you might use an ES6… nothing that you are going to do with your choice in terms of what features of the language to use will break Angular. However, there are some things at run time that are sort of like runtime components of… it's kind of hard to talk about this stuff, right? Because when we talk about ES6, it's more than just syntax of the language; there is runtime capabilities. So the runtime capabilities right now, actually I'm not sure if we’re using anything that prevents ES3 or not, so I may have spoken a little bit too carelessly right there.

I seriously doubt anybody is going to try to write ES3 at this point.

Yeah. So in general, the framework is targeting evergreen browsers.

Rob, what he really wants to know is are DHTML applications and Active-X documents going to work in Angular 2.0? [Laughter]

The serious point there is that I continue to get battered about support for IE8 because there are people who are locked into in. And I know that the Angular team said, “We are no longer verifying if Angular works. It may or may not work.” But I thought there was a declaration that a 2.0 positively would not work with IE8. Maybe I got that wrong, but if you can clarify that, that’s great.

2.0 is targeting evergreen browsers. And from the perspective of IE, I think essentially that means, well, it does mean IE10, although we may be restricting to IE11. That’s still sort of to be determined as we flesh out some of the implementations. The reason isn’t because of the JavaScript language features or the code that's generated from the transpilers per say; it's really a matter of the runtime capabilities of the browsers; what features that DOM supports and what features do the JavaScript runtime supports. If that makes sense, right?

So that is what the restriction and why we are actually saying evergreen browsers are the target for this. So if you have to support IE8, you're not going to be using Angular 2.0. We have to make a hard line here in order to sort mover forward and do some of the re-architecturing that we want to do for these performance scenarios that I'm talking about, or for these usability scenarios. In order to make those work, we have to lever certain runtime capabilities of the DOM to make that happen, which just are not available on those browsers, and also sometimes not capable of being polyfilled -- or the polyfill is so atrocious, that you couldn’t use it.

Right. So if you wanted to, you could rely on ‘object.definedproperty’ being there and take advantage of that, and that’s simply not there in IE8 and earlier.

Right.

So if you guys are authoring everything ES6, you're telling developers, “Hey, it's a great way to author. You should be authoring your own code in ES6.” And whether that sort of 2.0 or not, that doesn’t really prevent you from doing ES6 today, and then being ready to do ES6 when Angular 2.0 comes out even though you can stick with ES5.

Correct. We think ES6 is an awesome option, and were kind of recommending and trying to help people go down that path, but it's completely up to you.

I have another question, but I do want to point out I just found out this morning that my PluralSight course on ES6 came out today, and there's a whole module about using ES6 today in code for browser that only ES5 browsers basically doing exactly what you guys are doing on the Angular 2.0 project. A little self-plug there. But I do wanna circle back around the major features of 2.0. You talked about modules and dynamic loading, but I’d like to get like a brief overview of all the other major features in Angular 2.0.

Sure. There's things that everybody will be familiar with. So dependency injection is a really important part of the current version of Angular. And there's a new implementation to that, which is much nicer. And so that will be kind of a foundational piece that the framework itself is built with. But you also leverage to build your own apps. There are things like directives. You're familiar with this from 1.3, but they are refined in a number of ways for 2.0. And the idea is to make them simpler to use.

Right now, learning how to author custom directives for example, is not a beginner level topic with Angular 1.0. However, wouldn’t it be nice if it could be a beginner level topic for Angular 2.0? So part of the redesign is again around thinking about how people use these features, how easy it is to learn. And so some of the features are the same features you already know, but they are attempts to reimagine them in some ways, that will improve our performance, but also improve the usability.

That’s music to my ears because directives today, I'll admit that I'm a directive lover and hater, because there’s days that I write them and I just find a… one of the more complicated things to write, none of them are minor directives, but you know, really powerful directives; they just don’t seem to flow as much as the rest of the Angular technology.

Right. And when you deal with directives, you have to think about compiling or linking and your observing attributes and sometimes you have to apply and blah, blah, blah. And it makes it really difficult to learn, and it's also kind of like very low-level things that you wish that you didn’t have to think about.

And testing directives is horrible too. It's horrible to test too.

They are tough to debug.

Yeah.

There is a reimagining of how you would build directives that is trying to leverage a more declarative approach in a number of ways. And so the result is that atleast in our current prototype, you don’t have to think about compile or link, again leveraging ES6, you basically write a class and you ask for things to be injected into the constructor from the dependency injection, and the templating engine will give you those things. And you declare properties and you decide which ones should be surfaced as attributes on elements. And data binding just works; you don’t have to worry about watching things because you can get call backs automatically for properties when they change -- these kinds of things.

This is also on design, so some of these things are subject to change, but the idea is can we reimagine how directives are built, in such a way that we can kind of take all that low level stuff you had to worry about in give you a little bit higher level declarative API that lets you do all the same things without worrying about those nasty GETs I guess. So the design on that I think is really nice. I like the way that it's looking, and I think that people will find it to be a much more pleasant experience for building those kinds of things. So again, it's a feature you have in 1.3. It's the same capabilities per se, maybe some new things like Shadow DOM support for example, but a lot of the focus around that is making it just better for developers; making it easier to use and giving us a different set of constraints in the covers as a result of some of those decisions too, which allow us to do different performance optimizations. So directives, dependency injection, data binding.

So Watch Tower is the name for the library that does dirty checking in the new version. And dirty checking is being overhauled completely with a lot of learning about performance improvements that have happened. And so again, dirty checking is probably going to be there, but the implementation is revamped to be more scalable and more performant, and to be aware of things like object observe if they are present, and has some new capabilities that it didn’t have before. That’s also in the works. That’s a pretty complex part of the library, and again some of that is all subject to change, but it's a feature that you know, but that will be just better, right?

So Rob, I'm looking at the Watch Tower GitHub repo, and I think I found the right one here. “This is an ES6 Port of Angular.dart change detection code,” it says.

Yeah, and that's old now. So there's actually another complete redesign. That was sort of an intermediary implementation if you will.

Okay.

So for people that don’t know, Google has Angular Dart. And Angular Dart is not a port of Angular 1.0 -- it is actually a complete rewrite as well in Dart. And as part of that rewrite, they solved some of the problems that we're also talking about right now. But 2.0 is another right to solve additional problems even beyond that.

So some of the learning from Angular Dart is coming into AngularJS 2.0, but there's also another kind of layer of learning that’s being put on top of that. So Angular Dart change detection is actually faster and better than what's in AngularJS right now, but the new one that we're working on will be better than that and will be able to handle some other scenarios. So again, it's a feature that you know, but it will be better.

So Rob, one of the opportunities when you are doing a rewrite is that you also get to throw things away. [Chuckles] For example, I've never appreciated the fact that we have both a factory and a service that cause tremendous confusion, those two terms for people.

I choose to ignore that the service exists.

Yeah, although we call the thing that we make with a factory a service, so that just adds a little spice to it. So my point being, it's an opportunity to throw some things or any things that you guys have slated to say, “Well, you don’t have to deal with that anymore. Goodbye to that.”

Right. So interestingly, speaking of factory and service, like there's no real distinction on that level right now on our current code; there's just dependency injection. You just get instances injected. You don’t have to declare things differently, right? You can sort of provide some metadata to indicate whether it's a singleton, or whether it's transient instance, you can supply functions that work as factories if you want to. I don’t think that will be the way most people write their code, but it's sort of a feature of the dependency injection framework that we have a much nicer way to handle the composition of objects now.

That sounds great, I mean, that’s constants values services and factories. I can kind of see that falling there, but what about the concepts of a provider today? How does that work?

It is. It's actually part of DI right now. And you can actually give a function which you annotate with a provide annotation, that tells you what kind of thing it provides, right?

Oh, sweet.

You can actually hand that to the dependency injection framework if you need to do that. And we do do that internally for in some of our implementations of different things. So yeah, that capability is there. Actually the new DI is really awesome; it has child container support as well, so you can override things in containers, and you can add new providers, and it understands singleton versus transient scope instances and does a lot of smart things like that. I don’t think the provider feature will be something that will be used probably as much in 2.0 in your application code, but it's there.

Why do you say that? That makes me wonder a lot of things. Why do you say that?

It also makes me wonder about the config phase, run phase, which confuses a lot of people too.

Tell me about what you use provider to do.

Okay, so a lot of times, we have services (factories) that we write today, and we want to configure them in some way before the run phase. So we’ve got this config run phase today. Is that the bigger question? Is that changing in Angular 2.0?

Right now, at least at the moment, there's no configure run phase. And you can handle configuration through dependency injection.

Sweet.

So there's still some talk about recommendations there versus whether we need to add some features or not, but at this point in time, there's no configure run phase.

I can tell you, that is a pain…

I know. It's very confusing.

But I've already figured it out, and that’s job security, right? [Laughter]

But that’s the great thing about this is not only is it an opportunity to bring new features to the front, but it's a chance to scrape off some of the barnacles like these, that just got people. And I find taking things away almost as interesting as what we're putting in. The whole idea that 2.0 is about making a developer feel that it's cleaner, easier to understand, easier to test, easier to bug, it just feels like a more friendly and intuitive environment. That is a design goal is I think it's important as gussing it up with new bells and whistles.

From what you are saying, it sounds like were trying to go from Angular today, it's kind of like a paved road on the highway. This is more like a jettison where we're gliding through. It's much smoother experience because not having config run and provider and service factory constant value, all these different…

Too many concepts. So they are trying to lower the concept… It really helps anyone that is coming to it for the first time or anyone that wants to move from their current Angular; there's less things that you have to know upfront; there's less terms… you need to understand dependency injection, but if you have an understanding of that, there's not a whole bunch of like special categories of how to deal with that. Directives will be simpler to use and right now, there’s three different types of directives in our current thinking; there's essentially ‘component directives’ which are elements; there are ‘decorator directives’ which are like these attributes that you put on things to decorate an element with additional behavior; and then there's ‘templates’ which is like ng-if, ng-repeat that actually conditionally display fragments of DOM.

Because we actually have these categories of directives, you then build your directive as one of those three types, and it makes the directive building process much simpler. And also gives us more information in the core of the framework, because we understand more about what your directive is trying to do, because kind of what category it fits in. So we can do optimizations, we can do smarter things in terms of helping you not make mistakes. We can understand more things. So like you said, it sort of like if you wanna call it the jettisons road, everything that we liked better and trying to think about the things that are really confusing or really problematic or maybe are just not necessary kind of in this new version and kind of stripping them away.

Now I've heard that the templaters are is called ‘formatters’. Is that the official name?

Not in terms of our last meeting, but… [Laughter]

I do wish that life work like this. I mean, I would really like to provide a service that provides a clue, and then dependency injected into our government, but that’s like impossible, so. Anyway, I do wanna ask a little bit about the router. It seems like there's been discussion about… in every framework that has one, there's discussion about the router, and you're the person that's working on that, aren’t you?

Yeah, I've done most of the work on that. I'm working with Brian Ford, and he did a ton of research and working with the community and then I've written a number of routers in the past for Durandal and so we brought every…

So what are the changes?

The new router is a complete rewrite, but it's going to leverage a number of the capabilities of the core framework now. So as I talked about Angular 2.0, big scenario is dynamic loading. So now that we have that in the core, the router can talk to the templating engine, it can talk to the loader, and now we can dynamically load any route in the fly if we want to. It can be there already, or we can dynamically load it. So this is like a really big improvement. Something that was very difficult to do with the current Angular router.

But that's just sort of the very beginning. So we also have a nice new feature which I refer to as a ‘screen activator.’ And this is how we deal with separating the “how to change the view” from the “can we change the view?” So when you're navigating from customer one, customer two, and you’ve edited some data on customer one but haven’t saved it, usually, when somebody tried to go over to customer two, you don’t wanna use all the work that you’ve just done, right? So we like to be able to in the middle of that navigation process, kind of have the opportunity to ask questions of the developer to find out whether the navigation that’s being requested is allowed or whether we need to do something before we do that, and so on and so forth.

So we call this screen activator pattern. And this is now built in to the router, so for every controller essentially that you route to, you have the ability to know when the router has activated it, or when the router has deactivated it. In other words, when it's coming to that control or when it's going away from it, but more importantly for this use cases, you also have the ability to have a callback that indicates whether you can navigate to it, or whether you can navigate away from it. And all of these callbacks which return Promises, so they can do asynchronous things; you could talk to the server and ask the server information or you can…

Rob, this sounds a lot like the Durandal router and its interface.

Yeah, so this was like a really powerful feature of Durandal’s router that was reimagined for Angular 2.0. So you have just a number of callbacks you can now add to your controller in this world where you can completely stop navigation or you can do something asynchronous in the middle of navigation; you can stop navigation to the new screen, you can stop navigation away from the old screen. And it's all encapsulated, so you don’t have to have a global event somewhere where you just cram a whole bunch of conditional logic to make this stuff work. Each screen can encapsulate its own logic about activation. And that goes along the theme of modularization, and it makes things really simple and the router just understands these.

Now what makes this even cooler is that the new router has this notion of sub apps or child routers, which means that you don’t have to just a single router instance for your entire application. In fact, you can even have a router per component. And this allows you for large teams, for large projects work to… so for example, imagine an app that has multiple different features, and each one is complicated and each has its own set of routes. You can take and put a different team to one of those, right? In order to be more efficient. And each team can have a complete control over their own router instance deciding internally what the set of routes makes sense for their feature. And that is what we call a ‘child router.’

So it almost like you’ve got a miniature app that's completely standalone, that has its own router, its own routes, its own components, and then you can plug those into your larger Angular app, and there will be kind of an app level router that decides the base paths for each of those components. None of your child routers need to know, at the time of development, where they are living inside of this hierarchy of this URL structure, if you will. And so it lets you basically now build Angular apps that are composites of apps. And it can even be composites of apps of composites of apps of composites of apps, because you are not restricted to two levels of these routers; you can have any levels of child routers.

And this new router sounds kind of like what the UI router has today. Is that where that kind of came from?

So Durandal had a little bit of this. UI router had a little bit of this. So I think it's kind of an evolution of that concept. And you don’t have to do anything to have a child router, you just ask the dependency injection framework to inject the child router, and then you just configure it the same as any other router. There's nothing special about it from your perspective; it just so happens that runtime, when it's plugged in to the app, all your routes might actually be relative. And of course, we know everything that’s going on, so when we generate URLs, we automatically can generate the correct URL based off where things are in the hierarchy.

The screen activator patterns that I talked about, this is where they get really, really cool because we understand the complete state of your app at runtime, and when you try and navigate from one route to another, we understand the diff of the states that’s about to happen. And we know what levels of that heirarchly that we need to query to ask whether this transition is possible. It also lets just do a lot of caching and not transforming the UI between state changes that don’t affect certain parts of the UI.

So you can imagine that you might have an app that has an app level router. And one of your feature areas is just like your general settings area, right? And settings has a number of screens in it, right? So you’ve got your social networking settings, you’ve got your account settings, you got your user settings, you’ve got your theme settings. Each one of those, you wanna be able to build out in a modular fashion is some controller and view. And you want the settings area of your app to have its own router so that it can decide what the routes are to those different screens internally. But that lives inside of the larger app which has this app level router that says, “All those features are actually living at settings. I don’t care what the routes are internally. That router is in charge of that, but that piece is mounted at the settings relative URL.” So the settings become almost like an app onto itself completely encapsulated and it just drops into the larger app.

Now when you are navigating say from like customer detail one to settings social networking Facebook, we know exactly which routers and which part of that router changing, and so we know who to query whether we can make that change possible. If you're inside of settings and you just go from sort of like the social networking tab to the account tab, we don’t have to change out the larger settings piece because that isn’t changing; only what's changing is the inner screen that move from the social networking tab for example to the account tab.

So we understand the current state of all the routers across the entire app at runtime, and so we don’t have to change anything that isn’t actually changing. And so the developers code isn’t invoked; there's no UI that’s being recreated, there's no data binding changes. We only changed the minimal diff between those two things, essentially. And we only query the developer about the things that are actually changing. So the screen activator pattern works together across this hierarchy of routers now. And the hierarchy of routers allows you to further encapsulate your app as a set of feature areas or a set of child apps.

And this is actually common on a server side, if you are looking at some of the more modern NodeJS web frameworks. There’s this ability to sort of create like little child apps, or little sub apps and then sort of mount them via middleware or what not, into kind of the place that you want to mount them. So we have this full capability on the client side now, and it's integrated with the screen activators.

And not only can we have child routers, we also have parallel routes as well, so you can have a single route that maps the multiple controllers. And those different controllers will be put side by side in the area of the views that you say. And we understand the divs there, so if you navigate to a

different route, but if that route actually has one of the same controllers in common, then we know to only change one. So a lot of things about how you can componentize your app now from the perspective of the router. So it's really powerful.

How does that compare to the Angular UI router?

It's similar in a number of ways in terms of having child routers. I think that the screen activator pattern that we have in this new router is more flexible. I think it's a little bit more elegant that's personal opinion. Obviously, I've designed it, so I'm biased. It does come from a lot of work on these kinds of patterns that I've done over the years across the multiple frameworks, because this is a problem that arises in client side of development in general. And I've worked with this a lot of and kind of evolved my approach to it quite a bit, so this new version kind of has my latest thinking. So it's really smart about how it does these screen activations in these hierarchies and in these parallel structures. But conceptually, it's similar to some of the things that UI router does. I think our API is a little bit cleaner.

What about convention over configuration? That’s one of the things that isn’t in Angular philosophy today. And it really comes in the router where you keep saying the same things over, and over again that could be inferred. Are you doing anything about that?

When current implementation of the router, I've actually abstracted the notion of configuring the router from the router itself. And our default configuration is a low-level configuration, but it does have a number of conventions so that you don’t have to type the same thing, essentially. You know like, if you wanna route that’s foo and it needs to navigate to component foo, which a view foo, you don’t have to say that three times, right? You just say my route is ‘foo’ and it will infer the rest. And so there are some basic conventions like that. You can write your own conventions, because like I said, the configuration model is separate from the router, so you can create your own class with its own set of conventions and its own API for configuring the router. And it just needs to be able to export a simple JSON data structure into the router itself that will configure the actual router.

So there's a design choice there, that allows for the community or for individual projects to build their own conventions, and even decide how they want to configure the router, independent of the router’s actual workings. But our default implementation does have some conventions and we’re still kind of thinking through whether we could do more or better conventions. So those aren’t nailed down yet, but there are some basic, what I would call, pretty sensible conventions built in with that.

And in general, we're trying -- at least I'm fighting -- to try and have that approach trickle more into Angular itself. I think that that aligns a lot with the usability perspective of not having… you don’t wanna type things that, I call it I don’t wanna type dumb stuff. Sometimes you're working with the framework and you think, “Shouldn’t the framework know this? Why do I have to type the same thing in three different casings and three different places? Cant it infer from this name over here that this other thing is this?” So trying to bring those ideas and a lot more. I've done a lot of that stuff in my work in the past, so I'm trying to move those into Angular. And the current router implementation has some of that already.

What else can I say about the router? Did I mention that it's being back ported to Angular 1.3? Did we mention that yet?

Yay!

Awesome.

ROB: yeah, so Brian Ford is doing some work on that, and it will be a future equivalent implementation. Right now, we're working out the details of how we can have a single source code base that works against 2-3 different versions of Angular. And so we've done some abstraction work in the router itself now, to abstract the way that the DI and the templating engine so that the new router is actually a little bit more framework agnostic.

So not saying it will work with any framework, right? I'm not saying you can just go out and take Ember and like use our new router with it, but for our purposes across multiple versions of Angular we’re working to have a couple of nice little abstractions in there, so that we can basically use the same code, minus these plugin points for both versions.

And I'm also working on a new version of Durandal as well built on top of Angular, to be determined what that will actually look like, but my hope is that it uses the exact same router as well. So I think it will be cool to have the same router across two or three different frameworks, and then we can just sort of evolve that core router overtime, making it better and better, and everybody kind of gets the benefits from that.

So we’ve got a ton of features in the new router. I think that the sub apps idea of the child router, the dynamic loading, the screen activators, all those things are really big, nice improvements. That the way we understand state and state changes and how we are going to be able to do URL generation better and all these kind of things, everybody gets across all of those libraries. And then there's a bunch of stuff we wanna do in the future.

I should mention another really core idea of the router, which is internally, the entire router is implemented as an asynchronous pipeline. So in a lot of ways, it's actually designed like some server side routers, where when you request a navigation, what happens is we actually knew a pipeline that has a series of steps in it. And each one of these steps works like a decorator, so it can continue to the next step, or it can wrap the next step, come after the next step before it. And it's all Promise-based, so what you essentially have is a pipeline of steps, each steps being asynchronous.

And the pipeline is designed to be pluggable; our entire screen activation logic that I told you about is actually implemented as a set of four different steps plugged in to the pipelines. So if you don’t like the screen activator pattern, you can pull all those steps out and you can put your own in. I suspect people will leave that as it is, but a couple of compelling news cases are authentication and authorization. So you can write a custom step, and push it in to the beginning of the pipeline, and then have a default set of behaviors for authentication and authorization, that will run as part of every navigation.

And this is a really simple, elegant way to handle that problem, because you can say for example, “Is the user logged in? This can be you first step. Is the user logged in? No. Well, redirect.” Because from the inside of these steps, not only are they asynchronous, but it can also redirect from inside of these steps as well. So solving the problem of authentication, and a problem authorization on individual routes, it's just a matter of writing a step and pushing into the pipeline.

And again, it's an asynchronous pipeline. And so if you need to see… so, say a user is trying to access customer one edit, you can call back to the server in the middle of navigation, load the data, and ask the server whether this user has access to edit this piece of data all as a step sort of in the middle of the pipeline. And then you can extract all that code out of all your controllers. And it can just be handled as part of the navigation process. And you can decide, if somebody is not authorized for example, whether you wanna redirect them, or whether you just wanna cancel a navigation or whatever behavior you want for your app.

And so because the entire router is built on top of this asynchronous pipeline model, you can pull things out, you can put new steps in, you can do all kinds of crazy things -- authorization, authentication, automatic loading of data. If your routes fall in a certain pattern where they have say like the entity name in the route and then the ID, well you can write a step and plug that in. And you can automatically asynchronously load data as part of the navigation process, and then push the final object instance that’s loaded into the parameters that will be injected into your actual controllers. So you can even remove all loading of data out of your controllers. If your app is built according to some set of patterns that you can ride a step in the pipeline to process.

So this is super powerful. Like I said, pretty much the entire logic of the router is built as a series of steps in our default pipeline for the router. So you can plug into this as well and just do crazy stuff. I think there's a lot of really practical things you can do to componetize your code and to remove stuff out of your controllers to make your controllers simpler and smaller. Yeah, I'm really excited about that.

I hate to interrupt, but we are kind of at the end of our time, so I just wanna thank you for coming on and sharing all of these with us. My one last question is, is Angular 2.0 something that we can go play with right now?

It's not. And I don’t have timelines, but our first milestone that we're really working hard for is to get something that we can basically say to the community, “Well, it's not ready yet, but we want you to play around with this. We want you to give us feedback.” We've done a lot of design, a lot of prototyping. Some pieces are really quite stable and mature; other pieces need more work, so we're not quite ready to do that just yet. But kind of keep an eye on things because we're working really hard, and I think it won’t be probably too long before there will be something that you can at least play around with. That’s the hope.

Cool. Well, let’s go ahead and get to the picks really quick then. Joe, do you wanna start us with picks?

You bet. All right, so for my pick this week, I'm actually going to pick John Papa’s course, Angular Patterns Clean Code. It should be out by the time this gets published, but it's based on the work that John has done about kind of a way to write good, quality, clean Angular code. And I'm a huge fan of the work that he's done on that, so I'm really excited to see this course and have a whole course about clean code patterns for Angular. And we're still doing the Angular tip of the day, right?

Sure.

Awesome. My tip is going to be since we talked about dynamic loading in Angular and how that's going to be available in 2.0, my tip is a product that let you do dynamic loading in Angular 1.2 and that is is Overmind by Dave Geddis. It's application or kind of an add in that he wrote that lets you do truly dynamic loading with Angular 1.2. And if you have a really big app, you can just load pieces of it when you need to, end it will unload pieces of it. And it's just really amazing product for medium to large size Angular applications so that you get actually truly dynamic loading of code, and works with RequireJS as well.

And I'm going to do like a second pick, even though we're supposed to keep our picks short because ng-conf just announced that we are having ng-conf 2015. We've announced the dates, and we announced the fact that there will be more announcements, but it's going to be in Salt Lake City again. The dates are in March 5th and 6th. It's going to be very much similar to what we did last year. And lots more information coming, especially the call for papers is going to be announced very soon, so keep your eyes on the website www.ng-conf.org.

And people should really pay attention to that, right? Like didn’t it sell in like 10 seconds the last time?

Yes. 10 seconds was the cumulative between all the tickets that will be sold. 700 tickets all sold out. So yeah, if you wanna go, you'd better be ready. It's time to start getting budget approval for those tickets.

All right. John, what are your picks?

I'm going to pick one of Joe’s courses, oddly. So recently, I got a chance to look through Joe’s and K. Scott Allen’s course on ES6 at PluralSight. And it's really, really good. I learned a couple of things in there as well. And they’ve got a whole chapter module section on Traceur, and things like that you can use to actually using that stuff today, which is wicked cool. So while I'm not doing a lot of ES6 in my daily life, I play with it quite a bit on the side, and I found it very, very which is awesome. So definitely check that course out. And that one is available today.

And as far as the tip goes, one that’s helping out just like night which I’d like to share with folks if I haven’t already is ng-inspector. It's a chrome plugin, and it's kind of like Batarang, but slimed down. And really, all it does is it shows you a preview of all of the bindings and scopes on your page, so you can basically inspect anything you’ve got in Angular. And it's really helpful for when you are trying to debug you know, what’s going on in this scope and what is it bound to. It was extremely helpful last night for me when I was going through a series of nested directives.

Cool. We'll give Ward a chance to share some picks.

I recently, under John Papa’s tutelage have been encountering gulp, and I'm not going back to grunt again. I really like programmatically controlling my build process. I’ve found it remarkably easy to move forward. And so, I think John, you are putting together a course on gulp and I'm looking forward to seeing it when it comes out.

Yup. Just signed the contract.

Cool. My pick is Boomerang, and it's a plugin for Gmail. I am totally addicted to Gmail now for my emailing, but I've never been super good about following up with people, which kind of is a big deal when you are a freelancer. What Boomerang does is it allows me to schedule things to come back to my inbox. And there are a few other websites do it, where you basically see them or you forward the email to them with a particular timeframe on it. In this case, it's just right there in the email form, so I just check a box that says, “Boomerang this.” I tell it when, and I tell it under what circumstances. So if they replied, then it won’t boomerang it. But if they don’t reply, it will. Or I can say do it regardless, and then it comes back to my inbox.

Dude, that’s what you picked on the Jabber.

I know. [Chuckles] I love it. I'm sharing. Anyway, so my tip is if you have to make a request where you have credentials that need to be shared with your API server, by default, the HTTP provider in Angular will not send that information over. And so what you have to do is you have to set the defaults with credentials. And I'll put that into the show notes so that you can see it. “$http.defaults.withCredentials = true”. But then the other trick you have to do is you have to send the Access-Control-Allow-Credentials on your API on the backend. You set that to true. And then the last trick that I had to pull was if you do that, then you have to specify the Access-ControlAllow-Origin.

Anyway, you have to set that to whatever the domain it is being sent. So there's a little bit of play with that. My code is actually up on adventures in Angular forum, so if you wanna go and get into the forum, you can do that by going to adventuresinangular.com/forum and then you can see what I'm talking about. But basically, yeah, you have to set these two headers properly. You can’t use a star on the allow origin anymore if you send credentials and then yeah, you just set that on the service provider for http and it works just fine. Anyway, that's my tip. Brian, do you have a pick and a tip for us?

I do. I have this blog post about Regex Golf by Peter Norvig. And it has nothing to do with Angular, but it's really fun. It's kind of this iterative, like how do you write this crazy thing that generates regexes and satisfies these different constraints. And he goes through a couple different strategies and it's based on an XKCD comment, which is a bonus.

A tip, one thing that lately I really like is if you are using Sublime Text, CTRL+M if you are one brace, will take you to the matching brace. So like CTRL+M for matching. And this saves me a lot of time in like trying to collapse down code blocks or like refactoring. That’s my pick.

Cool. Rob, what are your picks?

I got two fun thematically related ones. First is Dungeons & Dragons 5th Edition. I'm a big Tabletop RPG fan. And just in August, Wizards released the newest version of the game, and it's quite welldone, so I'm very excited about that. And another one that’s dungeon related is a fun little game called Dungeon Roll, which is a dice-based game for 1-4 players that simulates going into dungeons and fighting monsters. And it's just fun. Everyone I've played it with has enjoyed it. It's really easy to learn. It's a small little box. You can take it around. Travel with it. Just a short, 10-15 minute game. So I think that’s fun.

And then my Angular tip would be that everyone should check out Angular Material Design. It's another project I started working on with a bunch of really sharp guys, taking the material paper UX ideas that Google is working on, and implementing them in terms of Angular or 1.3 directives. So it's a great set of components that you could use in apps. We're still not in a 1.0 release, but it's worth checking out. It's also a great learning opportunity I think for anyone that wants to see how a wide variety of advanced directives are built and tested, and distributed and all these kinds of things. And so it's just another really good source code repositories to learn from. That’s it.

All right. Well, thanks again for coming, Rob. It was a terrific discussion. We went a little bit long, but I think it was really good.

You're welcome. Hopefully my random stream of consciousness will make sense to your listeners. [Chuckles]

I think it would be really helpful. Thank you all for coming. We'll catch you all next week!