Check out Freelance Remote Conf! And while you’re there take a look at all of this year’s conferences!

 

02:42 - Angular 2 Beta and Projected Release Talk

06:52 - Payload Size

07:56 - Preparing For Angular 2

13:31 - Application Capability

17:06 - Language

17:33 - Releasing Angular 1 vs 2

27:10 - angular-cli 

28:31 - The Designer Story

34:57 - Promises and Observables

40:55 - The Router

48:43 - Angular 2 Myths: Busted

53:22 - React, React Native

55:37 - Angular Guidance; OO-Style or Functional App Architecture?

01:01:19 - Angular 1 => 2 Migration

01:04:17 - The Angular Community and Upcoming Conferences and Announcements

Picks

a2-in-memory-web-api (John)
John Papa’s Upcoming Angular 2 Pluralsight Course (John)
Julia Gillard (Ward)
Bryce Canyon National Park (Joe)
Stockpile (Joe)
ngrx (Lukas)
The Revenant (Brian)
ServiceWorker: Revolution of the Web Platform (Brian)
The Architecture of Open Source Applications (Igor)
iPad Pro (Igor)
Apple Pencil (Igor)
Paper & Pencil by FiftyThree (Igor)
Mandy Moore (Chuck)
Federico Iachetti (Chuck)

Special Guests: Brad Green, Igor Minar, and Miško Hevery.

 

Hey everybody and welcome to episode 78 of the Adventures in Angular Show. This week on our panel we have Ward Bell.

Hello.

John Papa.

Hey everyone.

Joe Eames.

Hey everybody.

Lukas Reubbelke.

Hello!

I’m Charles Max Wood from Devchat.tv. Quick shout-out; if you’re interested in freelancing, that’s the next conference I have coming up in February. Get your tickets now so you can get the [inaudible] pricing.

We also have three special guests; we have Igor Minar.

Hi there.

Miško Hevery.

Hello.

And Brad Green.

Hey yah.

I think we all know who you are so we’ll skip the introductions, but for those who don’t know, they are basically the guys that are running the Angular core team and created Angular for us so we’re really grateful.

There’s been some big news since we had you on last. Do you want to talk really quick about the beta and some of the other things you’ve got going on?

Yeah. I don’t remember when we were on last, but on December 15th we [inaudible] beta; I think a lot of them have heard about it. We were really intending this to be the signal for folks to start developments because our criteria was that we had stabilized the APIs and then we actually tried it out on a bunch of [inaudible] Google [inaudible] that we’ve launched. Some will be launching more soon so we got good confidence that the people can actually be successful developing on it. [Crosstalk]

I want to clarify something; when you say ‘developing on it’, does that mean experimenting with it or using it in production?

It depends on who you are. There’s some things that might prevent you from going live. So if you're an Angular 1 shop and you want to do the upgrade path and include Angular 2 with it, the download size of both of those might be too big. We’ve been working on total download size as one of our key initiatives and we’ll solve that soon. But as far as APIs and building Angular to be or pilot performance, that’s ready to go.

So when you say ready to go and yet – this always brings up the question and you must address it, what can you say about projected release, and if you can’t say what day it is, how would you tell people who have to make business decisions how they should think about their choices?

Our goal is that [inaudible] to ship Angular in 2016 and we keep on [crosstalk].

Don’t ever sell it, man. [Chuckles]

Our goal is possibly potentially to [crosstalk].

No, it’s going to happen this year. Hopefully sooner than you were expecting. We don’t want to disappoint because in the past, we had an experience with setting deadlines and just making it impossible for us to reach these deadlines and then – which is a bunch many people. So we’re going to ship it when it’s ready and it’s going to be sooner than most people expected.

I don’t want to put any pressure on you guys, Igor, but we on the podcast team had a pool going that we announced on our last episode and we have money laying on when the ship date will be. [Chuckles]

Do we have money laying on this? We never – I didn’t even know we discussed money.

I borrowed your credit card, Joe but [crosstalk].

Okay.

Yeah. So you're being very vague [laughter]. I’m just wondering because there’s this conference coming up in, say, May and I was kind of hoping to see something a little beyond the release candidate by then.

Well, let me just say some of the things we must do. This has been our strategy forever; we’re really clear about what does it mean for us to be final? There was a couple – five things that we enumerated in our blog post when we went beta. One of them is we need to be smaller. We’ve got a goal this year to be dramatically smaller, even smaller than Angular 1.

But for Angular 2, we want to reach basically the size of Angular 1 so that you can have a similar download experience [inaudible].

The second bit – the new routers is working for folks. The APIs work. We would like to be more ergonomic and we’re looking at some better APIs around that.

There’s a couple of things that we want to finish in the developer guides. We want to make the ES 5 documents and Ward’s working on this with us to make sure people are able to be successful through the dev [inaudible] on those things.

Get going, Ward. [Laughter]

Well.

You’re holding up the release.

Yeah. I’m all that stands between Angular 2 and release. I’m the block. [Chuckles]

Couple other things, when I was [crosstalk]. Oh, animations and [inaudible], yeah. And they were good. We’re making great progress in a lot of those things; mobile apps and some updates in a month or two on all that stuff.

So I’m just looking at your blog post and just to iterate there. It says “Reducing Angular 2’s payload, making the Angular CLI, doing the component router a little more justice and animations and then localizations on itnet.

Yup. Cool. No giant big things. We know how to do all these things. Just executing [inaudible].

Now, I saw some – I don’t know if it was a blog post or a comment or something like that about – because somebody wrote some article, it was React versus Angular 2. One of the things they talked about was payload size. There’s a whole bunch of people planning out, “Hey, the payload for Angular 2 has not been adjusted yet. They’re still in a very early beta type payload, not a late beta type payload size.”

Later on, I think it was in that same conversation, or maybe it was later, just something else was a tweet somebody had said. But I heard the quote about a Hello World app and there was a really tiny payload size for the Angular library in that.

You guys heard that payload size that [crosstalk] discussed?

No. We were the source of that rumor. I think it would be better for us to talk about the things we’re doing to reduce the size.

Yes, we want to be very small [inaudible]. Our end goal by the end of the year is that you should really not pay for much of a library at all. It will be generating code at just what you need for the use cases that needs scrubbing a bit. Igor, you can talk more about specifically what we’re doing. [Crosstalk]

Before you do that, I just want to stop and say I think it’s interesting; we start talking about the beta and immediately, we go to ‘when’s it going to be final?’ And nobody actually went ‘yay, beta!’ [Laughter] So yay beta! None of the rest of these guys will be satisfied with anything less.

I actually think that’s a good point, Chuck, because one of the things I keep coming back to is the person who has to make the decision today. And okay, that’s great that there’s an end goal at the end of the year, but if you're saying this is the signal to start development, what should I be looking forward to in a progression of betas? What is my risk? I know there’s got to be some risk of breaking changes, but how do I manage that risk? What’s your advice to somebody who’s looking at the project, perhaps they’re facing down on others who say, “Yeah, let’s skip this Angular then go to some other framework.”

How do you give somebody who have to make a business decision confidence about how to look forward to 2016?

