John talks with Juri Strumpflohner, an industry expert and angular trainer; and Rob Wormald, a developer on the Angular core team, getting into how Angular has evolved with the 2.0 release, powerful new features, their favorite libraries, and where the future is taking it.
John talks with Juri Strumpflohner, an industry expert and angular trainer; and Rob Wormald, an Angular core development team member, getting into how Angular has evolved with the 2.0 release, powerful new features, their favorite libraries, and where the future is taking it.
Angular has gotten much better under the hood. Rob talks about how the Angular team is working on really improving the code while still keeping the public API stable. He also talks about the team's ongoing debate on where to improve the code. Faster? Smaller? Currently, the team has chosen to work on making it smaller and has improved the bundle size of Angular.
One of the new things about Angular that people are most excited about is the Elements and CLI Schematics libraries. Juri talks about how Elements opens up a "whole new world," allowing people not to have to resolve the same problems over and over again by letting them create reusable angular components.
One of the hardest things to learn with Angular was the design and architecture patterns. Rob goes into how the team has improved the documentation, now actually getting into best practices and giving architecture guidelines.
Finally, our guests get into their favorite Angular libraries. NgRx Formly being the big favorite. NgRx Formly is a beautiful library that allows devs to create powerful reactive forms. Rob also highly recommends the Angular Schematics library. It is a powerful low-level tool that allows you to create templates and code generators. You can even use it in conjunction with the Angular CLI to extend it or modify it for your own needs!
"Angular Web Applications with Juri Strumpflohner and Rob Wormald (Angular Core Team)" Transcript
John Lindquist: All right, I'm here with Juri and Rob so let's go ahead and introduce ourselves. Juri, let's start with you. What's your background experience with Angular, that sort of stuff.
Juri S.: Yeah, cool. My name is Juri Strumpflohner. I am actually from the north of Italy, a very small region there called South Tyrol, it's in the middle of the Alps basically. I've been doing software development professionally for around probably ten years. I started on the backend side with .Net, HP.net and also some Java. I think around six, seven years ago or something I then dove more into the front end kind of stuff because the company I was working at really wanted to create more balanced applications, more dynamic ones with JavaScript so we dove into that at that time, still jQuery, so we're really jQuery heavy. We had some kind of JavaScript and [MVZ 00:00:57] framework on top of that.
Juri S.: Then we switched over to Angular JS then later I got involved much more with Angular itself, so Angular 2 and onwards. Yeah, that's where I'm currently in. I'm doing some front end development on Angular. I'm also doing some freelance training and work with some companies. Yeah, enjoying it basically.
John Lindquist: That seems to be a very common story, the backend developers around that time of Angular 1 coming out like, well we need to build more dynamic apps and they start learning Angular. All right Rob, what's your name, where are you from?
Rob Wormald: My name is Rob Wormald. I'm a developer advocate ... No, that's not true. I'm a developer program engineer at Google on the Angular team, it's a pretty new change.
John Lindquist: Nice.
Rob Wormald: I've been here at Google for about a year and a half, almost two years now, all of that on the Angular team. Previous to that I was sort of just an independent developer. I ran a consultant shop for a little while. I've done training, I've done teaching. I actually come from really ... I guess I really originally started programming iOS kind of when the first iPhones came out and the app store came out, which is almost ten years ago now. That's kind of when I got started with programming and did some iOS stuff, did some backend stuff, learned some Java and then moved to the front end to Angular.
John Lindquist: All right. Let's just start with a broad question. Angular, the 2.0 release was a big one, had all the fanfare. Since then with the version control changes and everything I think it's up to 5.1 now. How have either of you seen Angular evolve since the major change at 2.0.
Juri S.: I think it's from a feature perspective there have been a lot of features since 2.0 but for most people at least that's what I experience also when I do workshops in companies. They see it like it went quite on like smoothly so there have been obviously new kind of features they have introduced or have introduced for me personally the biggest features are for sure the new HTTP client, also improvements in the router, but mostly the bundle size improvements. That's also what I heard a lot from people already using Angular 2 and then jumping on to Angular 4 and now 5. They really reported and it was also seen on Twitter a lot basically how much the bundle size shrank down by just basically doing nothing and then router just upgrading to Angular 5, so that's really some of the things hear most when I talk to people.
Rob Wormald: Yeah. I think we went through a fairly major evolution from 2 to 4 under the hood and I think that's been the biggest changes I've seen under the hood. As Juri said, things like HTTP client, nice little simple AVIs we've added. One of the things that we like to point out and that probably we don't point out enough is that one of the reasons it took so long for the first version of Angular 2.0 to come out was that we wanted to make sure that we got the public API right.
Rob Wormald: Since we released 2.0 we've pretty much left that public API alone but we've been able to sort of under the hood evolve how Angular works completely. We've completely changed the way that we generate code between version 2 and version 4. That really is going to be the philosophy of Angular going forward that we want to keep this public API pretty stable, not have to rewrite your own application code and then we can go back under the hood and optimize it. For me, seeing that evolution happen, and really we had to prove it to ourselves between 2 and 4 that we could do it.
Rob Wormald: I think it worked pretty well, most people were very happy with it. As Juri said, they just recompiled and saved some bundle size. I think for us being able to see that kind of silent evolution happen, if you like, is pretty cool to see and it gives us confidence to do a lot more interesting stuff in the future.
John Lindquist: I have to ask, do you have any cool under the hood stories of something that was really surprising or something that the team fought over, things like that?
Rob Wormald: I think that one of the interesting things has been that really we optimized, we kind of designed Angular. We very much optimized for what we call the update case, which is that your application is up and running and then how fast can we update records or rows or a table, whatever. That was one of the larger issues we ran into with AngularJS in the later days of it. We optimized for that, but obviously it kind of turns out that as people are moving more and more towards mobile devices and as the front end of the ecosystem shifted, it turns out that often that update performance is not always the most important metric or not the only metric that people are working on.
Rob Wormald: We continually have this tension between making it easy to use, making it small, making it fast, and they kind of go in different dimensions. It's kind of a continual, evolving discussion on our team about where do we optimize for X or Y. You only have so much you can do and so deciding which axes you want to push along. Again, that Angular 2, Angular 4 change was really that, was us kind of coming to this realization that actually probably it was better to make the code size smaller than it was to make the execution of that code faster.
John Lindquist: Interesting.
Rob Wormald: We still debate that, we still kind of slide that dial back and forth on a daily basis as we're experimenting and developing new APIs.
John Lindquist: Yeah. I can only imagine the outside voices you guys hear demanding you be pulled in one way, smaller, faster, faster execution, all those things.
Rob Wormald: Yeah. I think that we'd love to solve all of the problems but there are only so many hours in the day, there's only so many people on our team, we're not a huge team. Of course, internal teams have often different requests and different needs than the external community does. It's very interesting trying to balance these opposing forces on a daily basis, for sure.
John Lindquist: Yeah. Juri, is anything new and exciting in Angular that if people that aren't on Twitter constantly following on the conversations they might not know about? I think I saw Material got it's first official stable release and things like that.
Juri S.: Yeah. Personally, actually I have to say what me excites most about what's coming up or what's already been announced, actually Rob, I guess, announced it that Angular Connect or Angular Mix already is Angular Elements and Angular CLI schematics. Those two things which I'm actually most excited about because I think, especially Angular Elements but as well also the schematics part, they really open up a whole new world actually because if we think about ... I was last week at the conference where I gave also a talk at the NGB in Belgium and Pascal Precht actually had a talk there also on Angular Elements where he did some live coding demos which were really exciting.
Juri S.: What he actually did is he went basically and took the Angular Material radio buttons and he compiled them down using the Angular elements basically to native web components and then reused them basically on a simple HTML page and that was really cool to see and follow along because you can now really imagine, okay I like those drop-down lists from Angular Material just to name some of these or an attached component, and you could compile those down to Angular Elements and then [triage 00:08:16] on all our applications. I think that will really be some exciting stuff when that comes out. I think it's currently a lapsed product, right Rob? It's not really introduction-ready.
Rob Wormald: That project is actually something that I've been thinking about/annoying the Angular team with for probably the past 18 months or so.
Juri S.: Thanks a lot for that.
Rob Wormald: Yeah, I know. It's taken some time to get there. For me there's two parts to it. The first is obviously the re-usability factor I think is major, the first time I introduced it and every time I introduce this idea. To me it's very sad that we have to write the same datepicker in different frameworks again and again and again. We spend a lot of time, and certainly my job is being out at our customers right, seeing who's using Angular, being at big companies and seeing how they're using it.
John Lindquist: Solving the same problem over and over.
Rob Wormald: Yeah, solving the same problem again. It's kind of sad. It's something that ... And I've done it myself, I've probably written half a dozen datepickers in my career and I would like to never write a datepicker again. The Chrome team and the web community as a whole, web components have been around for a while. They've gone some evolution and I thin some of the latest evolutions of web components are why we're beginning to look at them, it opens up some things that have been Angular to use web components before.
John Lindquist: Such as what? I haven't followed the web components.
Rob Wormald: One of them is ... Custom Elements went through ... They had this kind of V0 spec and this V1 spec. They're kind of functioning the same but they give us ... In terms of understanding what's going on at the component level, observing attributes changing and some tweaks to the way that life cycles work. Also the ability to actually create a custom element just by calling new on the constructor is not something we could do previously, so that's useful for us. Really the other thing, kind of the Shadow DOM API catching up as well, that introduces Slots and a bunch of thing that Angular sort of already does. Slots are very much like content rejection or transclusion.
Rob Wormald: The observed attributes on Custom Element are very much like Angular's inputs. The latest specs really align very closely with the Angular model and so it makes it reasonably straightforward to actually make elements a thing. That's the interesting thing of elements is that really the whole code base is maybe 200 lines of code, 250 lines of code. It's not a major thing, all we're really doing is bridging this native world to the Angular APIs. Angular was always built with this in mind. The early phase of API was baked around this idea so it's made it reasonably straightforward to actually close the loop so that Angular Component can just be sort of a custom element.
John Lindquist: I think you guys are one of the last remaining champions of the web component ideas.
Rob Wormald: Yeah. Certainly I think we were involved in the early design phases. Some of the opinions differ and really, to be honest with you, a year ago it was a much harder sell with web components not being in most browsers. Now that Safari has picked them up and Chrome has already implemented them. Firefox is in the process of implementing, we hope Edge is doing the same thing. We're sort of pitting this critical mass where they're available in enough places, there's enough companies who have this problem and so for us it seems like it's time to do it.
Rob Wormald: I should say that even internally at Google we have the same issue where we have teams who want to share code, we have a few internal frameworks here at Google and they have the same thing that they don't want to be reinventing the wheel. For Angular to become, if you like, the kind of tool for building those kind of sharable components we think is a pretty compelling idea.
Juri S.: Yeah. I think it's really powerful because, for instance, we had at the company where I was working we developed an AngularJS application at the time which was basically like on top of open layers, we developed some kind of geographical information system, which was like blocked in and could add some stuff on those maps if we capture it. Our idea was actually you had the full-blown application, which was an Angular application with some tools on it like drawing on a map and setting layers and so on, basically some configuration. But you also really wanted to give the opportunity basically to take that map and embed it with some more kind of our applications and just through some configurations like some inputs of the components basically to steer that configuration so that we know what the map should show on that page.
Juri S.: We at that time did it actually with AngularJS and that was really a hard thing because internally we structured it already using the components style of fashion like component architecture and the map was really also in the main application nicely basically separated from the whole rest of the application just steered through those input parameters but obviously in Angular 1 extracting such a component and then have it like a standalone into another page was really difficult.
Juri S.: Also, we actually ignored basically the problem what would happen if another AngularJS application would actually run on that page because that would probably have messed up everything. But now actually having these kind of elements coming along that would really solve that problem actually because people can develop their applications just as they are normally accustomed and they don't really have to know all the details which are behind the web components and that kind of stuff, and then just compile them down to single components, compile them out into reusable web components basically. That's actually why I'm really excited about that kind of stuff.
Rob Wormald: One of the cool things has been since we announced that we were looking into this and we've got in labs is that I've had, I don't know, a dozen, a couple dozen companies contact me with really interesting cases. This mapping one is actually one that comes up fairly reasonably often.
Juri S.: Yeah, I can imagine.
Rob Wormald: That's pretty validating to hear that there are lots of teams who when we presented here's this possibility they said, "Oh yeah, we've been trying to do that for a while."
Juri S.: Exactly.
Rob Wormald: It's something that's going to be quite useful for our community and we hope as well that it brings in people from outside the Angular community because the other part of it is that it allows you to think about just Angular components as kind of a standalone thing, and then if and when you need the rest of Angular, routing and HTTP and all these cool things, then we have that available for you. But certainly the ability to use a component as a component by itself, again makes Angular much more flexible, makes it much more useful in a lot of different scenarios.
Juri S.: Yeah, totally.
John Lindquist: Yeah. I think for a lot of people it's one of those things they don't know they want it because it has that kind of taste to it where once you see it you're like, oh wait a second, I've been looking for that solution but I didn't know that it was even possible.
Rob Wormald: Yeah.
John Lindquist: All right. Juri, question for you. You've done a lot of trainings and speaking at conferences. Since Angular 2 has come out have you seen people as they pick up Angular 2 struggle with certain aspects of it and do you have any advice for people who have had those sorts of issues?
Juri S.: I think initially it was definitely tooling because many people when I started the workshops they were really afraid because right now, I have to say that as well, I did mostly workshops for people which really started in front end development and they wanted to start with Angular 2 directly because they mostly came from backend sites, so .Net and Java were those cases which I had most right now. They were really scared first of all about JavaScript in general because they were like, okay it's a dynamic language and you don't know. They were accustomed to the static type language and when you introduce them to types that they really feel immediately at home, so that's a big plus actually.
John Lindquist: Yeah, for sure.
Juri S.: I usually also show them quite quickly the Angular CLI. I get them set up already with the product, I tell them too, I make them install it, so they install it on their machine and they start basically playing around with it and they already immediately see something on the screen and can work with it. With that basically ... For me it's like an icebreaker to get ready to work because they then see, okay it works, I'm already able to accomplish some stuff, and so they're quite happy. But in general I think once they get basics, what I often see is basically they struggle with architectural patterns, like how do I componentize my application, because that's often a pattern which they don't really know from the backend side because they are mostly ... Okay, you've got some REST APIs and you have to always structure applications.
Rob Wormald: Service oriented.
Juri S.: Yeah, exactly. It's more service oriented and that kind of thing and when you come to the front end you really have to think about how do I divide my application? Do I have different kind of modules, especially when you kick in a new router and kind of stuff. That's where they mostly struggle. I mostly try to explain to them the difference, like how should they split up the front end side, like in container components, presentation components, so that somehow they get some kind of picture in their brains, okay these kind of components should solve these kind of problems and the other kind of components, like the presentation components, would be more like UI components which I can reuse across my application.
Juri S.: I try to basically give them these directions and input. And then obviously there's NgRx as another way of structuring applications, but that's something actually I have not brought up yet because, as I said, mostly those kind of workshops have been for beginners, or let's say mid-advanced, so not really advanced. And then NgRx, if I give them an introduction it's mostly on a high level because that's usually a bit overvaluing for them initially. But I think there's actually a lot of potential in there so once you really get a grasp on how Angular works or in general how you should structure applications, NgRx can really help you there.
John Lindquist: I think what you described is what I've seen as well where I found Angular to be probably one of the most opinionated frameworks on how components should be written and modules organized and how you rate your services and dependency injection with those and everything. Once you get the hang of where everything goes you kind of get in that groove of, well this is a component and this is a service and register it here. You just kind of get your work done. It can be so nice to have those guidelines, especially with TypeScript in the game, the errors start disappearing and you just get productive.
Juri S.: Yeah. That's really something actually which people like a lot, I've seen.
John Lindquist: Yeah. Nice error messages. I think we undervalue how pleasant it can be to get a good error.
Juri S.: Yeah.
John Lindquist: I love a great error, a great descriptive error and it's always an afterthought on so many things. How about you Rob, what's your most frequently asked question recently from your many journeys?
Rob Wormald: I think probably at the long-term one of the more challenging things for people has been kind of Angular's compiler metadata AOT kind of story. Again, we've got this compiler in the middle and we have a lot of really good reasons for this compiler and this ability to evolve the framework. It's kind of a first class important system for us. But it can be rather opaque. There are these rules that are sometimes a little bit esoteric and, again, it's one of those things that if you understand the mechanisms then it's reasonably straightforward to work around some of these issues, but again it's one of those things that, as John said, if you don't have good error messages, if you don't have the mental model in your brain, then it can be difficult to debug, it can be difficult to understand how it works.
Rob Wormald: Angular is unique from many JavaScript frameworks in that we have this compiler, your code goes to this kind of magical, invisible step and that can be kind of intimidating for people, that can be sort of confusing for people, especially if it's something that you're adding in later in the game that can be challenging. I think we've heard that feedback fairly well. A lot of the stuff we're working on at the moment is trying to make that easier, trying to make that a little bit more forgiving, a little bit easier to share code.
Rob Wormald: The other thing is our application architecture. It's funny that people don't really remember that in the AngularJS days we never really gave any guidance on best practices. We didn't really have that on the Angular website.
John Lindquist: NG controllers all the way down.
Rob Wormald: Exactly, right. And certainly ...
John Lindquist: That's just what you did.
Rob Wormald: Totally.
John Lindquist: You got on the homepage and you just go to NG controllers and one giant HTML file.
Rob Wormald: I think really as a ... Before I joined the Angular team I think many Angular developers, and what I mean is people who have used Angular for a while, would have told you that AngularJS docs are probably not the thing you should be reading. John Papa's style guide and all this other really good information the community built for AngularJS is really the primary point of reference. When we went to Angular 2 we wanted to be sure that we thought about this and we gave you some better guidelines, we gave some better ideas on this.
Rob Wormald: Again, this is something that evolves. NgRx is kind of a late entry to the Angular ecosystem and so that's not really discussed in the documentation about how to think about things like NgRx. Really I think we've got a pretty good set of documentation on how to get started with Angular, how to get your head around these concepts, but I think that we can do a better job and it's something that we increasingly want to look into of teaching you about true application architecture, how you should think about these things, trying to take, again, some of that decision overhead away from you.
Rob Wormald: Again, a lot of that comes from feedback from teams internally, teams externally, who are really using Angular much more than we are. That's almost the thing to keep in mind is that while we write the framework we're typically not writing big apps like our teams are so we rely on a lot of this feedback from teams to know what's working, what's not working, what we could be clearer on and that's the thing that I think we certainly want to continue doing to meet these other people.
John Lindquist: Yeah, totally. Juri, what sort of Angular libraries ... I watched your courses which are coming out pretty soon. I saw you use NGX formally in your forms lessons. Are there any other libraries that Angular developers should know about that have come out recently or that you've been using or that you would advocate for?
Juri S.: Yeah. NG ... Actually there are quite a lot of libraries out there to be honest.
John Lindquist: I know the NARWHL guys are doing stuff.
Juri S.: Yeah, exactly. NGX formerly was one I actually mentioned in one of my courses, as you said. It wasn't a course where I actually tried to teach how you can do dynamic forms in Angular because I think in Angular 2 or Angular 4 and onwards it has been made actually very easy to do that kind of thing. Reactive forms are really powerful and just today in the workshop I also gave people who did some live coding about an hour or an hour and a half, together in the workshop where we started with a simple reactive form and then we step by step basically, as I showed basically in that video course on iCAD, we incremented that kind of four-week standard and made it more dynamic so in the end we actually had a singular Angular component where we could patch in a data model which obviously had a different, a certain kind of structure and then then basically change itself automatically without actually changing HTML part and the whole random part with also supportive validation and that kind of stuff.
Juri S.: Obviously we did not cover all cases but that really is interesting to see how people, when they approach a problem they're really like, wow that's a cool kind of thing because you can change the HTML actually and form just the DOTs. NGX Formly is actually something that implements that kind of thing. I think in Angular 1 there was already Angular Formly, if I'm not wrong, which [crosstalk 00:24:08]
Rob Wormald: [crosstalk 00:24:08]
Juri S.: Exactly, by [inaudible 00:24:10] dots. NGX Formly is actually an extension for Angular 2 so to code that idea from Angular Formly, so reliably from Angular 1 to X and brought it over with Reactive Forms for Angular. Yeah, that's the library. If you're interesting in having dynamic forms because your backend API has some fields, some models which like the user could effectively design or configure, then you'd definitely need some dynamic behavior in creating those forms and editing those kind of data. There Angular Formly or NGX Formly is definitely what you should look at.
John Lindquist: I have a good friend who is a huge advocate of React and will build absolutely everything in React, but he says as soon as a site gets form-heavy I will automatically switch to Angular Reactive Forms.
Juri S.: Yeah, they're really powerful.
John Lindquist: Because it's just the best. If you're doing anything form-heavy in any of your sites, the reactive forms in Angular are one of the best things on the internet right now.
Juri S.: We basically ...
Rob Wormald: I think we're finding that ... We have both of these forms APIs, we have this Reactive Form and we have this more traditional AngularJS style form. I think that one of the interesting things about Angular's Reactive APIs is they really came later in the design phase of Angular. People like Victor Savkin joined the team and then I joined the team and people who are really, really deeply into this reactive programming stuff. I think we're finding that in some cases it is more confusing for people, there's some mental overhead to learn Rx, but we also find that this kind of reactive API, if you can understand how it works then a lot of things in Angular really link together very well. I mean the ability to take out a reactive form and plug it into a reactive HTP request, then plug that into the view and have all that stuff work nice and seamlessly is pretty cool but also something that we, if you like, have only recently discovered as a thing.
Rob Wormald: Increasingly we've decided that it works better for Angular developers, we find that it's a faster way to do things, it's an easier way to maintain things and I think you'll find that we optimized Angular in general going forward for the sort of reactive case because reactive forms, people tend to love them and we think that if that's the model that people tend to like, that's the one we should optimize for. Whereas right now a lot of the reactive APIs, if you like, are kind of pasted on top of some of the poorer APIs and I think you'll see us invert that over time with the reactive stuff at the core and the traditional stuff becomes layered on top of it.
John Lindquist: Cool. Yeah, I kind of get that feeling with the Angular forms with the reactive forms have this beautiful story kind of written that feels like it's reactive first and, like you mentioned, some other parts are reactive second.
Rob Wormald: I think as we've been designing things like the data table and material and and the tree views, we keep using this API that is very much reactive based and it turns out that it works in all kinds of different places. It's really quite cool to see these really common patterns emerge from both the Angular community, the Rx community, other framers who are using Rx to kind of see those emerge and that they're working for people will continue to optimize for that case.
John Lindquist: Awesome. Any other libraries, other than Formly libraries, that people should know about?
Rob Wormald: I think the one that everybody should check out is our new schematics library. One of the big requests we get is: I want to do custom code generation and I want to be able to extend the Angular CLI. Schematics, they are actually the mechanism we use inside of the CLI to generate new projects and components and all these things, but they're designed to be very, very flexible and very extensible. One of the common cases we talk about is you might go to a team and they might have a slightly different set of style guidelines or they might want to have the copyright notice at the top of every file like we do at Google.
Rob Wormald: Really the idea of schematics is that you can take our base set of generators and override them and make them custom to your own case, to your own company, to your own organization and then allow you to really build a set of tools that allow you to generate and move very quickly on your own application code. This is actually how the NARWHL Nx project works, they're using schematics under the hood. We're working on a schematics integration for NgRx right now so you're going to be able to generate some of the boilerplate form use so you don't have to write out actions and introducers line by line.
Rob Wormald: Schematics is a very low-level but very, very powerful kind of cogeneration tool. That, we think, is going to be pretty major and again there's nothing Angular-specific about it, it's not restricted to Angular at all so we hope that it becomes a usable tool for the entire web ecosystem.
John Lindquist: Is the feel there ... Sorry, I haven't looked into the schematics at all. Is the feel there that you're still using the Angular CLI and then you're writing a template that extends the current template?
Rob Wormald: Yeah, you can do that. Part of the ... There is an option when you go to CLI config to just say use this set of schematics instead when it does code gen, so when you do NG create component or whatever it can actually create your own custom flavored version of that, but you can use it as a standalone tool as well so you can just run schematics by itself outside of the CLI for other cases. One of the good cases that somebody talked me to the other day about was using schematics to read in their backend database schema and API and then actually use that to do code generation of TypeScript so they're kind of generating their API client with backend information.
Rob Wormald: That's the kind of thing that schematics, I hope, becomes more and more useful to people. Stuff like Swagger, where you have this kind of machine readable schema for the server side, it's really pretty straightforward to kind of ingest that and then generate TypeScript code for that or generate API clients or whatever you want to do.
Juri S.: Nice. In fact, I've seen Manfred Steyer also wrote in Angular schematics where he basically scaffolds out a crowd application for Angular. I'm not sure basically whether he checks the backend or whether it's something like you have to tell the schematics which kind of entities to generate and so on, but that would be actually a really cool idea to hook up with some Swagger API, as you said, would be really nice.
Rob Wormald: Yeah. It's sounds like something that we ... This is one of the cool things that TypeScripts will give us is because it's such a static [inaudible 00:30:23] language we can do very clever things with it and code gen. I think we're really only scratching the surface of some of the integration stuff that we can do, which we ... That's the front and the backend, various different teams, all this stuff. We have these problems at Google, we have these big scale issues at Google. We have teams who build, if you like, the kind of boilerplates for other teams at Google and so those sorts of teams we really want to give a powerful set of tools to allow everybody that consumes their work to be equally sufficient.
John Lindquist: On the topic of TypeScript, this is kind of a tangent but have you seen anything added to TypeScript that really helped out Angular or vice versa or anything coming up in TypeScript that either of you are excited about.
Rob Wormald: Certainly a lot of the new type inference stuff has made ... The two things that I think have been really affected more than Angular itself are the RxJS libraries, a lot of the new type information makes RxJS work a lot better, especially if you're into the more kind of functional style of using RxJS or rather than dot chain syntax, being able to do composition and [creating 00:31:27] and piping and all of that. A lot of that was really enabled by some new changes in TypeScript 2.4 and 2.5. That one's fun because Ben Lesh actually put up a test case and Anders Helberg from the Microsoft team fixed it in the night. It was really cool and it really opened up a whole bunch of new, really much better type inference inside of Rx. Of course, NgRx gets that benefit too. We rejiggered some of NgRx to make sure that type information flows through better.
Rob Wormald: The other thing I think is dynamic import coming in that I think will be very, very interesting. That's just landed at TypeScript, we're just seeing it land in Chrome and I think that will ... Having kind of a baked-in, lazy loading mechanism in the language will make a lot of what we do a lot easier, it will make a lot of the kind of dynamic cases that people want to build in Angular easier.
John Lindquist: Does that mean SystemJS goes away?
Rob Wormald: In theory, yes. SystemJS was always kind of developed to mimic the native API as much as possible.
John Lindquist: Right.
Rob Wormald: In theory that's the kind of working theory. There's a lot of gotchas and edge cases and things for people to really start using ES6 modules in Angular, the big one being that nobody has written .js on an important for two and a half years, three years, in any language in anything. That's going to be required to run another browser. Yeah, it's certainly ... I guess the thing is for me what that really enables is rather than having to use a Webpack specific idiom, which we don't think is a good idea. We love Webpack, we don't think you should have Webpack in your code.
Rob Wormald: We have a bunch of abstraction in there and inside the CLI to make all that work and that's code that we have to maintain. Having a really baked in language primitive for lazy loading of code will make everybody's jobs a lot easier, it makes your code a lot more long-term safe and takes a lot of the onus off of Webpack so that you don't have to use Webpack specific idioms in your code.
Juri S.: That's something that is just about to be released? Did I get you right on that? Because I didn't get look into this.
Rob Wormald: Yeah. I believe it is in Chrome Canary, it's already in Safari Technical Preview. It's all ratified and seems to be good to go. TypeScript already supports it, Webpack already supports it. Again, it's that ... You can start using the syntax today and then if and when the browser specialty lands that then you can maybe one day turn off Webpack.
Juri S.: Yeah, for sure.
Rob Wormald: But we don't see that happening in the near future but certainly it's nice to be able to write code that you know you're not going to have to go and rewrite at some point in the future.
John Lindquist: Yeah. It's always weird when those features actually do release in browsers, like when classes finally came or arrow functions. You open up the Chrome console and start using it and like, wait a second.
Juri S.: It just works.
Rob Wormald: I took an Angular app the other day and I manually built everything from the ES6 so all of our source code is written in TypeScript. I had to do some hacks and I had to go manually rename some things. But to have an Angular application running pure ES6, pure ES6 modules using ES6 module loading in the browser, using dynamic loading in Safari was really super cool. Just to see it work and to see it in this kind of untransformed kind of form was really validating. I think it's going to be cool if and when we can get to a point where everybody can do that.
John Lindquist: Yeah. It's almost like this prophecy is being fulfilled.
Rob Wormald: I'm like oh my God, this is [crosstalk 00:34:50]
John Lindquist: A long time ago a wise woman once said this and like, yay these are finally here.
Rob Wormald: I have to say, in the defense of the people who run these specs there was a lot of blow back early on that they sort of figured out how to write modules but not how to load them. There's been such a shift in a couple of years about how we think about loading code and the lazy loading is such an important thing. I think they got it right, getting the stack out there so that people could begin to write code. It's not going to bite too many people in terms of having to actually use the native syntax. I think they got that right and yet it's nice to see these things finally begin to actually land in the browser area.
John Lindquist: Yeah, for sure. All right. I'll toss one last question out there. Any other tools or ID extensions or things you guys are using for productivity that you think everyone should know about?
Rob Wormald: I think Stackblitz, if you haven't seen it, is rad. Stackblitz was the thing I [shut down 00:35:45] in the office and literally the entire Angular team stopped what they were doing for 20 minutes and played with Stackblitz.
Juri S.: Yeah, I think this is really cool.
Rob Wormald: [crosstalk 00:35:52] We have a bunch of really smart nerds who have their own opinions but everybody was universally impressed with Stackblitz. It does Angular, it does React, it does Iconic. I think that actually Stackblitz for me, it was that same kind of thing of seeing, oh this is what web dev could be like. I've said to the guy who runs Plunker for a while, if I could give you 25 bucks a month for Plunker Pro and I never had to have a local installed IP then I would do that. Stackblitz is in the same kind of fashion. Being able to do this web-based development where you don't really have to worry about tooling so much, you just get to start writing code, I think is mega.
Rob Wormald: The thing that actually inside of Google we have this cloud-based editor that's not all that indistinct from how Stackblitz works and really there's a fair portion of internal development at Google that happens using that cloud IDE. To have that as a real thing I think is pretty cool so I hope that Stackblitz and things like Stackblitz become more and more prevalent because the barrier to entry for people, the difference between ... We do a lot of work to make sure that Angular is easy to use, to make sure that the CLI does everything you need it to do, but it's still the difference between going to a website versus having to read a bunch of instructions on how to do NPM and all these other things. With one click I'm in and I'm immediately productive is as very, very powerful thing, so much that we're actually switching Angular's documentation over to use Stackblitz.
John Lindquist: Oh, cool.
Juri S.: Yeah. For me, Stackblitz has really made it easy to do workshops because I had usually the slides where I would explain some kind of topics and then I had a kind of demo link on there directly on the slides especially as a reference material for the attendees afterwards and usually initially obviously I had their Plunkers linked. It was kind of weird because you explain to them the whole stuff and how Angular works, how it loads up, and then they see SystemJS inside those Plunkers and it was always kind of a shift you nearly had to explain then that as well.
John Lindquist: Yeah.
Juri S.: Now I simply embed some Stackblitz links, they can play around with that and they can even download it, so that's the most cool thing I think because they can download it, it's a fully computed Angular CLI application already so they can just use their local Angular CLI and boot it up and it works just as in the browser so that's really, really cool.
Rob Wormald: Yeah.
John Lindquist: We live in exciting times.
Juri S.: Yeah.
John Lindquist: Closing thoughts from either of you?
Rob Wormald: Yeah. I think from our end we are pretty stoked to see ... We hit a million monthly active users on Angular's website for the first time.
John Lindquist: Oh nice. Congrats.
Juri S.: [crosstalk 00:38:16]
Rob Wormald: That's a big milestone for us and so we're super stoked that the community is not giving up on us. I say this fairly often, that we very much feel like we are only just getting started. There is a lot of really, really cool stuff coming down the pipeline. I think that we more or less kind of built Angular's public API the way we like it and now a lot of what we're doing is based on feedback we're getting from developers, these new use cases. For us I think the next couple of years of Angular will be very, very exciting.
Rob Wormald: Again, we're not going to change Angular for everybody. You will be able to continue to use Angular in the way that you use Angular today, that's the guarantee that we're making, but certainly we want to begin to open the doors to a whole variety of different use cases, a whole variety of different skill levels and backgrounds and all these different things. Certainly from our perspective, stay tuned.
John Lindquist: Great. Juri and Rob, thanks for all you do in the community.
Rob Wormald: Same to you. I don't think we would be where we are without Egghead and the coursework that you guys do, so thank you.
John Lindquist: All right. Happy holidays.