039 AiA ES6 with Scott Moss
00:43 - Scott Moss Introduction
01:55 - Scott’s Programming Background
04:11 - Working with Lukas
05:04 - Angular and ES6 (ECMAScript)
06:11 - Subclassing a Directive
- Classical Inheritance
- DDO (Directive Definition Object)
08:58 - TypeScript
- Transpiling
- Differences and Definitions: traceur, babel, TypeScript
- Types Have Value
19:06 - How should people use a transpiler in a real application?
21:07 - systemjs
21:53 - Build Systems vs Package Managers
24:15 - Writing Tests in ES6
26:03 - Debugging
28:20 - How coding in ES6 has changed Scott’s style of building Angular 1 apps
30:19 - Modularity
- Arrow Functions
33:07 - ES5 with Angular 2??
37:31 - Good Example of Using ES6 with Angular
- GoCardless
- GoCardless Angular Style Guide 39:21 - Learning New Material and Using ES6Picks
Learn about TypeScript 1.5 (Ward)The Effective Engineer by Edmond Lau (Lukas)Isar Raw Canvas Backpack (Lukas)INcontroL (Joe) John’s Daughter (John)Angular U (John)The Imitation Game (Katya)Treeline (Scott)Interstellar (Scott)
Transcript
JOHN: What are we doing? Like a podcast in the basement now? Living with mom? [Laughter] [Does your team need to master AngularJS? Oasis Digital offers Angular Boot Camp, a three-day, in-person workshop class for individuals or teams. Bring us to your site or send developers to ours -- AngularBootCamp.com.]**[This episode is sponsored by Wijmo 5, a brand new generation of JavaScript Controls. A pretty amazing line of HTML5 and JavaScript products for enterprise application development, Wijmo 5 leverages ECMAScript 5 and each control ships with AngularJS directives. Check out the faster, lighter and more mobile Wijmo 5.]****[This episode is sponsored by Digital Ocean. Digital Ocean is the provider I use to host all of my creations. All the shows are hosted there, along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent. And their VPSes are backed on solid-state drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code “angularadventures”, you'll get a $10 credit!]**CHUCK: Hey, everybody! Welcome to Episode 39 of Adventures in Angular Show. This week our panel, we have Lukas Reubbelke. LUKAS:[High-pitched voice] Hello! [Laughter]CHUCK: Katya Eames. KATYA: Hello. CHUCK: Joe Eames. JOE: Hey, everybody. CHUCK: John Papa. JOHN: Hey, there. CHUCK: Ward Bell. WARD: Hello there. CHUCK: And I'm Charles Max Wood from devchat.tv. We also have a special guest this week, and that’s Scott Moss. SCOTT: What's up, y’all. CHUCK: I'm so relieved to have somebody on the show whose name I can pronounce. SCOTT:[Chuckles]CHUCK: Do you wanna introduce yourself real quick? JOHN: Hey, what about us? You can’t pronounce our names? CHUCK: I had to practice with your names. LUKAS: It's actually pronounced “Skōt.” CHUCK:[Chuckles]JOE: It’s quite a dichotomy between Lukas’ “hey” and Scott’s “hey.” SCOTT: [Chuckles]JOE: [inaudible] contrast there.**LUKAS: Don't judge. CHUCK: Anyway, do you wanna give us an introduction -- let us know who you are? SCOTT: Yeah. I'm the Senior Frontend Engineer at Udacity over at Mountain View, California – with Lukas, actually. Although he lives in Austin, Arizona. So I'm Senior Engineer there. Before doing that, I was an instructor and engineer at Hack Reactor, which is a nice coding school in San Francisco, where they focus on like full-stack JavaScript stuff. And before that, I was in the Navy, where I did all types of stuff -- not programmer related. So besides doing all that, in my spare time, I'm running angularclass.com, which is a site for Angular training workshops and corporate training and maybe we'll get a consultancy. I also do a lot of volunteering; a lot of Meetups, conferences, and other miscellaneous workshops. I'm also doing instruction on Egghead and Frontend Masters. And I'm in the middle of writing a book. CHUCK: So not busy at all, right? SCOTT: Not busy at all! CHUCK: And, by the way, thank you for your service. LUKAS: Scott, could you take just a few minutes and just kind of tell us about how you got into programming and kind of where you came from, and how you got to this point? I think it's such a phenomenal story. And anybody who's not familiar with it, I think we'd be doing them a disservice by not giving them the opportunity to hear the story. SCOTT:**Yeah. So, how I got into programming. So I was in the Navy. I had a five-year contract, and I was finishing up the last year. And I was informed that I was going to be discharged, so I made a conscious decision that once I get out, I wanted to do something that I really like -- something that I was talented at. I was talented at basketball, so I was like, well, I can go overseas to play basketball with my sister. But I really liked the idea of programming and software and technology – although I didn’t really know much about it. So I chose that. Literally a week after I got out, me and my younger brother, we were in San Diego at the time; we packed all of our stuff, put it in my car and we drove it to San Francisco -- no money, nowhere to live. And we lived in my car. And we would wake up every morning, we'd just take our computers and go to like cafes – Starbucks and stuff – and just like get on websites and teach ourselves to program. We did that for a few weeks. And we loved it. It was like the best thing for us. I wasn't happier. I had nothing to complain about. I don't think I took a shower for like a month during that time [chuckles] but it was just awesome. Like the people that I met at the cafes and like being in that environment of Silicon Valley and everybody is like always doing stuff. It was really amazing. So I did that, and I got good enough to actually get into Hack Reactor. After completing the program as a student, I got hired as intern, where I like worked on interviewing every single applicant that came through Hack Reactor. So I learned a lot of practices when interviewing people. After I did that for three months, they hired me on as an engineer and as an instructor. So I was in charge of building some of the curriculum and then delivering it. And I also worked in some engineering stuff. So my background is kind of crazy. It's definitely not traditional. I never went to college. I barely graduated high school. And growing up, I lived in a hotel room with me and seven brothers and sisters for a long time. It was pretty rough, but I think that kind of lead me where I am now, where I made the conscious decision that I didn’t wanna live like that anymore. And that I was going to do something that I enjoy.JOE: That's awesome and inspiring. LUKAS: I'm misty. I've just got tears in my eyes right now. JOE:[Chuckles] How long have you've been working with Lukas?SCOTT: I've been working with Lukas for like two to three months now. Right, Lukas? LUKAS: Yup. SCOTT: Yeah, so I met Lukas when I actually came on board Udacity. Like, yeah, we got this other guy, he's in Arizona. And I was like, “Okay, who's this guy?” and I was like, “Oh, it's that guy! I know him.” LUKAS:“That guy.” [Laughter]SCOTT: “I know him.” Immediately, I felt just so proud to be where I was, because I get to work with somebody so awesome, so… LUKAS: Aww. SCOTT: It was just love at first sight. Me and Lukas, we just clicked. LUKAS: So we're like the Miami Vice of programming, by the way. CHUCK:[Chuckles]JOE:[Chuckles] I was going to say, I would think that after working with Lukas would make seven people in a hotel room seem not so bad. [Laughter]**LUKAS:**And I don't shower either – for like a month. [Laughter]LUKAS: Ward and John are like the odd couple and Scott and I are like Miami Vice. CHUCK:[Chuckles] All right. So should I derail us back to ES6 now?**LUKAS: Yeah. Sorry. Let’s just get back on track there. Take it away, Chuck. SCOTT: When it comes to Angular and ES6, before I actually got involved, I was actually pairing these two technologies together, there's just like some things that you actually don't think about before you actually start developing with these things. So some of the concerns that actually came up when I actually start using these technologies, were like, I think the biggest thing for me was this really nice community of all these great style guides out there. John Papa’s got a great style guide. But then when you mix that in to like using something like ES6 modules, things can get crazy – I mean really crazy. It took me maybe a week to really find a good pattern that worked. So it kind of gets crazy there. And then you start thinking about when it comes to testing, you're like, “Well, I now have this class syntax where maybe I can test my JavaScript separately from Angular now, but have Angular still consume my classes for controllers or directives,” and stuff like that. It opens up a lot more opportunities for things. For instance, you can start subclassing your directives and stuff – which I don't think a lot of people have done before. You never think about that stuff until you start getting involved, but there's so many ways to do one thing now because of all these new features, that it can get kind of crazy. CHUCK: Can I pounce on that “sub classing directives” and stuff for a minute? I mean, everybody who has a computer science background at least is familiar with the idea of classical inheritance. But they all work a little bit differently; you know, Java’s work a little bit differently from Ruby’s which works a little differently from C#. So when you subclass a directive in JavaScript or in Angular, what exactly do you get or don't get? I mean, is it just copying the prototype over like we're used to, or is it something else? SCOTT: Good question. It's a little different when you're talking about directives. So if you think about a directive, if you're doing where you're like making a directive where you're actually returning a DDO or Directive Definition Object, then you could think, “Wait, this is obviously going to be an object. I can have this be like an instantiable or a like newable function.” If you think about it like that, that now what you can do is -- and especially if you're going down the component approach of Angular where everything is a component – then this totally makes sense. Whereas now, you can have these container components which are just like these newable functions. For instance, let's say you have a tab type component and it has many tabs inside of it and they are also components. Now you can have this tab component which is a newable function and then you could set it’s template, you can set its controller, you can set its scope and all that stuff. And then when you make a new tab instance, you can just make a new constructor that just inherits some of those defaults; maybe it will inherit the controllers so it sets up their relationship; maybe they inherit the same API and stuff like that. So then now, all you have to do is when you want to make a new directive, you just say, “I just want to make a new tab child,” or whatever. And it's a lot easier than having to redefine an entire directive definition object again. And then now, you can actually test that directive’s definition without bringing Angular in. You can just like grab that function and test it and inspect its property and see what it is. LUKAS: The interesting thing about that I think is the Angular team, for a long time, has been of the opinion that everything should not actually be Angular. And I remember the first ng-conf, I believe it was Igor who actually said “Hey, if you're going to build the component, just do it in JavaScript,” or some kind of UI. Do it in JavaScript and then wrap it in Angular. And so I think one of the reasons why I really like Angular as a whole and their mindset of “everything should not be Angular but use Angular where it's appropriate. But then use JavaScript or the DOM, or these different kind of native things that come with the browser where appropriate and if possible. And so now, I think with Angular 2 or ES6 is it makes it a lot easier to kind of separate that out, which creates some really incredible opportunities in terms of Isomorphic JavaScript and different things like that. SCOTT: Yeah, I totally agree. That definitely makes some more sense – for me at least. It just shows the part of Angular part of Angular like, yeah, you know, you can create an application outside of our context and architecture and completely bring it in. It's just really smooth. CHUCK: We keep hearing about using TypeScript after ng-Conf; using TypeScript on top of ES6 for Angular 2.0. Is the story different for Angular 1.0? SCOTT: I've actually asked myself of that question a lot too. So the thing about TypeScript, so right now, TypeScript doesn’t have or some of the important features that ES6 has, for instance like the module loading. I know 1.5 in TypeScript, they are going to introduce that and it's going to be awesome. But it does have the type checking, which is great. So what I did, I decided to just use ES6 because first of all, it's going to be native and most browsers are done building features on it. It's here. They are just implementing it now. So I decided to go with that. And also, I do a lot of Node development. And I like the fact that I'm actually using the same on both sides. So if I'm building some full stack application, I'm using ES6 on the back with io or Node and then on the front end, I'm using ES6 with Angular. To me, it just brings a little more consistency, but you wouldn't be wrong if you wanted to use TypeScript with Angular 1.x right now, but you wouldn’t get all the features that are Angular 2 and TypeScript 1.5 would have. JOE: So I think one of the things that's interesting about using ES6 today is the fact that unless you are doing a subset of ES6, and you're targeting a very specific browser, then you really have to transpile. SCOTT: Yeah, you have to. JOE: So then the problem becomes all right, I wanna transpile, obviously I don't wanna transpile in the browser because I don't wanna put that extra load on the browser.” SCOTT: Yeah. JOE: You certainly can -- you can transpile on the browser -- but it's just extra work and load that you really don't need. Some people like transpiling on the server side. Well, where does that ever end? When will we reach a critical mass where people will be like… you know, we can certainly be in a situation where the browser support, the vast majority of ES6 but we're still all transpiling 100% of our code into ES5 at compile time, build time. SCOTT:**Right. Yeah, you know, that’s a good question. And I don't know if that will ever be the case, because if you look at some of the transpilers out there, the two most popular: Traceur and babel. Traceur has a runtime that you’d have to use in order to do this stuff. Babel actually doesn’t have a runtime. They have a whole bunch of optional polyfills instead. But then, if you look at all those extra [?] minimal features like es7, maybe you wanna use object.observe or you wanna use the array stuff that that’s going on. When you think about that stuff, it's like, even if ES6 was native in most browsers, like you said, we're still going to be transpiling everything because we're always going to using something that is not available -- at least I know I am. I'm just so in love great comprehension that they're using CoffeeScript for so long. I would never not wanna use that. So I don't know if it ever gets to that case. So that just means that transpilers are just going to have to get better. And they are. So you know, babel changed their name from six to five, because they realized that this is not just going to be a transpiler from ES6 to ES5, but something completely more. And for that, a lot of people who use React use Babel, because Traceur isn’t compatible with ES6 and React; but babel is because they are making the push to make sure that they can use their tooling on a wider range of technologies. So I think that transpilers are just going to have to get better because I don't think they are going to go anywhere.JOHN: Well, it might be worth just taking a moment to talk about for people who haven't heard some of these terms, you know, and the difference between babel and Traceur and TypeScript and you know, so Scott, do you wanna kind of go down why you use what you use and kind of what the basic differences are? SCOTT: So when it comes down to actually ES6 code, and like I said, you probably won’t use a transpiler. And a transpiler is just a tool that converts your ES6 code down to something that can be readable in an environment like browser down to ES5. So the main two ones are Traceur and babel. Traceur is built by Google. It uses a runtime that actually compiles your ES6 down to ES5 in the browser. Babel is open source built by some other third party. And they do the same thing, but they do it completely different; so instead of using your runtime in the browser, they use optional polyfills. And the output of the code is actually more readable. It's more closer to what a human would write. Whereas the output of Traceur definitely looks like machine wrote it. I don't think you could go and look at Traceur’s compile code and like understand what's going on. JOE: It actually looks like something that doctor evil wrote. SCOTT:[Chuckles]**JOHN:**Yeah. I tell you, every time I run Traceur and I see the output, I look at it and go “Is it really doing that or is this just a [joke?]?” [Laughter]**JOHN: It's that awful. It's just really awful. JOE: I feel like I'm looking at asm. SCOTT:**Oh, no! [Chuckles]**JOHN: Yeah, man. It's so bad. And then you look at the output of babel or the output of TypeScript and you're like, “that’s so clean!” SCOTT: Yeah. It's like, “yeah, that’s exactly what I would have done” or “that’s probably what I wanted to do,” either way… LUKAS:**Yeah, if I had [inaudible], that’s how I would write JavaScript. [Laughter]**JOHN: “I don't always code in ES6, but when I do, I use TypeScript.” WARD: We should mention that TypeScript is also a transpiler. JOE:**Yes. TypeScript is [inaudible] own transpiler.WARD: And so what it does is really , it combines both the tooling and the transpiler function. So that’s why it can do things like give you intellisense support and refactoring and all that -- all kind of in one package. And of course, it was complete ES6 which 1.5 will be. That combination would seem to be pretty compelling to me versus Babel. Have you played with 1.5 and can you say whether the promise is are there are not? SCOTT: I haven't played with 1.5. That's on my to-do list for the next… JOE:[inaudible] 1.5. I can’t find it. Like, I looked around the site and unless I'm missing something, it only gives you the current version, 1.4.**WARD: We'll get you the link. JOE:**I want it. Am I the only person that feels like TypeScript was something only for .NET developers until Angular 2? [Laughter]**JOE: Now it's something that maybe someone that doesn’t use .NET would consider using. JOHN:**So I think that's really interesting. We should do a show on TypeScript. [overlapping talks]LUKAS:[inaudible] anybody who knows TypeScript.JOE: And let’s get somebody from the TypeScript team. I'll ask them that question… SCOTT: I never heard of TypeScript until I heard of Angular. JOHN: So full disclosure on this: I have a TypeScript course with Dan Wahlin that we put up a couple of years ago in Pluralsight. TypeScript, it's not intended for that, right? So that's kind of the elephant in the room is that TypeScript was created not just to be for .NET developers. But I think you're absolutely correct. Until the Angular team decided this is where they're going to head and AtScript is going away and become a part of it and all that, I don't think a lot of the community really gave it a serious look. And the stats that I've seen over the last month since ng-conf are kind of supporting that so far early on. But it wasn't created for .NET people to be able to do JavaScript; it was created for, as Ward mentioned, not just getting the ES6 faster, but also the tooling experience. And we all know what the Angular team is really, really excited about having different tooling companies -- like WebStorm or JetBrains and Visual Studio and Brackets and all these others -- being able to light up all these features, now they can do all these type checking and other kinds of compilation. SCOTT: Yeah. That sounds really amazing. When I actually started getting to like, you know, using WebStorm and stuff with JavaScript, I was like, “Wow, this is awesome.” Because I’ve done Android development with Java. Coming over to the web, I was like, “Oh, man. I wish I had the right unit tests to see what type this was. This is ridiculous.” So like, that’s pretty amazing. JOHN: Yeah. But I think you're spot on, both of you, that did most people even really give TypeScript a real shake until ng-Conf? I'm not sure they did. WARD: Anything Microsoft did they're against it. They just couldn't believe that they could produce anything that anybody wanna use. SCOTT:[Chuckles] Right. That’s just screwing with Microsoft. That probably hurt their accreditation.**WARD: Yeah. And it' s interesting to see if that worm has turned because all the other companies they’ve fled to haven't exactly been great, you know, they are great friends with the developer that everybody was claiming they were. JOE: But I think we're also going to see others try to at least look at what TypeScript is doing to make up for it. Like TypeScript is the only thing that’s, besides Traceur… you know, Traceur supports the adaptations that Angular 2 has. TypeScript’s 1.5 is. Babel stated supposedly that they're going to… SCOTT: Yeah, they’ve just released updates to do it. JOE: Okay. WARD: By the way, that type notation stuff is not part of ES6. JOE: Right. WARD: There’s no type annotation in ES6. JOE: Yeah. It's not ES6. WARD: Yeah, it's a TypeScript thing. JOE : So I'm interested to see if the community starts to see some value in types in TypeScript and then we see other tools which are likely to come out and compete with them and say, “Hey, we're going to do some of that too,” you know, the new babel… SCOTT: I think we will. JOE: I hope so. SCOTT: I definitely think so. I mean, so right now, I've done some corporate training and a lot of companies are requesting like oh, they are asking me, so we'd be doing this with es6 or TypeScript and all of the stuff. Like, they are aware of this stuff and like they are very conscious of it, which to me is impressive because I wouldn’t expect them to be. So I think it is. JOE:**And one of the things that have always bothered me -- speaking specifically of types – is… and granted, when I went to JavaScript, I came from type language (I came from .NET, in fact) and I was doing JavaScript and CoffeeScript started to get popular and I elected it and I thought “no, I just wanna do pure JavaScript.” And even when TypeScript came around, and I thought that was kind of cool. It just didn’t really work out with everything that I was doing. But I do dislike the widespread, I don't know if it's just belief or just attitude that if I'm a frontend guy and I do JavaScript, that types aren’t valuable. And I hope that through Angular, through TypeScript, that we'll see a change in that behavior. It's not like you have to have types that build solid products, but types do have value. And I hope more people will start to see that.JOHN: That's the key. There's value there. It's not necessary. It's not like if you don't have it, you're going to fall apart, but there's definite value to knowing the types of what you do, especially for unit testing. And even testing before that and just looking at your editor, and knowing, “Oh, wait a minute, that's a number. I just passed an object.” JOE: I think they are just like in ES6. I think there's so many people that don't wanna use ES6 because they just don't understand that there's value there. SCOTT: Exactly. They’d look at some of the new features like WeakMap and something like “well, what's the point? I already have an object.” But they don't really understand the value there, but maybe they will. Hopefully they will. JOHN: So let’s say, Scott, if I'm gonna go down the road and use ES6 with Angular, if we go down that road, and I'm new to this and I wanna get started in it, we keep talking about transpilers, and that’s cool. We're not suggesting, I hope, that we're just gonna write click over our files one by one and… SCOTT:[Chuckles] No.**JOHN: So how do you suggest people actually use a transpiler in a real application? SCOTT:**That’s a great point. So you pretty much are going to have to adapt some kind of build system that you made yourself for a combination of some build tools or maybe something that is prepackaged. So I would recommend for some of the most popular ones out there. So you have webpack which is really, really awesome. So the way I look at web pack, it's like something that is awesome for the current generation. To me, it doesn’t seem like it's next generation, mainly because it doesn’t follow the module loading spec, like some other tools that we're going to talk about that does, but it's like really, really great when you compare it to something like gulp. So as far as transpiling and maybe even like building our CSS, it's super awesome. So webpack is one. There's plugins for like you can use Traceur or babel with webpack. It's so easy to get started. If you want a little more manual customization and do a little of the processing and other build steps, you can just go straight to using gulp. There's also a plug in which Traceur and babel there for gulp. You can just build your own process there. But my favorite one that I like to use – and I think it's just crossing the line of what the future of ES6 is going to be, so it might not have as many features as webpack does because it's stepping into a new generation. I would say it's going to be jspm. That’s definitely my favorite tooling. It actually uses systemjs to actually perform any type of universal module definition and you can require any module that you want. So you can go to GitHub and npm and just going to load that up as any module format [inaudible] ES6 so you can import it in any file. And it does the transpiling of your code as well. So that's my favorite tool. I recommend that. It uses babel and Traceur. But like I said, it doesn’t have as many features as webpack at this time, but they're totally working at it and I'm actually working on some plugins for it too.**KATYA: For those of us who are newer, such as I, what is systemjs? SCOTT: Good question. So systemjs is just a universal module loader. It uses module loading polyfill. So actually, the system object is something that’s part of ES6, but the systemjs library is just a polyfill for it. And really, it's just a way to load modules -- whether it's going to be commonjs modules like in node or requires modules, AMD or maybe even ES6 modules. It doesn’t matter how that module is defined; systemjs will be able to load it up and give you access to it inside your code. So it's just a universal way of loading these different modules because we've diversified the way we make modules over the last couple of years. And that’s going to be stuck in ES6. So this is just a polyfill for it. So aspm uses that to load the modules for you. JOE: Awesome. WARD: Just to be clear, you mentioned gulp and these package managers in the same breath that… I think we wanna make a distinction there, right? Because both is not a package manager per say – it's a build system. And build systems and package managers are kind of different, right? SCOTT: That's true. So gulp is definitely not a package manager. It's truly a build system. Its job is to handle a file. It pretty much does file manipulation for you and tons of other stuff that you can get to. But it's designed to take files, operate on them and spit them out. Definitely different than jspm, which is actually combined with systemjs, is actually a package manager. So its job is to like go and fetch packages for you from GitHub and node. So you can actually use them together. You can use gulp and jspm. And I do it all the time. But when it comes to actually taking care of all things related to my ES6, I usually just defer it to jspm and have gulp do other things like change log and all other types of stuff, not related to ES6. Although you can do it with gulp too, and there's nothing wrong with that. WARD: That's helpful. Thank you. SCOTT: And the thing I really do like about jspm is that… or actually, I think systemjs does this is the systemjs uses… if you guys ever used requires or amd, you're going to have these shims, where you define what this module’s dependencies are. So systemjs uses that. So you can really go to any dependency you want on npm or GitHub, and you can like, “You know what, I want to be able to import that.” And it's really sweet. For instance, the first time I use jspm, I was building an Angular application and I'm all about material design. So the first thing I wanna do is use Angular material. So if you are using Angular material, you know that it has a couple dependencies; it has its own JavaScript, its own module, and it also requires ng-aria, ng-animate, and it has its own CSS file. So there's four different dependencies there. Jspm, when you download Angular material with jspm, not only will it fetch all those dependencies for you, which it should but when you import Angular material, it's going to go ahead and import all those dependencies including the CSS and actually add that CSS into your HTML for you, so you don't have to add a link tag or anything like that. It's going to grab the CSS, stick it in the DOM for you and it's going to make sure you have everything you need and then now all you have to do is import Angular material from Angular material and everything is good to go and all wired up. So that right there, just blew my mind when I saw that. CHUCK: So one thing that occurs to me with this is if that you're writing code in ES6, do you just write your tests in ES6 too? SCOTT:**Yeah. [Chuckles] I actually thought about this for like two days. I was like “if I'm going to go all in on ES6, then I'm going to do everything in ES6.” And luckily, depending on what build system you use, there’s tons of ways that you can use ES6 with your test. So there's really isn’t an excuse in why you shouldn’t, other than the fact that you just don't wanna do it, which is fine, because there's overhead in setting up these plugins and stuff. But me, personally, I do write my tests in ES6. And depending on what build system like jspm has, let’s say we're going to write some unit test, jspm has karma plugins, webpack has karma plugins for the ES6. So there's definitely ways for you to use ES6 in your tests, and in my opinion, you should. You should just make everything uniform. If you're using ES6 to write your code, you should use ES6 to test it.WARD: I don't understand what the problem is. In other words, what am I missing? What was going to make it hard for me to write my tests in ES6? CHUCK: No, I just… so there are a couple of things that kind of occurred to me: one was that if there's an issue in your build process, then writing the test in ES6 if it's just run through with an interpreter may or may not catch those issues. Other than that, I just didn’t know if the tooling was up to date, such that it played nicely with ES6. SCOTT: Yeah. Most of the tooling is up to date. If you stick to like a popular build tool, build process like webpack or jspm, the tooling to update there. Now if you wanna go down like a more custom path, you're going to be in charge of making sure you do that. So like I think a catch-all way of making sure you can run your test that are in ES6, it's just compile it first and run the test there. Run the test against the ES5 and see what happens. So that’s definitely the catch-all, especially if you're like going down the gulp route where you do it yourself in gulp. And yeah, just compile it yourself and test ES5. WARD: One of the terrors with going through transpilers is you're sitting there, maybe debugging in the browser and you see something that you wanna go back… style the thing you wrote, you wanna see it in ES6; you don't wanna see it in ES5; you wanna be able to get it back and forth. Does that work out it practice for you? And with all browsers? Or what browsers do you use? SCOTT: There's two ways. So it's pretty much if you want source maps if not, so, when you're doing transpiling, especially with babel, you're going to some nice source maps, or if you're using like gulp, there's like gulp plugins for the source maps and the gulp babel plugins supports that. But if you don't use source maps, you'll be looking at the code that babel spits out or Traceur spits out. And babel is not so bad, but like we said, Traceur is pretty bad. So like, you're going to have a hard time doing that. But like I said, the sourcemap actually make it pretty easy, so I don't have too much problem on newer browsers, debugging my code. And then like you can look at the browser console, it will show you the ES6 code right there, line for line. And it works pretty good. Like, you wont be able to like actually like step through the execution of it and stuff because the browser is not reading that stuff. But you can still figure out what's going on, the errors on this line, here it is. So that’s pretty good. But testing on older browsers, I had a running on IE9 the other day. I forgot why I was doing it, but I was doing it… WARD: You love pain? SCOTT:[Laughs] I've had some pretty painful experiences, that’s for sure. And this was definitely one of them. It was just a lot of work going on; there was some polyfills that I was missing like for maps that the IE9 doesn’t like, and then just figuring out how to work their dev tools. It was pretty painful. If you're using the latest and greatest evergreen stuff, yes, you're going to do fine. But going backwards, I feel sorry for you.**JOE:**I just wanna point out that there was a time, (and I'm sure there's a couple people on here that will remember this time) when we were using IE7 and we had to do something in IE5 and be like “oh, that sucks that we have to go back so far. Good thing we have IE7…”SCOTT:[Laughs] Oh my god. [inaudible] IE7, I was maybe…**JOHN: We don't wanna hear it! CHUCK:**I was going to say, “he's going to make us all feel old.” [overlapping talks]LUKAS:[inaudible] In middle school. Middle school homecoming.**WARD:**Yeah. Well, back when I was painting on cave walls… [Laughter]JOHN:[inaudible] talk about how old my daughter was when IE7 was out. [Laughter]WARD: So, Scott, how has coding -- even Angular 1.0 -- in ES6 changed your style of building Angular 1 apps? SCOTT: That’s such a good question. This is like probably one of the best reasons I use ES6 with Angular. So I've actually, like, John Papa, I follow your style guide pretty to the T and really like the way of organizing the modules. Like everything just makes sense. And I actually taught that when I was teaching people Angular at Hack Reactor. So I taught them like, “Yeah, this is how you do it. It just makes sense when you build things by modules.” Actually, bringing in ES6, specifically the support for ES6 modules, and then like switching over to a component architecture, which is the recommended approach now because it makes the transition from Angular 1.x to 2.0 a lot easier. Using ES6 modules is just perfect for this because now, you literally can create an entire component that Angular is going to consume outside of Angular. You can create the controller. You can create the templates. You can create everything dealing with that module completely outside of Angular’s context and just have Angular register this component. And for me, that's really, really awesome because really most of my code now is actually can be tested specifically away from Angular -- which as we know, can be pretty difficult especially for people learning Angular; like getting them to write that test all these mocks can be pretty crazy. So this makes it really, really beautiful and it reinforces the point of like having modular code. So, now, you have people just working on separate modules and separate components, that can be composed to make greater and bigger components. And then eventually, you just have somewhere in your body tag, you just have like element that says app and your entire app is inside of there. And every single element there is just a component that was composed and written entirely outside of Angular. So that, right there, for me just makes a lot of sense. And I can actually use some of those components in other projects. I might just have a repo full of just random components, where I can just make an app composed of these three components and make another app composed of these three components. And it's just really, really flexible. And I'm not tied down to like Angular’s context anymore. JOHN: So the modularity really plays pretty easily with ES5, ES6, obviously. But let’s say you have a controller, Angular 1.x and you're doing ES5. So now, you have controller using angular.module foo.controller and then you define it. In the ES6 world, there's a couple of ways you can actually go about doing that. Have you tinkered with many of those? And then as a follow up on that, do you do scope or do you do controller as? And how did that play in your decisions with ES6? SCOTT: So if you wanna take advantage of the ES6 features specifically, I will say the class feature, which is pretty awesome. I mean, it does what we already know how to – just put some sugar on top of it. So that class syntax, so you definitely have to go with the controller as. You can do the scope, but then it isn’t as nice and it's not the recommended approach. And it makes transition over for Angular 2.0 a little harder. So I’d go with the controller as. And then what I typically do is like I'll have the entry files for my modules, my Angular modules, and then for instance, I'm going to make that controller, say .controller. I give it a name and then the second argument is actually a completely different class that I created in a separate file that I’m importing with ES6. So I would have the Scott controller being a separate JS file and it's just a class. And all the properties are defined to that controller. So you can just do your setters and getters there, your methods there or your properties right there in that controller. And that would just import it over. And so it's actually going to be registered with Angular. So that's one technique. I've actually seen people just go ahead and just like continue to inline their controller as they typically would do with ES5. But I've actually seen people use like arrow functions there. So be careful and not get “arrow function happy” because you can use arrow functions and decide that you wanna use the arrow functions for your controller, because you're actually going to change the context of what this is. So I've actually seen people do that a lot and I’ve helped people debug that. You’ve got to be careful how you use that feature, but definitely taking advantage of the class feature there and how you are going to separate file is powerful because now, you can test that controller completely separately from the rest of your application. And then maybe that controller might have some common stuff in it; maybe you have five different views and they all have a title that’s bound to their model, now, you can create a controller that has that and because it's sub class to those controllers, and you don't have to worry about that default there. So that’s just another way to take advantage of those features. JOHN: That’s awesome. That’s a good tip. So I mean, using those arrow functions, and I love my arrow functions too, but you can actually get in trouble sometimes with because you're not aware of it, because the whole point of the arrow functions and TypeScript's already doing this in ES6 as well, is you're not just getting this anonymous function with the shorter syntax, but you're also now getting the this context passed along to your function. So in some cases, it's what you want. In other cases it's not. SCOTT: It's definitely not what you want. JOHN: So we're just talking about ES6 with Angular 1.x, and we're talking about ES5 with Angular 1.x which you did, but you can also do ES6 or ES5 with Angular 2.0 as well. And I don't know about you guys, but I haven't seen any examples yet of doing ES5 with Angular 2. Has anybody else? SCOTT: It's not pretty. JOHN:[Chuckles]SCOTT:[Chuckles] There's too much to explain. I actually did it. I was trying to show somebody how Angular 2 worked and I was doing ES5, and I realized that there was this way too much for me to explain and most of it, I didn’t even know myself, because Angular 2 is just like on the bleeding edge. And the way that I'm looking at it, so far, that the [inaudible] people making it has all been like TypeScript and stuff, so like me looking at it in ES5, I was like, “well, I don't think I actually understand this myself.” Because I know like TypeScript, it does this but over here, I'm not too sure. It's just a lot of setup and a lot of bootstrapping. And for me personally, it kind of ruins the experience of actually building with Angular 2.JOHN: Yeah, if you're building with Angular 2, you kind of really wanna go down to that ES6 level, but yeah, I just thought it was worth pointing out there because there's actually four combinations that you can play with right now. SCOTT:[Chuckles] Yeah, it's pretty crazy. Now I wonder if that’s going to people in like some type of stasis, where they are like confused in like what they should be doing. Like, “should I be doing this? Should I be doing that?” I like the fact that we have all these options but I'm also worried that people aren’t going to know what to do and how to do it and what's the best way.**JOHN: It's actually one of the things that I get asked a lot in the style guide lately. There's been a lot of activity at my GitHub of when am I going to move to Angular 2 or when am I going to move to ES6? And what I'm actually planning on doing for that is just not going to bother with ES6 for Angular 1, for now, as far as style guide goes, because this is a little different. I'll move right to Angular 2 migration guide with ES6. Because, I think you'd agree with me, based on what I'm hearing is using Angular 2.0, you might as well go to ES6 or TypeScript. With Angular 1.0, while it's helpful to do ES6, if you're going to go that route, why not jump in Angular 2 anyway? SCOTT: Exactly. I agree. JOE: For most people, it's pretty premature to be talking about using Angular 2.0, so I would say that the right answer here is ES5 with Angular 1 is okay, but ES6 with Angular 1 is better. And then Angular 2, it's ES6 or you know, either with Traceur or TypeScript. Honestly, I hope that Angular 2 is one of the things that really pushed people that aren’t doing transpiling to start doing it, just because I think it does a good job of showing that if a framework takes advantage of what is available in ES6, that it makes a lot of sense. And then there's so much more to be gained by it. So I hope it pushes people as they start using Angular 2 for real, six months or whatever, that it pushes them to start transpiling and going to ES6. And we don't have very many people that say, “I've got to stick with ES5, but I want to migrate to Angular 2.” And I'm absolutely, absolutely, absolutely not going to go to ES6. I'm not going to transpile. I hope we get very few cases like that. CHUCK: I have to wonder a little bit if… and I think this depends on what kind of build process you already have in place, but some people, they write their ES5 Angular stuff, they kind of cram it all in one file and then they just serve that file. And so their build process is “I have it all in the same file.” JOE: That's fine as long as you have 200 lines of code. CHUCK: Right. What I'm aiming at is so for those people, the barrier to entry to this is that they actually have to add a build process. I don't think transpiling, if you already have a build process, is that bad because you just add another task to the list, and you know, install a new tool with npm or bower or something. But I'm really curious to see how many people really have a build process, where this is a trivial addition versus this being a barrier to upgrading eventually to Angular 2. JOE: Well, and the more that people do take that first step and finally put in a build process, then they'll start seeing that it's actually not as bad. You know, the first time, it takes a little bit of effort, but after that, on subsequent projects when you're just copying and pasting existing build process or you get really comfortable with grunt or gulp, or maybe it's WebStorm’s automatic build, whatever it is, you pretty quickly figure out, “Oh, this is actually isn’t so bad,” and then on new projects, it's not such a big deal for me anymore… even if it's a small project, you know, there's plenty of people out there that will still use ES6 even if they are building a toy project with 20 lines of code because they love it so much. SCOTT: That’s me. Everything that I build from outside of work is everything is ES6. I just don't start a project without it. CHUCK: Are there good examples on the web? I know we kind of talked around this a little bit, but are there good examples on the web of using ES6 with Angular? SCOTT: I think the most popular one that I've seen which after using it so much, I don't really agree with some of the patterns they did, but it's actually pretty popular and they were one of the first ones is GoCardless is a company and they have their own ES6 style guide out there of how they actually built Angular with ES6. They have their entire repo out there that you can look at. I looked at it at the time when I first saw it before I actually delved into ES6 in Angular, I liked it. But now that I'm using that, I don't really agree with some of the patterns, so maybe I might put something out there. Maybe put some of my own opinions out there. WARD:**Don't tease us, Scott. Come one. [Laughter]SCOTT:[Chuckles] Okay. So one pattern I don't like is how they don't really take advantage of the actual modules in ES6, but they really rely heavily on the modules in Angular. I like the way that since everything is going to be modules, it kind of reminds me of node almost, so there should be like entry file where you create an angular module and then it just registers all the components or whatever, that are created somewhere in ES6 (maybe in the same directory or sub directory.) What they did was like they actually just abuse the Angular module and they just kept registering everything on the same module. And I didn’t really like that. Instead of like creating an entirely new module, on this highly isolated component, they wouldn't take advantage of that. They were like sub classing the Angular modules – I'm sorry, not sub classing but doing like sub modules with the Angular modules. Which is great in ES5 and I do that all the time, but I did in ES6, you should just be like, if you're going to do the sub module type thing where you have like child modules that get registered on parent modules, you should do that in ES6 land – you shouldn’t do that in Angular land. All of my Angular modules now, they are almost entirely flat because the ES6 takes over the inheritance of the modules.CHUCK: Yeah. I wanna ask one more question and then I think we're probably going to get into picks. And I know Katya, you’ve done some stuff with Khan Academy and some of the learning systems out there, so I’d like your take on this. But how much of the material that new JavaScript developers are picking up is ES6, and how important is it that they pick it up early? SCOTT: Yeah, there's none. There's no material out there – none. And it's very important that they do. In my opinion… and especially since future development in ES6 is done, it's very important. If I were in charge of teaching somebody JavaScript right now, I’d actually teach them in ES6. CHUCK: Yeah. What are your thoughts, Katya? I know you’ve kind of gotten through some of these training and… KATYA: I agree. There's not really any out there – none at all. But it's really important to learn. I'm still learning it, so. CHUCK: Cool. Anything else we should cover on this before we get to picks? SCOTT: Other than there’s really not a good reason why you shouldn’t be using some type of ES6 -- whether it's ES6 or TypeScript -- no. And you should – you should totally be using it. JOE:[Chuckles] I totally feel like we're all just out in the woods, crying.CHUCK:[Chuckles]**JOE:**Nobody is listening. [Laughter]**JOE:**There's a few people that come out and they are like, “Hey, good idea.” And then everybody else is like, “There's some crazy people out there saying [inaudible] ES6.”**SCOTT: They say that now, but like all the training that I do, all the training that I do now is all about ES6. Even if it's nothing to do with Angular, it's just all ES6. And if somebody can figure out a reason why I shouldn’t be doing that, I totally wanna know because I can’t think of one. CHUCK: Yeah. Well, you know, the more I look into ES6 and the more that I play with it, it just gets a lot of the boiler plate out of your way, and then you can focus on what you're actually doing. Which is the power there in some of these higher level languages that transpile to JavaScript. SCOTT:**Yeah. That’s for sure. And one thing I noticed too is a lot of the corporate companies, like you said they have to invest in like a build system. And a lot of them, for instance, maybe they're using like PHP backend – good bless them… [Laughter] Now they are like, “Oh, wait. Maybe we have to use this thing called Node.” It kind of like teaches them new things, because they have to build this build system. And then they’d venture off in these technologies like. Like I actually was in a situation where somebody had a PHP backend and they were like using ES6 on the frontend and it was with react though and I was like, “Yeah, you know, you probably got to invest in something like a build system.” And they were just looking it up and they figured out and it like, oh everything is like on node.” I'm just like, “Well, yeah, you just got to learn node.” They didn’t think that node was like even a thing. They thought it was like [?] language. It was not even a thing to them. And they were like, “I got them to research about node and they were just amazed about it.” I think it forces people to like go out and do things they wouldn't normally not do.**JOHN: Yeah. I’d have to confirm that the aversion to node is amazing out there. If people haven't been… there's different reactions: some are just worried about it; some are “it's a lot to take in”; and others are just, they have this disdain for whatever reasons. SCOTT: Right. JOHN:**For the record, that's not me. [Laughter]**CHUCK: Awesome. All right, well, let’s go ahead and do some picks. Ward, do you wanna start us off with picks? WARD:**Sure. Mine will be where to get a look at the alpha for TypeScript 1.5. I don't know when the [inaudible] comes out, whether it will be beta or whether they will release it. They seem so close to that. We'll have some show links for that.**SCOTT: Sweet! CHUCK: Nice. Lukas, what are your picks? LUKAS: My picks are I have a book that I have just recently read that I really loved called The Effective Engineer by Edmond Lau. And it's just incredible. I burned through it in like 2 hours. And then I wrote them this fan boy email about how awesome it was. And it's just about how to be an effective engineer and choose high value activities and focus on those things. SCOTT:**You read that already? We just got that book. [Chuckles]LUKAS: I started reading it and I was like, my life is changed for the better. My birthday was last week and my wife bought me a Côte&Ciel; it's a backpack which is just absolutely gorgeous and I'm super stoked about it. And so those are my two picks for the week. CHUCK: All right. Joe, what are your picks? JOE: So at ng-conf, we had a StarCraft tournament and we flew in a couple of professional StarCraft players to play a couple of games against each other that everybody got to watch And then for fun, we got a couple of Joes play with the pros in a two on two -- one pro, one Joe -- against each other. We have this that we flew in and did control and the guy was so dang hilarious. We had this cast the other week flew in and did the control and the guy was so dang hilarious. He casted this game and he was kind of poking fun of these Joes and all the mistakes that they make. But it was funny as could be. And I'm so disappointed we didn’t record it because it was one of the funniest StarCraft game I've ever seen. So I wanna the cast, iNcontroL just because the guy was a great caster and he was funny as can be. And as a StarCraft caster, he's a great caster. So that will be my picks is the StarCraft professional caster, iNControL. CHUCK: All right, John what are your picks? JOHN: So I've got two picks here: one is my daughter who we're talking about early before the show started. She just spoke in front of the city council here in Orlando about a new high school proposal that they're doing. And she actually made the news in the newspaper. She did a great job and I'm just a proud father. I think it's great to see my 13-year old daughter getting up and speaking in front of everybody. And then from the coding side of things, there is this conference called Angular U that’s coming in June. JOE: Never heard of it. [Laughter]JOE: Anybody cool speaking there? JOHN: Perhaps. A few people. CHUCK: I've heard some names, but nobody cool. JOHN: This guy named Scott Moss is going to be there. LUKAS: That guy is a poser. WARD: He's going to talk in Angular U? That’s great! I love Scott. JOE: I heard that guy doesn't shower for a month. SCOTT:[Laughs]**WARD: And he sleeps in his car. We should have him on the show though. JOHN: We did hear that you have to shower to attend Angular U though. SCOTT:**Oh, no! [Chuckles]**CHUCK: it's a dirty rumor. You can just wade up in the ocean and come back. LUKAS: “Dirty rumor” ha-ha-ha. JOHN: I was talking to Dan Wahlin, he's one of the organizers last night and they’ve got some really, really awesome things lined up for this. The Angular team is going to be there, several of us will be there. I mean there's Joe, there's Scott, myself and some others. But I think it's going to be really… WARD: I happen to be one of those “others,” John. JOHN: Oh, Ward! Ward… WARD: Thank you. LUKAS:**And [inaudible] is going to be there.JOHN:[Chuckles] What's really cool is there's going to be some things besides just the regular talks there, too. So I think it's going to really, really exciting doing some really cool things that haven't really been accomplished in a while. So I'm pretty excited about Angular U.**CHUCK: Nice. Katya, do you have some picks for us? KATYA: Yeah. My pick is The Imitation Game because that’s one of the only movies that has actually made me cry. SCOTT: Oh, wow. JOE:**I was sitting next to her. I can verify… [Laughter]**SCOTT: What's that movie about? KATYA: It's about Alan Turing. SCOTT: Oh! CHUCK : Oh, I wanna see that one. SCOTT: Yeah. I wanna see that one. WARD:**Yeah. I cry every time I try and make something Turing complete. [Laughter]**JOE: For people listening to this podcast, that’s kind of a movie you should definitely watch and see the history. I've always complained about people that don't know the history. As short as it is, the history of our industry and the giants whose shoulders we all stand upon. CHUCK: Yeah. Absolutely. I should have a pick, but I'm drawing a blank, so I am going to pass. Scott, do you have some picks? SCOTT: I sure do. So my first pick is going to be Treeline – Treeline.io. It's this YC company now created by the guy who made SailsJS, which is like some backend language, backend framework for Node. It's like a drag and drop GUI that you can make a backend with. It's actually pretty awesome. I just tried out their beta the other day and I was pretty impressed because although I do a lot of work in Angular, I actually do way more work on the backend than I do in Angular, so I'm always interested in seeing what type of backend technologies they are. And this one seems pretty legit, so it's pretty awesome. And my next pick is going to be Interstellar, the movie. So I don't know if you guys have ever seen that movie, but when it came out, they had it here in San Francisco, 7K, 40mm IMAX. WARD: 3D? SCOTT:**It wasn't 3D. That would have just killed it. I would have been like, “Oh, my god.” I saw it twice in a week. And it was like the best movie I've ever seen in my life, mainly because yes, it was entertaining. It really did change my life. I cried in that movie, by the way – twice. [Laughter]**SCOTT: And I never cry. I'm really not good at expressing my sensitive emotions, but I cried twice in that movie. WARD:**Did you cry? [inaudible]**SCOTT: Yes! I was crying there. It was just heartbreaking. I guess because I'm a father and it was just like, “Oh, man. I don't know what I would do if I was in that situation.” It just changed my life because it made me think about my son’s future and his kids. And as humans, where we're going and like what we're doing. And like, I noticed some of my activities and habits changed after watching that movie. Really good movie. Highly recommend it. CHUCK: Very cool. JOE: It also makes you really aware of okra. SCOTT:Yes! [Laughs] Okra and corn.JOE:Yes. We appreciate okra a lot more after watching that movie. [Chuckles]WARD: I only cried in Halloween 5… SCOTT:[Laughs]JOE:[Chuckles] I cried in Dumb and Dumber, but.CHUCK: So I did realize that I did forget to announce we do have t-shirts out there. So go to the website, click on the link t-shirts. You can get t-shirts or hoodies or both for the show. We're actually doing this for all of the shows, so if you listen to any of the other shows, then go over there and click on those links too. And you can get t-shirts and stuff. When this comes out, I will be at Rails Conf. So if you're at Rails Conf, and you want a sticker for the show, come find me. I'll give you a sticker. Or if you're in Utah and you wanna go grab lunch or something, same deal. SCOTT: Sweet. CHUCK: All right. Let’s go ahead and wrap up the show. Thanks for coming, Scott. SCOTT: No problem. Any time. CHUCK: All right. We'll catch everybody next week! [This episode is sponsored by Mad Glory. You’ve been building software for a long time and sometimes it gets a little overwhelming; work piles up, hiring sucks, and it's hard to get projects out the door. Check out Mad Glory. They are a small shop with experience shipping big products. They're smart, dedicated, will augment your team, and work as hard as you do. Find them online at madglory.com or on Twitter at @madglory.]**[Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net]**[Bandwidth for this segment is provided by Cache Fly, the world’s fastest CDN. Deliver your content fast with Cache Fly. Visit cachefly.com to learn more.]**[Do you wanna have conversations with the Adventures in Angular crew and their guests? Do you wanna support the show? Now you can. Go to adventuresinangular.com/forum and sign up today!]