With beta, one of the things beta means to us is we really want to start supporting people developing with Angular. For that – for us, that means no breaking changes without notification or deprecation strategy, having clear migration instructions. But really, if you look at the list of things that we still need to do for final, there is nothing major there. If we make changes to the APIs, it’s going to be minor stuff. We tried really hard actually to make all the major breaking changes before we [inaudible] up so that after beta, we had just have to do polish and just minor auxiliary changes to the APIs but not changes to the core APIs and I think that’s very important for developers.

So for us, beta release – we are shooting up [inaudible] Google to production with Angular. We actually – every time we make a breaking change, we need to figure it out how to upgrade all of these applications. Because of Google, there’s only one version of Angular 2 that everybody uses, and there’s several hundred developers already using Angular 2.

We’re not thinking of it lightly; we’re thinking about developers building our beta and thinking really hard about every change that we need to make. If we really need to make it, how to make it easy for developers to get over the breaking changes.

We actually have some really good plans about how to automate this whole process so that it becomes a non-issue or something non-controversial and not – something that wouldn’t stop developers about – and start making them worry about ‘how am I going to deal with this breaking change?’

It’s important to realize that things evolve. If you look at the web, the only thing that is still happening is that the web is evolving. We’ve met all the libraries and frameworks evolving themselves. It would be foolish from us to think that once we stamp Angular 2.0, that it’s going to be final and that’s how we’re going to change it all.

So a much better strategy is to prepare for how to deal with the evolution of the framework moving forward. Can we do a better job than what we did with Angular 1, going from Angular 1 to Angular 2?

So if somebody asks you today – because I know you’ve got those question, Brad. I saw it on Twitter the other day. I think you answered. If somebody asks you today this question of one or two forms – I’m starting a project now, should I be using Angular 2? And the second question I’ve see is I’m starting a project now that’s delivering in March, April, May, June, July – pick a month – should I be using Angular 2? How do you answer those things right now? [Crosstalk]

Starting with projects – this is a fine category for Angular 2. Now whereas before beta, we said no; we should only be doing it with Angular 1. Greenfield projects though are great candidates for Angular 2. The question would then be about shipping. When should I ship it? I think it’s only related to the download payload size. If this works for your app, then you’re great to go; if not, then make your way to a [inaudible] installer.

You keep [crosstalk].

Yeah, because I’m running an app right now and it’s a very simple app but I see Angular 2 dev in the browser. It’s not bundled, it’s not nothing. It’s one meg and this is always the early beta. It’s very raw, etc. now. But I imagine that’s not the stage I’m going to be in, just putting it out there. You're not going to be shipping a one meg file, right?

No. Let’s go back to the bill that says that thing that’s very important. If you look at the Angular today, the Hello World application is about 160K or 150 kilobytes of [inaudible] and that’s basically our baseline. That’s what we are. We know that this is really bad. If you look at the same application with Angular 1, it’s going to be something like 52K if I’m not mistaken. Basically, our goal is by the end of the first quarter, we hit the 50K mark.

That’s [inaudible] 25, right?

That’s [inaudible] 25. Yes, gotcha. [Inaudible] 25; we’re around 50K. We think we can do that by the end of March. That would be good enough for us to say now Angular 2 is production-ready. But we have a goal that goes past the 2.0 mark and that’s the unit goal. By the end of the year, we would like to get down to 10K in two months.

This is a stretch goal. We’re not even sure if this is possible. It’s a little bit crazy but I think we have some evidence that shows that if we think out of the box and think about things in a very different way than what we had – how we’re used to think about download size and sample of the application, we can actually reach the 10 kilobyte goal.

Cool. Thank you.

I’d like to look at the other dimension. A lot of business people don’t care about Hello World. They want to build an app and you guys have been using Angular 2 for some time now internally to build Google apps. So I think one of the other business preferences is A, too capable of supporting a large, serious application with it as real demands.

What can you tell us about the kinds of applications that you’re intimately familiar with that are using A2 today?

There’s two really big apps that we’d really like you to work with. One is Google’s internal [inaudible] application that are – 10,000+ sales folks use every day. It’s called Green Tea. You can’t see the app externally but there’s about a hundred developers on the projects and it’s got 500 components written on Angular 2. It’s zippy and nice and we’re really happy to have them giving us feedback. They were the first and earliest adopters. So we’ve been designing Angular 2 and the APIs to work at the scale for a long time.

Out other extremely [inaudible] price that [inaudible] yes is this other thing that Google makes money out called AdWords. AdWords is writing their entire UI on Angular 2 now. They have come a long way; it’s not shipped but not too far away. They have hundreds of developers using Angular 2. This is another step function in terms of the size of Angular where all that nice cases for really big apps that are using size and [inaudible] work, they’ve got some really impressive [inaudible] goals. So things like link stuff like lazy loading and optimizing all the different components, making sure that every part of every page has done and perform well. So we have that experience there. So we we’re pretty confident this can work really well in big enterprise applications.

Can you comment a little bit about what it’s like to coordinate a hundred developers around Angular 2? Have you learned anything besides from it’s always hard to coordinate a hundred developer? Anything [laughter] that people can take away from trying to work with Angular 2 and that kind of team scale?

A couple of things maybe. One is that – actually lazy loading is really your friend here because if you can compartmentalize your app into separate tabs, then an individual development section can only load the part of their app they care about. This is great for running your test and great for mapping your dependencies. How much do I have to conceptualize in the whole project?

Another was around migration because these guys on [inaudible] they started on the previous version of Angular; now they moved to Angular 2. One of the big realizations after trying to do it a couple of ways, you got to migrate the services first. Otherwise, you’re trying to build things you’re [inaudible] needs without the base being there.

I’m sorry Brad; you mean the backend service – web services?

The service layer in the browser. Because it was an existing app, all of the server side APIs already existed; we just didn’t have the business logic in services to deepen the Angular 2 style to some more [inaudible].

Yeah, [crosstalk].

It kind of leaked into the controllers and now you’re trying to have a clear separation between business functionality and the components?

Yes. Just make sure you’ve got service written first for any kind of migration and then build the component based on [inaudible].

What language are you guys – are your teams writing in it?

The [inaudible] is writing in Darts which is as popular here; it’s like Google. I think for external folks, it looks very close to TypeScript and the APIs on Angular’s actually the same so I didn’t expect you to have a different experience.

We’re also starting [inaudible] with TypeScript care of Google under the first teams I’m just being offered into so to speak.

So when you guys are building these apps as these other teams are building them, I imagined releasing Angular 2 is different in releasing Angular 1, right? When you guys at Angular 1, you didn’t have this history of massive experience and millions of people using it already. When have you run along the ways you're putting out Angular 2 [crosstalk] that’s changed?

Oh, which blog story? We’ve got lots of blog stories, right? [Chuckles]

It’s different now. Right now, you’ve expended that bars really high. So what did you have to deal with as far what’s been challenging there?

Well, we had a funny little [inaudible] where we took down a lot of Google developments once because a lot of people have caught on Angular. I don’t see that [inaudible] difference on Angular 2 because when we started, we were nothing. Nobody cared about what we did and now everybody cares. I remember [inaudible] and Miško laments those days when I could just make changes freely and the migration was nothing and updates was nothing and we didn’t have opinions. People didn’t have opinions. [Chuckles] It’s far better now, honestly. The end result’s way better without having all these other input sources.

Yeah, back in the days, it was just me and Miško waiting in a bus stop. [Chuckles] Some fantasies is just really interesting. These days, it’s – we get so many opinions and we’re just flooded with opinions. One learning from Angular 2 is do not start a discussion unless you have an opinion already because you’re just going to be flooded with lots of opinions. It’s much better to propose something and then have people give their pre-[inaudible] proposals or tweak the original proposal then start Greenfield because it’s impossible to do Greenfield brainstorming at that scale. I think that’s the biggest learning that I have.

My learning is that people have opinions about syntax but nobody cares about semantics. The reality with semantics is that they get what matters with syntaxes, something [inaudible] how hard it is.

On an exact note, I was just listening to [inaudible] the other day who was saying,” I chose –“ I don’t know if it was Aurelia or React, whatever it was, “because I looked at Angular 2 and I liked it but I couldn’t handle the syntax.” And I was like, “Really, that’s the reason you turned away?” I hear that man.

I think it’s inevitable. It’s your initial gut reaction that tells you something about it. Whether or not you’ll be successful or not at it, I think you do have to think deeply about what is the actual end result in which language goes – lacks semantics over syntax.

And that’s the littlest syntax. We just got a lot of [inaudible] about syntax, making sure that makes sense and people have set the least number of people but it’s not the whole story, right?

Actually, one cool thing about Angular 2 which we can talk about is that the way we build Angular, syntax really doesn’t matter that much, what matters is the semantics. With Angular 2, you want your custom tablet syntax, you can actually build it. It’s not too difficult to take a piece of Angular and replace it with your custom piece and also [inaudible]. You now have your custom syntax.

The only thing that matters to us is that syntax is semantically compatible with Angular which is not that difficult. If you look at many of the tough looking [inaudible] out there, they’ve been so compatible.

That’s really good to know because I wanted to get started on the wild cats’ template syntax. [Laughter]

Probably after you [inaudible] these. [Laughter]

That’s how he’s going to write the docs.

That’s how we’re going to write it. Wild cats.

One of the things that many of us have found when we go out and talk to folks is we really want to get them excited about talking about Angular 2, but we stumble at the door with the tooling that’s in front of it. What can we expect to have happened there? Some of it might just be education because everybody stumbles trying to figure out how they use these loaders and stuff like that.

How do you guys see? What’s the future look like?

Yeah. So this is definitely a problem that we are looking at and working hard on solving. To understand what’s actually happening is there is this fundamental chute in the webpack I want to be happening. Because there are several new APIs and specifications being implemented by [inaudible]. There is the ECMAScript 6 with lots of new syntax that is new to developers. We have new module system; we’re introducing TypeScript which we hope that eventually will actually become more than just an open source project. Hoping that it’s going to become part of the ECMAScript standard in some way or shape.

So there are many things that are happening in developers; we need to absorb all these changes at once and that can be a little overwhelming.

There’s a lot of [inaudible] to say, a lot of tools to configure to get all these things running working together, right?

Right. There are a lot of tools that we need to use because most of the browsers didn’t actually support all these application APIs that we need. So we’re using transpilers to write the code in the new way but still run it on browsers that we got today which requires extra tooling, extra configuration [crosstalk].

And build systems. Sometimes systems [crosstalk].

It’s pretty complex so here’s what we’re doing. We’re working with different partners to simplify the auto machine. The best sample in TypeScript team which we work very closely with. And we’re simplifying everything so that if you're using NPM, if you're using Angular, there’s very little configuration to be out-of-the-box to use TypeScript to transpile either your TypeScript code or even ES 6 code. If you choose not to use TypeScript, you can still just write ES 6 code and it applies to TypeScript transpilers so it’s fine.

There are other examples of these partnerships happening but more importantly, we’re also taking all these tools and integrating them into a project we call an angular-cli. Angular-cli is a common line interface for building Angular applications.

The goal here is really to build a tool that will allow you to start the project, expand the project, test it, build it, deploy it all with a single tool, or all of these other tools that you need to get all these stuff done are already integrated for you. If you just customize stuff, that’s okay. If you want to customize this [inaudible], if you want to do a custom SaaS processor – systems processor, you can do that. But out of the boxes, you just get some good experience that usually involves you to customize more.

You did mention early on the conversation, probably worth re-emphasizing, that somebody who’s coming at this from ECMAScript 5, programming in JavaScript in the old JavaScript way, we’re going to make sure that they can continue to program with Angular 2 in that fashion if they so choose, right?

Have I mentioned there’s a guy named Ward working on docs for that?

Yeah. [Chuckles] They want to hear it from you, man. They don’t want to hear it [crosstalk].

It’s a miracle that people should be able to stay with ES 5 if that’s their desire. We are focusing on TypeScript and other things because we see a lot of advantage of it, and just ES 6 if you want to go to that. But if folks want to stay with what works in all of the browsers today without a transpiler, ES 5 is the way to go.

I’ve got a follow up question on that. I’ve seen the syntax for ES 5 and compared to TypeScript, I would say it was hard to objectively say that it’s anything other than – certainly, it’s more wordy. I would say it’s a pretty decent step down. Is there any work specifically going to be done on that to make it a little bit easier, or is it what it is because this is going to get in ES 5.

Yeah. The work has been done already. It’s called ES 6. [Laughter]

That’s a great place.

Seriously. ES 5 version of Angular is not more wordy because Angular’s more wordy in ES 5. It’s because ES 5 is more wordy than ES 6. So if you want [inaudible] that looks better that is less verbose, use ES 6 or TypeScript.

And if you really want to look at ES 5, just transpile it back down ES 5 and look at it.

Right.

Well, I certainly hope that very few people decide to author a lot of Angular 2 in ES 5 just because I think this is a great opportunity for people to move into the modern day.

The important thing is to realize that this is not Angular doing – Angular’s not creating ES 6 and TypeScript. These things are happening regardless of Angular. And you can choose to either stay with ES 5 and Angular will be there for you or you can go to this new language that we think is much better and will make you more productive. Once you learn it, you’ll get better for [inaudible] Angular with it.

Yeah man. We could enter – we could take out the word Angular in this whole conversation that we’re having right now and insert Aurelia, Ember – whatever you want. It’s the same problem.

Yeah. My experience has been that it’s the stumbling around with transpilers and the whole complicated build system that gets in the way before I can get started with my application that makes me feel like, “Hey, too much to learn here. Why can’t I just go with what I know for a while?” [Crosstalk]

And I think that’s based on building angular-cli.

Yeah. I think that’s part of your answer to this question.

Yes.

But we’re still going to teach people how to tell – how to roll with ES 5.

What do you guys really see the usage percentage of the CLI being? A mere 100% of people who are doing Angular 2 will be using the CLI or less? [Crosstalk]

Today, it’s very little. We don’t obviously have metrics yet. We love to assume that CLI because in the current state, the CLI’s are – I call it [inaudible] and it’s [inaudible]. What we did is we partnered with the Ember CLI team to get off the ground quickly and build something that does the basic stuff. [Inaudible] projects allows you to add more components to your projects, provides you both system [inaudible] development server has testing built in and it has deployment to GitHub pages and Firebase built in but there are still things that are missing.

We don’t have optimization pipelines set up. Many things where Ember shows up and it’s weird where if you don’t have background and understand the partnership between Ember CLI and the Angular, [inaudible] you're surprised that you see Ember and you [inaudible].

So there are these things that still need to be fixed up. We have a plan for this and we’re actually planning to get the CLI in shape. We could replace most of the documentation that we have today that [inaudible] guys to use the CLI by the end of this [inaudible].

So switching gears a bit, Lukas and I were having this conversation about the designer story for Angular 2. So you might have things like inline templates that are considered best practices by some people and other people, not such best practices. So do you want to go the declarative route or the imperative context of – how do you see that playing out with Angular 2? Any recommendations?

Besides mine? [Chuckles] This comes down to how much HTML you want inside your JavaScript.

Yes.

That’s a very [inaudible] version, Ward. I don’t know where this came – this idea that inline templates are the best practice.

It certainly is easy to write if you want templates in ES 6 because you have to pack things so you have modular strings. It might be convenient for the purposes of our documentation to inline all the stuff because you can visually see next to each other.

I certainly wouldn’t want to be editing a very large file – HTML file inside of JavaScript because, well, the editors don’t understand the structural [inaudible]. [Crosstalk]

[Inaudible] has this [inaudible] last that it’s HTMLs have a string and I can’t see you guys use keystrokes – you get that. But in general, it’s just that it happens. [Inaudible] extension, see where else it’s done.

So I think for most large scale projects, think having a proper [inaudible] of HTML and JavaScript is probably the proper to go.

It’s also better when you have so small projects that it’s probably – I’m the developer, I’m the backend and I’m the UX designer and I’m all these people. But if we are a bigger team where I actually have some UX designers on it, it’s much nicer for them to be able to deal with just the template in the HTML [inaudible] tools that they already know. We can go from their prototypes straight into the development workflow without changing anything in Angular which is for a big team and being inclusive of all your roles, I think it’s very nice to have external templates.

Now, what about things like ng template casts that existed in the plugin for Angular 1; how do we handle things that where angular-cli will help us out [inaudible]? Will we have to load our HTML CSS in every page?

Yeah. Sure.

So it helps to acknowledge that you would compile down your application and even in the [inaudible] process, we actually move the templates into the UI templates, even going this step further which is we actually generate all of the source [inaudible] to create that.

So when in this new world where Angular or in our world, it’s about 10K gig or something can’t [inaudible], what happens? The idea is that what we ship down the browser is all one huge job [inaudible] for the primary assets inline into them whether it’s a small JavaScript [inaudible]. [Chuckles] One single JavaScript file and that’s going to be the [inaudible] where all these assets are inline in both style sheets and HTML. Obviously, you can just [inaudible] stay separate.

Yeah, because we want this balance, right? And that’s where I’m curious of where these old tools are going to end up. We don’t want to load every single file into visually everywhere meaning every component’s got CSS and HTML and so on, but we also don’t want to be loading one massive file like you said. So imagine [crosstalk].

[Inaudible] by which you break things down, but for component view of the performance, you want to download as few files as possible and [crosstalk].

With HTTP.

With HTTP. So also what you want to do is you want to skip the necessary compilation things of Angular 2. So you want all the [inaudible] offline and just ship the file product which is [inaudible] as any application code as somebody [inaudible] AngularJS where all the things are hooked up.

[Inaudible] is necessary to know expression [inaudible] services a lot.

This is actually how we want to – the code size, the [inaudible] of size with the offline template compilation as we – what we call it. We’ll be able to just take the HTML, turn it into JavaScript code and then throw away the Angular compiler and now ship it down to the browser because it’s not necessary there anymore.

So this allows us to remove big chunks of the code base and just launch it [inaudible]. Or we can do the same thing with the [inaudible] pieces of Angular. This is part of a strategy to reuse the code size. Then before we got to worry about our code generating too much stuff, we actually measure it and turns out the core generated stuff is smaller than the stuff we are dropping. [Crosstalk]

Than the actual templates [crosstalk]?

Yeah. We’re not going to be generating megabytes of code [crosstalk] to ten kilobytes, right? [Chuckles]

So I’m looking at the couple of apps they built lately with Angular 2. These are just apps I’m kind of building out; I’m working on a course for Angular 2 to get moving and I’ve been doing some samples and some hackathons – things like that. One thing that has become very painful for me right now is while I’m really used to Angular 2 and I’ve got know for the tooling side of things in my workflow, it’s hard for me to find a good way to put UI components in place.

You mentioned animations aren’t ready yet; that’s one of the things on your list, but what about just UI components. If I want to make sure Angular Material in version 1 is awesome, is there a platform or a strategy for getting that ready?

So the same folks who have built the Angular Material 1 are now working on the Angular Material 2 suites. And they are also shooting for an initial sets of those in a couple of months. We’re going to be seeing the early parts of their efforts very soon but that’s something we think are very useful in a couple of months.

Sweet. So I don’t have to stay on bootstrap.

Well you can. Actually, there’s a couple of different versions of bootstrap and what it’s for, Angular 2

had already done. I just saw a prime phase version of components for Angular 2. So they’re all under the [inaudible], you don’t have to go Angular Material design although we love it here. There are going to be a lot of different ways you can do it. But [inaudible] folks have announced for Angular 2, the Kendo UI folks – you’ll have options.

Sweet.

So we are going to see them, see all the control vendors get involved and adapting to Angular 2.

I think all the ones that I’ve seen. And there’s a new suite of Fabric UI stuff out there from Andrew Connell and I think they're going to be doing Angular 2 version as well. So yeah, lots of great things through all that.

This is a time – delicate issue because they’re enthusiast and then there are people who are, as we say, from Missouri and that’s about observables. Some people just can’t wait to see observables and some people are just shaking their head. So what’s the Angular position on observables and how to make these audiences comfortable? Because we’ve been talking about it a lot on different shows and I could tell you that many of us have had our challenges trying to wrap our heads around observable in a way that we never had that kind of trouble with promises.

So how long did it take us to develop process?

Overnight. [Crosstalk]

Well no.

JavaScript is invented at ’95. Promises are like in 2002 so let’s [crosstalk].

Alright. I’m going to call BS on this one right away, alright? Because you look at the APIs of promises and observables; you just look at it and promises are vastly simpler than observables and they don’t have this nearly as many options.

I think they're still – there’s a whole lot of developers that haven’t even quite grasp promises. I know I can teach promises and I always could to people who have never seen it before in an hour or less. I’m not sure that I could do that in an observable.

But I’m not [inaudible] observable; I’m just laying it out there that I think it’s not fair to say that these are the same animal. They’re quite different animals; I’m just wondering how you’re going to put people – what’s the position overall for Angular?

You mean like observables for events or events that are happening more than once? Definitely, observables is the way to go. One thing that we are experiencing with is who use observables exclusively [inaudible] on these promises. This is controversial and right now, we’re keeping those open in both ways.

But back to my question, promises define memory [inaudible] well were created in the ‘70s. There was a big spike of interest in the ‘80s, ‘90s and then finally, 2012, the JavaScript community realized that this could actually be useful to solve problems that we’ll be having for two decades then promises took off.

Observables [inaudible] position set that observables are much more powerful. With that, the API services were significantly bigger.

I think the challenge we have is how do we explain that to developers that the bigger API service is actually worth it. And if you start thinking in terms of observables, you’ll be actually much more productive. You will have much more flexibility. You’ll be able to do things that you cannot do with callbacks or promises.

The thing that I’ve seen that convinces people is in simple cases, it looks way worse. But when I’m trying to write real code where I have to do retry, cancellation, all these things, it’s whoa, it’s a lot less code and way easier to read.

Talking about who built real time dashboard that tries to aggregate multiple streams of data that are coming in. Their sources are reliable units and we connect to them. It’s almost impossible to do this correctly with promises or callbacks. [Crosstalk]

Yeah. Everybody’s on board when it comes to streams. I think we have a whole – we’re still not ahead of that. The use for it for [inaudible] that becomes challenging for people who got used to promises. [Crosstalk]

We’re jumping a little bit, too, on this because I think – I’ve been doing observables now with Angular 2 and it’s really been my first [inaudible] to be honest with RxJS and observables in Angular 2.

And the struggle I’ve had is not the happy path. I’ve been using it exclusively now for getting my data and doing things for events; the struggle I personally had is when I try to do what I call realworld scenarios. I don’t just call HTTP and it works; sometimes I get errors back. And where do I [inaudible] those errors? There is the service who running the component without using [inaudible] then figuring out how do I handle exception handling with observables. That’s been – I found that that’s not very straightforward at least to me so I think that’s an area.

Igor, you get it on the [inaudible] is how do people show people the value in using these and that’s actually going to be helpful. I don’t know the answer to that right now.

I think it’s only right and I think there’s a lot of work to be done to make debugging and errorhandling better. But honestly, if you look at where observables has the big [inaudible] of promises, observables are already in a much better shape.

We have a specification for promises that doesn’t allow us to have local error handling. This [inaudible] is discussed this only now. Whereas with the observables, observables has a lot of specification and error handling so typically, they're much better.

And you're saying my experience has been painful except the handling side? I’ve actually kind of enjoyed the other side. I’ve actually enjoyed using observables to get the data back into send beta around my application in Angular 2.

I do think people will adapt to them, but on the other side, I think there’s a friction we have to be aware of that not only learning Angular 2 but now you’re also learning this new thing.

Yup. This is our responsibility to remove the friction.

Yeah. But you guys don’t know in Rx. Let’s be clear, right, it’s not a Google thing. Observables aren’t your thing; it’s just something that you’re adopting and saying this is useful in Angular. Is that correct?

Yeah, but we collaborate with the folks – on the people who work on our apps a lot. A lot of the other [inaudible].

It’s probably worth pointing out to our audience that you can always take an observable and go to promise on it and you're back in business or just substitute an event for a subscribe. It’s usually almost the same. We have to help people get there and it’s not that it’s impossible.

I’m not knocking observables; I’m just saying it’s a hill to climb and we need to face it, figure out how to get people up the hill.

So let’s talk about Angular. [Laughter] I agree; it’s been – I spend a lot of time there but you mentioned the router a little bit, Igor. I believed you’ve mentioned it or maybe it was Brad on what things it have to round out and get ready for the release.

Can you tell us what your plans are for the router and why you feel like you feel like you need to do a little bit more work there?

Yeah, I can definitely talk about that for a bit.

The biggest challenge I see is if you look at how we configure routes today and how we generate links to all these routes, things work. I feel capability-wise and feature-wise, the router’s pretty solid. We have override features, we can tackle scenarios that we could not even imagine with Angular 1. So I hope that it’s good. I’m sure it will conquer those bugs and we’ll fix those, but architecturally and conceptually, I feel pretty good about the router.

One thing that bugs me is that the way we express the configuration, how we create links, it’s slightly [inaudible] mix these universal [inaudible] but I think we can do much better. Now the question is how.

One of our goals with Angular 2 is to make it [inaudible] friendly; make it so that we can analyze things statically and do as much work as possible upfront so that we do very well with working fulltime. This allows to get the full [inaudible] increase with the smooth sailing applications.

I feel like with router, you can do better in the [inaudible]. Especially in static finalizing the links and static finalizing how different parts of the applications interconnect it. So this is something worth exploring. We create an API that doesn’t rely on the constant strings, rather we have symbols or objects with methods that we could use for generating methods.

I have additional proposals that is on GitHub that kind of solves this problem but that proposal’s running problems with voice loading. If you get all these doing static analyzability, how you do lazy loading in such a world? Because as soon as you do lazy loading, you don’t have a single compilation [inaudible], you have basically breaking applications and multiple intertwined multiple compilation units in that kind of sets of completion and all those static properties of the [inaudible].

So before we decide what exactly we want to do with the routing, we decided to tackle the lazy loading first. So our strategy is figure out how to do lazy loading in general, how to deal with end to end, starting from compilation all the way up to loading and joining the code and making the code [inaudible] in WiFi. Once this is solved which is what we’re working on now, we’ll go back to the router and we’ll [inaudible] how does the router fit into this new world where lazy loading’s probably would be fine. It has proper rules and let’s apple these rules about it.

To be clear, lazy loading works and we’re using it into production, [inaudible]. What Igor was talking about was he worked end to end with your package manager for the router so things just can’t happen for you and you’re not allowed to do it on Mac.

Yeah.

Say that if I hear you right then, Brad, what you're saying is that you can just define your app and your routes and your app, just by nature, have a router when it works. Is it with all the [inaudible] to figure out how to [inaudible] things for you, you got to do nothing.

Yeah. But one of the goals of our 10K plan is to load browsers easily so that you don’t play upfront cost of downloading the application when you just want to render one screen.

So much sense to me because some of the routers I’ve seen in the past require a lot of configuration – all the configuration I tried made it very difficult to change what’s available later, whether it’s the lazy loading or because authorizations change and you wanted to open or close features. So the fact that you're starting from that larger problem and working back to the router just makes so much sense to me.

It does. As somebody who just – just last night, I was working on a routing example for a certain application example. It hit me as I was trying to do router with Angular 2. I get it and it works. The number of things that I have to configure – and I’m not just talking the route config, I’m talking about the different things I have to import like the router length, the route of the [inaudible], the route of providers, then the different options on route config, I’m still making mistakes along the way especially if you like nested routes.

For example, I’ve seen – I’ve done this three times and it made me feel good the other day. I have a respected friend of mine who’s very good at Angular 2 make the same mistake of I had a route and I actually pointed it to itself. I know that doesn’t work but somehow, because I got so confused in the route configuration, I did that and of course the error was like ‘dude, what are you doing?’

So I think the problem isn’t that the router’s bad; it’s that the dual routing well; you have to tell the router a lot of information. Right now, it’s a lot of manual strings as Igor pointer out. But if there’s a way to make that simpler or better, I’m all for it. That would be great for everybody.

Yup. That’s definitely a goal. If you look at the evolution of Angular 2, we started with more verbose but very explicit on the view syntax, then slowly shaved off stuff as we got experience with the semantics of the code, as Miško has mentioned, and are really focused on the semantics.

The syntax can always be improved; you can change syntax with different syntax if you want to. The semantics are very difficult to change. Especially when it comes to migration. We see this very clearly with Angular 1 going to Angular 2. The syntactical changes are not a big deal; it’s the semantical changes between the two that will be the biggest challenge for us. This is where we are focusing our ng-upgrade if [inaudible].

Speaking of syntactical changes, I just – they wouldn’t be complete, Igor, unless I heard you say the term banana in a box on this podcast. I think it was you who coined it, wasn’t it? [Laughter]

Oh, we needed that. Definitely, we needed that moment.

Yeah. These are functional programming freaks and experts.

I know. I think both are true. [Laughter]

So he was the one who introduced the two-way binding syntax and make it very careful about how we talked about [inaudible] binding because we see people being confused about how we talk about it.

We have a syntax that allows you to express one-way binding in both directions. Let’s put it that way. [Chuckles]

The syntax is like a box of bananas.

No. That’s banana in a box.

If you can put a box inside a banana, you are welcome to try.

You know what [crosstalk] I think we need Ward to be the [inaudible].

[Chuckles] Okay.

This has a longer history of partial programming word that it’s a banana [inaudible]. If you want to geek out, just look at banana stuff in functional programming. You’ll find these things. [Chuckles]

I can see that John Papa’s going to have a dance. [Inaudible] banana in a box [crosstalk].

We’re going to have to make [inaudible] at the conference.

Let’s be clear about the square brackets that we’re talking about. The square brackets [crosstalk] whatever they are.

So I have a question that I like each of you to answer one after the other and that is what is the myth about Angular 2 that you encounter that you would like to explode if you can get a shot at that question?

The funny one I get all the time is that the Angular team might be going away. It’s not really specific to Angular 2.

Well that’s true, isn’t it?

[Inaudible]. I don’t know why. I think people are worried. They want to know how can I rely on this going forward.

What makes them think about [crosstalk]?

I don’t know. Well – okay, Google’s a big company and not all of our products live forever. So they may look at other thigs we’ve done like, “Oh, that thing went away. There’s no more reader,” which we’re honestly all excited about but we’re a big company. And so they look at that and like, “Look, some products went away. We may not have Angular forever.”

So who else wants to crack at that question?

The myth about Angular 2. Here we go.

Who doesn’t use Angular?

Oh, I’ve heard that one, yes.

I hope everyone uses Angular.

Oh, that’s a good one.

Right. Because there are certain Google products that don’t use Angular, therefore, Google does it.

Right. We know we have not converted every single line of source code to Angular.

You know, it will actually be much easier for us who did not use Angular because we wouldn’t need to deal with all these upgrades and migration. [Chuckles] In a way, I cannot restyle the case but it’s far from true. We have 3,000 applications. That’s something crazy.

That’s a lot. Most of the big [inaudible] that we use like Green Tea; our bug analyzer runs on and all

of our HR tools and [crosstalk].

Hiring tools.

Hiring tools.

The holy cloud, the cloud Google has [inaudible] the whole thing needs extra [inaudible] and runs something [inaudible].

Oh, let me just plug Angular.com for the list of all the stuff that does run on Angular.

Yeah. You can check which of those applications are Google’s specifics [inaudible].

That’s not Google’s specifics; there’s like 38 – 30 to 40 things from Google and lots of things from all over the world.

So let me invert that for a second and say if Google’s got such an investment in Angular 2, why is it bothering and why is it working so hard to develop an Angular for the public to use which is a tremendous [inaudible]. That’s a lot of support.

That’s a good question. That’s easy because that’s not for us [inaudible] do it.

So Google does pays you to have fun.

Oh, that’s a good question to answer. [Crosstalk]

We’re glad that you’re doing it but it’s like why are they working so hard to make it easy for me – does not work for Google – and John who doesn’t and all the rest, why are they making it – working so hard to make it easy for us to use Angular?

There are many answers to this. I think when people ask this question, they think that maybe we are thieves in the [inaudible] machine that gets thrown this way and that in Google. It’s us who decided to do these things and – I don’t know, I’ve been here for a while. People trust me to do things. We get to do these, this [inaudible], but the thing that we like about it and Igor and Miško have been [inaudible] in is that we get tremendous feedback and having a platform that’s built into the world is so much stronger than one that is purely inward facing where our group think – can dictate that it’s good when it’s really not.

I think we are so lucky to be in this position where we are really on the border between the internal worlds of Google and the external world of open source, the JavaScript development. And Angular is a resolve confusion of these two worlds because I don’t think we are able to build Angular if it was purely open source project that we’ll be just hacking on our open source free time. We also thought the same thing; if we just built internally and explored it like, here’s the code base; go ahead and use it. It’s really the fusion of two worlds that brings the magic and that makes Angular work.

Now, through Angular, we have created all these great friendships and partnerships with other people like TypeScript and Rx, Ember and lots of other people that helped us influence where Angular is going, how it’s evolving and how it works internally. I don’t think it would be possible to do it in any other way than [inaudible].

What about a related question on where things are heading towards for you guys and that’s – you guys mentioned these other teams you were working on and React’s another one, right? So you guys talked to them?

Yup!

React has, I think, a React Native. And you're building mobile applications and what-nots that’s pretty cool. Is there going to be an Angular Native? Where are you guys leaning – where do you want to point people towards building Angular 2 apps for mobile?

We’ve been working most closely with a company called Telerik. These are the guys who make the Kendo UI components for Angular and other platforms but they have a platform called NativeScript. They’ve been building this atop Angular 2 so you can build the same services and components that you do but all with an actually front end render with native UI components. They’ve developed this and we’ve think of a lot of examples and it’s [inaudible] ready to go.

We’ve also been working with the React team on React Native and that’s not as far along but I’d love to see more investments. And Igor, maybe you’ve got some friends that’s working on

[inaudible].

[Inaudible].

Yup, so we have some of their folks working on the React Native angle of this.

There are different frameworks; there are different ways to develop native apps. I think there will be rational reasons why you might pick either of them depending on your needs. Where the – I don’t know if I’m – somebody can slap me that I’m incorrectly categorize these things, but one aspect of this is the NativeScript guys built a lot of their frameworks to make it possible to build one app that runs great on multiple [inaudible] platforms, iOS and Android and I think Windows Mobile will come up as well.

Whereas the React team is much more about, hey, we’re going to provide a platform-specific API that you can use to build the iOS and Android app. And there’s reasons that you might pick either of them.

Yeah. We had TJ and Burke on both this show and on the JavaScript Jabber Show. We actually had a React Native podcast on the devchat.tv network. So if you go to reactnativeradio.com, you can check that out.

I actually – I tried to send the React Team a bunch of Christmas tributes and Christmas over there, it pains me because I pulled in, I was doing this and they never showed up so I still [inaudible].

Nice.

So one of the questions that I like to talk about is I think that a lot of people, when they learned Angular 1, there was sort of an implicit guidance into architecture design. It was very light, it was relatively unopinionated even for Angular which tends to be considered a fairly opinionated framework or at least moderately opinionated.

And I think that with Angular 2, it seems like there’s less guidance in the architectural like build things here, put things here, put this type of logic here and here. What are your thoughts about that [inaudible]?

I would actually say that in Angular 2, we’re going to have more opinions or more recommendations than we had in Angular 1. If you look at Angular 1, we didn’t have a package manager that we will say, “This is the package manager that we stand behind and we should be using.” Or we didn’t have a module loader that we were saying this should be the module loader you should be using.

We left all these things – both of them because by the time we were building Angular 1, there was no clear winner. It was not clear what is the best for an application. And depending on the scenario or the company, the team that we’re building the application with, the answer was different.

In Angular 2, these things have solidified. There’s just one mean package manager out there for JavaScript which is the module loader and the syntax and how you express what’s [inaudible] have been specified in the ECMAScript’s specifications. Right now, we have just syntax and module loader’s still on the wait, but it may not go too far from there.

Now that we have plenty of these fundamental issues result in the standard play, we have much better foundations to build than the rest of the recommendations on. And the reason why we haven’t had any strong opinions about how to build Angular 2 applications was because when you need to give a developer some freedom to experiment and so, what is the best way to create my [inaudible] structure? What is the best way to – what patterns do you use?

I think right now, we have a pretty good idea of what works and what doesn’t. Our focus before Angular 2 final will be on, writing down some recommendations and building them into angular-cli and building the rest of the tooling around strict conditions.

Okay. Joe, I owe you so I think you let something different of your question.

What do you think I’m at? [Chuckles]

You’re asking are we in those traditional 00 style app architecture or any more functional react to that architecture?

That’s a great question to ask as well. [Chuckles]

Why did you guys thought [inaudible]?

I think that’s a question you wanted? [Chuckles]

No. I know what the question Joe was asking.

We’ve had conversations about this so – you guys and I have so I know that this is something that you guys have heard me talking about before, but I’m just curious to hear where you guys are at in this. Because I do think that architecture matters and we definitely have been living in this other world and now more reactive architectures – I don’t know if it’s taking the world by storm so much as it’s really showing up in a lot of places. [Crosstalk]

Being talked about in a lot of places and we’ve been having this debate ourselves here on this podcast as to whether there’s a – throwing the baby out with the bathwater going on. We’re interested in whether you guys are – I think that’s a great question, Brad. Do you folks have a position on that or are you going to be agnostic about that?

So yeah, we are supporting both. And it would actually design Angular specifically for both. Now I have some opinions and you guys jump in like everyone here should [inaudible]. I think we haven’t seen any big apps done in functional reactive style. I would like to see some big apps done in functional reactive style.

Since we have a [inaudible], I can’t say wholeheartedly, “Yes, you should do that; this will happen to you if you do it.” At the same time, in the micro-examples that we see, there are a lot of nice properties of the functional reactive style in testing and data flow and debug ability. Because we’ve – and at the same time, I think Victor Savkin I’ve seen – which Igor highlighted as our expert, he has some nice blog posts on when to pick one versus the other. I think it’s actually not going to be a truly one or the other but I think it will be a mixed and like in the leaf nodes. It makes a lot of sense to have stakes and in the [inaudible] app, maybe I would love to have an immutable state that I deal with functionally. But the jury’s a little bit out so we are spreading both. We will have a bunch of blog posts.

I’ve seen a lot of other good people using Redux and other architecture styles and things built on Rx specifically to do functional style with Angular 2. So I’m excited. I remember when we moved to object-related programming, there was a lot of evangelism and help we need to get from people. I think we’ll need to help people get to the [inaudible] style.

I think we should [Inaudible] simplify a little large applications; it’s because when we say ‘a large application’, we mean hundreds of developers and hundreds of thousands and billions of the last [inaudible].

That’s right. So on Green Tea, no, we’re not using any reactive programming yet.

Cool. Excellent answer.

One of the things I’ve been asked about – I’m sure you guys have been asked about – we go from this simple line back down is Angular 1, Angular 2 migration? Some people heard the message, some people haven’t heard the message, and some people – those people, who have heard the message about the ng-upgrade and tools would like to know are those in an array stage or are they scheduled for a dramatic change or just incremental improvements.

What’s today’s story about upgrading from Angular 1?

The limitations are – so Angular 1 [inaudible] upgrade – we can upgrade any kind of component or service by wrapping it into Angular 2. The kind of limitations that you have to deal with is that anyone that dom elements is really bold by either Angular 1 or Angular 2. So things like a directive that only augments existing element living in that kind of automatic fashion can certainly make a copy of it, rewrite it and have two copies of it running inside of Angular 1 and Angular 2.

The other area on which it’s got a limitation is that I can [inaudible] with just a supported dollar compile functions [inaudible] similarity. But [inaudible] to those things mentioned, the upgrade story work nice. It is something that you will try and give it a look.

We were actually working with several [inaudible] teams to get out for best practices, because we do want to be able to hand people some recipes and things that will be helpful like what’s Green Tea we learned – hey, do your services first. We want to have a similar set of nice things that will be helping people get along faster this year.

It’s just another thing out of your toolbox that you can certainly try converting the link components over to Angular 2 when there’s only branching updates. It really comes into play. We’re getting to that situation where we hate to use the same components from both Angular 1 and Angular 2 for whatever historical reason. And so it’s just nice to have these extra option but you can certainly just start with the least or start with the root of the application and just convert that one to the other – one after the other.

There, you don’t need ng-upgrade which is [inaudible] question. Same [inaudible], like if you have, please do not [inaudible] these circular dependencies so that you don’t have to be stuck going forward.

Well, when you’re mixing Angular 2 inside an Angular 1.

Can you explain to people really quick the difference between what ng-upgrade and ng-forward are?

ng-forward is the community whereas ng-upgrade is the internal core team effort. Ng-forward, I believe, it teaches Angular 1 and Angular 2 syntax but you keep Angular 1 semantics. Whereas ngupgrade actually allows the two frameworks to co-exist out of the HTML seamlessly, back and forth, collaboration for these two frameworks.

So out there, there’s a whole large community. Honestly, I don’t have any idea how large the community is but I imagine you guys do when you hear from them all the time; will we hear from you guys this year in conferences or in other news out there? Do you have anybody on your team that’s going to take a kneed on the developer outreach?

Yeah. So we – So Jules Kremer tried our team late last year and she has been working – I’m figuring out which conferences we’re going to be at. It’s going to be a lot more than we were in the past years. We’ve been kind of finding out. And while we went to the Angular Pacific Conference last year, we really want to go to places that maybe you haven’t heard the Angular 2 story; maybe a lot [inaudible] than Angular 1 story.

Hopefully, you’ll see us. Maybe not the whole team but we do want to send our folks to a bunch of places that we’ve not been in the past.

Can you be more specific than that?

Ah, okay. We have a big list. We need to get it public.

It’s going to be public. Yeah.

We’ll publish our list.

Are you going to Fluent?

I am going to Fluent, yeah. I think I’m going to be in the Keynote so I’m excited about that.

Okay. NDC, how about that one? [Chuckles]

I don’t think it’s on my list, man.

Alright, here’s the most important one because this is by far the best conference out there. That Conference. I totally surprised you with what I said, didn’t I?

You did. You threw me off, Joe.

[Chuckles] Are you going to That Conference?

We’ve been there in the past. I think Brian’s been or Miško’s been.

Brad’s also been. It’s kind of cute the first time you hear about that conference, ha-ha, but it gets old. [Laughter]

I just love going on water slides in between talks. [Chuckles]

Yeah. Joe gives his talks in his swimming trunks.

No.

Yeah.

This is a much less important one but are you by chance going to the ng-conf?

Yes.

What is ng-conf?

Oh, Igor, I’ll tell you later. [Chuckles]

We’ll tell you when you’re older, right? My question is I think people are pretty used to hearing announcements for some of these conferences, especially some of them like AngularConnect or ng-conf. With the beta being out there, are there going to be any big announcements or big surprises at any of these conferences? Or is it going to be pretty much just, “Here’s the progress we made and more or less what you expected since it’s in beta”?

That depends if you read our meeting notes or not.

Maybe he’s just sneakily trying to ask if final is going to be ready for ng-conf.

No. we will surprise people who aren’t paying attention to all of our really open progress.

Oh okay.

Maybe it would be very surprising to them. But if you read GitHub, nothing we can do can be a surprise because it’s all – you can see every move we make.

I suppose that’s true.

Almost every discussion that – and it happens in there really – it can be overwhelming but it’s [crosstalk].

So just don’t read it and there’ll be a lot of surprises.

Yeah, it would be super nice. Alright, well I know that some folks have said they have to go soon so let’s go ahead and get to the picks. John, do you have some picks for us?

I do. There’s an awesome new NPM module out there that I want to tell the whole world about because the owner of it is so proud of it. It’s an awesome in-memory web API up on NPM. And we also – it’s actually our famous Ward Bell. So if you need some in-memory web API to run with, definitely check this thing out. I’ll put the link to it inside of the show notes. It’s called a2-in-memoryweb-api.

There’s not enough dashes in that name, Ward. [Chuckles]

I know. You need to throw in a hyphen or two.

Maybe some underscores.

I’m working on that. Let me see how long we can make a name. It’s a tradition that my company came up [chuckles] a very long name. If you're going to promote it, thank you, John, then by all means, contribute. It needs a lot of help but it needs a start. I appreciate that.

Yeah, it just went to beta last month. Oh wait, that was something else. [Chuckles]

It actually just got written this weekend. But it truly is really cool. I’m actually using it with some course [inaudible] together.

I guess my other pick is I’m very excited to announce that we’re writing and Angular 2 course for Pluralsight which will be coming out hopefully in February.

Woo!

Nice. Alright, Ward, what are your picks?

I’m going off-track all together because the last night I saw [crosstalk].

Star Wars? [Laughter]

He loved it.

Never! Gosh. I did anything but watch that. Instead of Star Wars, I went to see Julia Gillard, the first of female prime minister of Australia; as far as I know, the only one so far, and I was blown away by her talent. Her skills is as a presenter were spectacular. Never seen a politician who could present that well and her sensibilities were so great. She’s a total star so if you ever get a chance to see her speak and she speaks throughout the US [inaudible], put her on your list. Julia Gillard, former prime minister of Australia.

Alright. Joe, what are your picks?

Alright. So I spent the weekend at Bryce National Park and had a great time. So I’m going to pick Bryce National Park as my pick for today. It’s a really fun national park; got some amazing geography to look at. A lot of fun hikes – we didn’t do too much hiking because of the amount of snow that’s there in the winter, but it is a really great national park and it does have a lot of fun hikes. If you want to go do more snow [inaudible] type hiking in the winter or going summer.

While I’m at it, I’m going to pick a new board game I just played this last weekend that I really liked as well. It’ called Stockpile. It’s one word. Great board game, easy to learn to pick up place very quick; place like five people or something. Being a big board game geek that I am, I play a lot of new board games and this one truck out to me. It’s a great one.

One more thing I want to mention is that, of course, ng-conf is coming up. We’ve got a lot of awesome things that are planned and some amazing events involving the Angular team themselves and lots of experts in the industry. And we’re always looking for sponsors so if you’re a company, is interested in sponsoring ng-conf, you could hold this. As of right now, that’s the only way – really the only way to get tickets of them, being accepted as a speaker.

The CFP is open right now so if you have any great ideas for an awesome talk at Angular, submit those in.

Alright. Lukas, what about you?

My pick this week is the GitHub project ngrx by Rob Wormald. Absolutely fantastic; just a Redux style project with observables. It’s really easy to use. Just inverted my entire paradigm about how data flows in an Angular 2 application. I’m writing a blog post on it. Now, Ward and I cannot [inaudible] it out on [inaudible] done by – an awesome work by Rob on ngrx. It’s really cool.

Actually, I think it’s very cool, too. Just because I take up the traditional side of these things, doesn’t mean I’m not curious.

Aright. I’ve got some picks. The first one is – I just want to let people know, especially in this audience, that I’m actually working things out so that we can do a live show in ng-nl. Now live means that I’ll be there putting Crowdcast of Google Hangouts or something up on the screen so that everybody else can join in.

So if you want to be involved with that, then go ahead and jump in. I’m probably going to do a meet-up beforehand. I’m going to let the Angular guys go if you guys have a second to do some picks. Seems like you guys have to go, too, and then I’ll finish up with picks.

I can never pick just once. So I saw this crazy movie called The Revenant which is not really my kind of movie, but if you want to feel grateful about your situation, you’re in a first-word country, go watch that.

If you want something technical, there’s an awesome article on the Ponyfoo website on the service workers and how they can make things a lot better for loop maps.

Awesome.

So I’d like to pick Ward Bell for doing an awesome job on the documentation server for Angular 2.

Now, I’m blushing. [Chuckles]

I’m thinking it, Ward.

Yes, I’m thinking it. I’m thinking [inaudible].

Okay, I have two things. I read this very interesting book called Architecture of Simple Open Source Applications. The premise of the book is there have been successful open source projects out there that we should learn about, and unlike architects of real buildings, software engineers don’t really study history and don’t look at how these successful projects have been architected.

We learn a lot about languages and how to do stuff but not how things have been done in the past and what works [inaudible]. And this book tries to capture several very successful open source project in a very objective way and showing a lot work with it. I really like it.

The second thing I want to pick is iPad Pro and the Apple Pencil. I tried it, I played with it. I played with a paper half and it’s amazing. Really cool stuff. I always liked to doodle but I tried different tablets, different things I’ve had. There were Android tablets in the past and nothing works well.

Paper was always better. But now with the iPad Pro and the Apple Pencil, wow, this is so powerful.

I still am skeptical but you can prove me wrong. We’ll have to compare notes at ng-conf.

Okay.

Alright. My other pick that I was going to do was just the people that have been working with me for a while to get all these stuff done.

Mandy – we’ve mentioned her probably in every third show. But she’s worked with me for a while; she’s the one that helps line up a lot of the guests, make sure they know what they need to do to get on the show and it’s the podcast. She does a great job with all that stuff so a big thanks to her.

Then I’ve also got a developer that’s been working with me for the past two or so years. He’s helped me put together most of devchat.tv and the conference sites and everything else. His name is Federico and – quick shout-out to him as well just because he’s done a lot of work that you all have benefitted from. I really want to give him some credit.

So yeah, those are my picks. I don’t think there’s anything else. We’ll go ahead and wrap the show. We’ll catch you all next week.