[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!]
CHUCK: Hey, everybody and welcome to Episode 14 of the Adventures in Angular Podcast. This week on our panel, we have Aaron frost.
CHUCK: Joe Eames.
JOE: Hey there!
CHUCK: John Papa.
JOHN: Hey everybody.
CHUCK: I’m Charles Max Wood from devchat.tv. And this week, we have a special guest — Scott Allen.
CHUCK: Do you wanna introduce yourself really quickly?
SCOTT: Sure. I run my own company OdeToCode LLC, and do some consulting in the mid-Atlantic area of the United States. And do some PluralSight videos once in a while.
Today’s episode is about ES6 in AngularJS.
SCOTT: That’s right.
CHUCK: Do you wanna give us a starting point there?
CHUCK: Maybe explain what it is that we’re really talking about or give us a little more depth there?
JOE: ECMAScript 6.
CHUCK: Isn’t that what I said?
JOE: You just said “ECMAScript.”
SCOTT: I would definitely agree with that. I’ve long been a fan of composition over inheritance, so bringing together small pieces instead of trying to use inheritance to reuse code. I think unfortunately inheritance has been a selling point for object-oriented programming, but it’s just been over emphasized for decades. And I think it’s just over the last 8 or 10 years that people would come around and say, “You know, maybe inheritance isn’t that great.”
So that being said, when I first saw the class feature in ES6 I thought, “Do I wanna use this? Do I not wanna use this?” And I have to say that for building an abstraction, I think classes can be pretty useful because the code sort of jumps out at you and it says, “Here’s an abstraction to represent something. An abstraction to represent local storage or an abstraction to represent a ?? that we’re going to eventually data bind onto the screen.” And I don’t need inheritance for any of that.
And in fact in some places, this whole in ES6 works out pretty well. For instance, specifically when we’re talking about Angular, when you register a controller with an Angular and you say, “angular.module.controller” what you’re really registering is a constructor function. And when you create a class, the symbol for that class (whatever the class name is) is a constructor function.
The class syntax I’ve found is actually really nice for that, because yes, the class name is your construction function, but you also have this dedicated key word constructor, where you add a function to this class that is invoked when someone uses the new keyword against your constructor function. And it’s a really nice place to put your initialization logic and maybe list all of the things that are going to be data bound against those.
And I tend to see a lot of ES6 code right now that I’m running across where people are doing a lot of inheritance and super and they are going right back into that world. And that’s where I kind of get a little worried, iffy, if you may (pun intended) on [chuckles] having too much in my class. I love the idea of a class being a controller and getting rid of this crazy, modularity thing. But I think there’s got to be ways we can kind of control it a little bit, so that people can build things that don’t become too complex and we end up with a “seven layers of class inheritance hell.”
JOE: I can’t wait for the first time I maintain code like that.
AARON: So I’m over here biting my tongue because I’ve got some opinions on classes as well. But I’m excited to hear how we’re going to use this stuff in Angular. So I’m going to avoid the whole ES6 discussion, and hopefully we can talk about how it works into Angular.
CHUCK: I think that’s actually a good point. How does ES6 power up Angular?
SCOTT: I don’t think there’s anything specific to ES6 that lets say would make an Angular experience better or worse. I don’t know how to explain this, but ECMAScript 6 is the language and I think the language is more beautiful. Therefore, the code that you’re going to write to power Angular will be more beautiful, expressive and elegant and so forth.
JOHN: Can I say, “Oh, thank gee for having arrow functions.” So, so happy to have those.
CHUCK: [Chuckles] Is that just the arrow syntax, or is there more to it than that?
AARON: There’s more to it.
AARON: Yeah. So basically, in other words, everywhere in your code where you said “var me = this” so that you can later on say “me.something” without referring to the wrong this, you don’t have to do that anymore with arrow functions. It keeps its scope on the right this.
CHUCK: Right. So one other thing that I’m curious about is just the barrier to writing Angular in ES6. And there were couple of things that come to my mind. One of them is my browser runs ES5, I believe. So do I have to add some extra libraries or something to kind of fill in for the ES6 functionality?
SCOTT: Yeah. And that’s really easy to put into your workflow. I mean, chances are you already have some sort of build system or task running that’s linting files and concatenating files, so that this will just be another step of first transpiling things from ES6 to ES5.
JOHN: Scott, have you used 6to5?
SCOTT: I haven’t, no.
JOHN: It’s a library. I think Dan Wahlin, I believe. I may be incorrect, but I think Dan Wahlin was telling me he was using 6to5 and I checked it out. It looks really interesting. It does a similar thing turning ES6 code into ES5 code. Because I’ve had my own issues. I love Traceur, but I hate it at the same time.
JOHN: But this seems to be an alternative which I hadn’t heard much about. I’m curious, have any of you folks used 6to5 yet?
JOHN: I’ll have to ask Dan about it — if he’s even the one who told me. [Chuckles]
AARON: He’s got a lot of features in there though — 6to5.
JOE: Also, it’s worth noting that if you’re absolutely unable to do any kind of a build process at all. There is some shim libraries like ES6 shim and others where you couldn’t get a few of the ES6 without actually going through your build process. But it’s pretty limiting. Like you have map and set, but you won’t get any of the new syntax that makes like class and fat arrow and things like that.
JOHN: And there’s develop time experience, and there’s run time too, right? So develop time, use whatever you want to get there like these shims but runtime, I think we would generally not recommend putting another library in the browser to make people do that.
JOE: You talked about not putting in shim libraries. It’s important to note that Traceur does have an actual shim library that does have to run. It does not compile 100% of your ES6 written code to ES5 compatible code. For example, things like map and set, those are objects that just don’t exist at all in ES5. And there’s no analogy to them, so you do need some shimming. So there is some shimming involved even when you’re using a compiler like Traceur.
JOHN: Right. And Traceur mostly work on the server with your build process, but you get a couple of those things shimmed. It’s not the full shim.
JOE: Right. Sorry, let’s move on to another question.
JOHN: Good point, man. So Scott, where does ES6 leave things like CoffeeScript and TypeScript and whatever else might be out there in the world?
SCOTT: Personally, I think moving forward, people that are happy with TypeScript are still going to be using TypeScript because ECMAScript 6 does give you classes and lambda expressions, arrow functions, things like that. But it doesn’t give you a compilation process that checks the types and does any sort of strong typing that you can get with TypeScript. And CoffeeScript, a slightly different flavor of language, and I can still see people still using that moving forward too. Does that answer your question?
SCOTT: I think so. Maybe when thinking about CoffeeScript not so much, but definitely Typescript is with types, that’s just not something you have sets and there’s a lot of people that want that, so I don’t think they would drop Typescript in favor of ES6 even though it has a nicer syntax for a lot of things.
AARON: So on that topic, I think that some people are going to prefer the route of kind of what we’ve been talking about so far which is polyfill all your stuff and make sure that you’ve got all the right polyfills and all the right build steps and kind of take care of it on your own. And then there’s other people that are going to rather use something like a CoffeeScript or a TypeScript where it’s going to take care of that stuff for you and you just write in whatever it is. And it will worry if you’re in ES6 land or ES5 land and work the way that it needs to or not.
So I think that people using CoffeeScript or TypeScript — and I don’t — but I think those people will possibly have an easier time upgrading their stuff to work with ES6 than the rest of us will. Again, not advocating for either those — just saying that that’s I think how it will work.
JOHN: Scott, who should be able to looking at moving to ES6 and when they should be looking? What’s the profile of that team that should be considering it or not considering it?
SCOTT: I’d probably wouldn’t do it if I didn’t expect the code to stick around for a bit, because although it’s relatively easy, there’s not too many hurdles. You have to have a build process and do this transpiling. It doesn’t really mess up too much of your workflow. If you’re just trying to slam something out, the minimum, viable product or something like that, I don’t know if it’s something I would consider for that sort of project. I think right now it’s still forward looking, right? The spec is basically finished, but it’s still in the “debugging phase” if you will, until the end of next year. Browsers are still slowly putting this stuff together. So we still have some time.
SCOTT: That’s a good question. That’s something I’m still really trying to figure out. Again, a lot of those is just syntax. Things that were possible before, but it’s just easier and more intention revealing. So having all these new syntax features doesn’t necessarily make programming in Angular faster or anything like that but I think it makes the code more readable.
And then it’s just sort of you up to you to figure out, “Do I wanna use Class? Do I also wanna use ES6 modules and somehow work them into this thing?” It’s looking at all these features and figuring out how you wanna map them. I guess the biggest thing is to me actually is classes. Do I wanna embrace classes or not? Because if you want to embrace classes as a way of building an abstraction, then you’ll start thinking of controllers as being a class instance and services as being a class instance.
AARON: I think classes is probably the biggest question of how does it fit in. I think what Scott is saying is true. I think everything else just kind of fits in. Like the rest of its syntax, the only real major change… some of those syntax though will change how we’ll write Angular. For example, when you have a class or a controller function, we can do like default value stuff in functions today, and then Angular knows how to inject based on the signature of the function. But if we start putting all sorts of weird, default values and rest arguments up in our controller functions, the Angular library is not going to know how to parse that stuff out. And we’re going to start getting a lot of errors. And so we are going to have limits on what we can use and what we can’t use. So, I mean like you pretty much are going to have to stay away from anywhere Angular needs to dependency inject anything. If that makes any sense.
JOHN: What do you mean by stay away from it?
AARON: Like, if you have a filter or any part of Angular and you wanna use like rest arguments in it, that rest argument syntax will likely break the dependency injection engine. Or if you try and like do a default value on something that’s getting injected, that syntax in the places where the dependency injectors trying to look to see what needs to be injected. Those syntax is like equal signs or like a triple dot or a function call for a default value. Those kinds of things will likely break Angular’s dependency injection system.
And so, anywhere where a dependency injection function like a controller or service, you’re going to have to stay away from using the new ES6 syntax sugar in those function parameters. So in your scope functions, like “scope.foo = some random function,” you could use it in there, but you couldn’t use it on your controller function because those syntaxes will likely break the 1.3, 1.2 or 1.1 dependency injection.
I mean, I was just trying to point out that you can use it. You’re not likely going to be able to use most of it, like if it goes up in your parameters, you can’t use for… it will probably break the dependency injection. But you could use everything like modules, you could use generators, you could use let. It should be a problem.
I don’t know if classes will work or not. We’d have to test to see how the native implementation of a class, if you could just swap it out for a controller function. Because I don’t know if those controller functions get newed up. Does it call new?
SCOTT: Yeah. If you register a controller using the name of your class, it all just work.
JOHN: Beautiful. Awesome.
AARON: That’s good. Okay.
JOHN: [Sings] Everything is awesome.
SCOTT: Yeah, more beautiful Angular code. Absolutely.
JOHN: That sounds like the title of your next course. [Chuckles]
SCOTT: [Chuckles] I just wanna revisit it, if it’s okay, this idea of using a class as a controller, just because I’ve gone through like 12 different iterations of, “What is the best way to create a controller for Angular?” And a couple of those iterations involve classes. It’s really interesting. When you define a class in ECMAScript 6, the name of that class, that symbol, let’s say you write a class called “podcast.” Podcast is a constructor function. And Angular always treated the function that you register for a controller as a constructor function. So it uses the new keyword, so it instantiate some instance from that function.
AARON: I never realized that. That is true. I didn’t even realize I was doing that. But yeah, you are right.
SCOTT: It also does that when you call all the module object. If you call module.service to register a service, when it instantiates that service, it takes the function you give it and treats it as a constructor function because it uses the new keyword there. It doesn’t do that with factory or value or constant, but it does with the .Service API. So one way to write Angular code in ES6, if you want to embrace classes, is to write controllers as classes, and services as classes.
And the controller one is interesting to me because I’ve always felt… I’ve never been happy with the controllers that I write in Angular. There’s always something that I look at them and I wished that something was different. I have never been able to quite put my finger on it, but controllers are these interesting mix of, “Let’s initialize binding properties. Let’s kick off some calls to services. Let’s add some methods in, so that we can hook up ng-click events.” It’s just those mixture of all these things.
I’ve tried several different approaches to try to disentangle these things. And with classes, one of the nice things I noticed is that when you define a class, again the name of the class is your constructor function. And behind the scenes, there’s a constructor function and that constructor function still has prototype property, and any methods that you add to that class, gets attached to the prototype. So it’s very similar to what we’ve been doing in the past and like Aaron said, it’s syntactic sugar for what we’ve always been doing. [Chuckles]
But the interesting thing about a class is that there’s a dedicated keyword for a constructor, and that is the code that actually gets executed when someone says, “New podcast”, “New class instance”. And one of the things I’ve found interesting about writing my Angular code is all of a sudden, “Oh, now I have a place to put my initialization code. I don’t have to worry about where that’s going inside of some big iffy or inside of my function.” It’s very easy for me to look at a constructor function and see, “Oh, here’s this property, this property, this property, this property.” And then there’s a whole bunch of methods defining the class that are reachable from the view through expressions.
There’s a couple of good things about this and a couple of bad things about this — and I’ll try to wrap this up really quick because I know we’re short on time. But one of the things that changes when you use a class and you are writing that constructor method, is that that is now your injectable function. So the parameters that you advertise on that constructor method are the things that Angular has to figure out, “How do I pass these to you using its injector?” And now, those things are scoped to that constructor. So what are you going to do with them? Well, I guess I’ll save them as “_members” inside of my object now. Whereas before, when you write Angular controller using ES5, you just have a function and things are injected, then you have ?? inside of there that close around that stuff.
I’ve found some benefits to classes in the sense that, “Oh, I have this nice initialization logic here. And here’s a list of all the methods that are going to be available.” But there’s some down sides too, just in the sense that it’s a little harder to form closures around things that you need. You need to think a little more about where you are going to save things like services, that you’ve injected. Hopefully, that all makes sense.
AARON: John, in the style guide that you have that everyone loves, you have a syntax for injecting variables that I normally hate, and I tell people, “John got everything right besides this.” But I think using your injector syntax would probably for me, I think it would fix the problems that Scott’s explaining. And it would also fix my main problem with Angular controllers, which is like people writing code, code, code and then declaring another function and then more code, and then more functions, and more code. So it’s just all kind of combobulated nightmare.
And ECMAScript 6 classes and really all classes that I’ve worked with in languages, don’t let you write that root level code. Any code that’s going to run, has to be in a method that gets called. And Angular controllers are just horrible, ugly nightmares the way most people write them or its function expression, code expression, a watch more function expression. I think classes will clean up the way that people write controllers. And yeah, I’ve actually never been more excited in them now listening to kind of Scott explain some of the ways it will work. That’s cool. I’m excited.
SCOTT: Yeah. I know John in the style guide talks about, “In the controller, put all your bindable properties upfront.” And that’s kind of what you can get with the constructor of a class.
CHUCK: I was wondering.
AARON: And honestly, because of the inheritance, you could probably include like some default classes like an Angular controller class, dependency injection class, or an injectable class where you could extend that for your controller. And when that gets supered up, maybe it takes care of the dependency injection problems for you. You know what I’m saying?
JOHN: Yeah. I think it’s where inheritance really makes sense in this new world with Angular in ES6. Not where you’ve got, you know, I hate the canonical, “Hey, you’ve got mammal. And it’s got an animal and it’s got a dog and it’s got a…” “Oh come on, man get me out of that world, please.”
SCOTT: Yeah. At least on the server side, when I write server side code with languages that have classes, base controller classes have always been helpful.
JOHN: Yeah, I always question myself. Whenever I see… I love base controllers or base classes in general, but I question myself every time I create more than one level of inheritance — in any language. And it’s not that it’s a bad thing, it’s I really wanna ask the question, “Why did I do this? Is it really giving me a value for doing this?” And if it’s not, then I usually back off it.
SCOTT: Yeah, there’s dragons in that direction.
CHUCK: So I wanna ask, are we ever going to get to a point where we don’t have to do the ES6 compiling song and dance? And it’s not just a question of, “Okay, eventually browsers are going to support ES6, but we’re still going to have to deal with older browsers.” So when do we start cutting those off and saying, “I’m sorry, but you need to upgrade your browser if you’re going to make this work.” Or are we just going to have polyfills for the difference?
SCOTT: I sure hope so. There’s this push behind evergreen browsers now and everyone seems to be trying to keep things updated. So I hope that when my grandkids are programming, they are not looking for transpilers. No matter how long it will be.
AARON: So, Chuck, we’re kind of in a similar situation today already with ES5. We all use things like Lo-Dash or jQuery that kind of take the normalcy out of programming and it’s all kind of included for you. Instead of using array.map, we’ll use a lo-dash map instead because we don’t wanna have to detect if the browser has the map function on the array. So we’re already kind of in this transition phase with ES5. Granted, ES5 was a much, much smaller release. Way less ambitious than ES6, right? And so ES6 is going to be harder, but I think it will just work its way out, and I think the tools will make it easier to do the tools in the new language.
CHUCK: Cool. The other question I have (and this is something that I think can be answered quickly with Yes or No and some links), are there any examples out there of people writing Angular right now with ES6?
SCOTT: I don’t know of any. I’ve looked around a little bit, but I don’t see much of it as yet.
JOHN: Yeah. I’ve seen very little other than just examples and demos and things. I personally have not written any apps with ES6 for Angular.
AARON: Yeah. Can I give one last thing before we cut off, Chuck?
CHUCK: Yeah, go.
AARON: We’ve talked so much about ES6 in here. Can we just give everyone some references? I think you should go look at Joe and Scott’s PluralSight course. And I did a Frontend Masters course last month. It will be out in December. So if you’re sitting here listening to this going, “What is ES6? What in the world are they talking about?” There’s some really great video content online that you can go and learn about all the new features and consider how you’re going to implement it in your Angular apps.
JOHN: And I’ll mention, I don’t know if you did this in your Frontend Masters course, Aaron, but in our course, we have a whole section at the end that’s just about using ES6 today. How to use transpilers, and shims and all that sort of stuff. So that’s kind of the relevant point here is how to use it today, right?
CHUCK: All right. Let’s go ahead and do some picks. John, do you wanna start us off with picks?
JOHN: Yeah. I could do that. And I think Aaron hit the ?? there. The ES6 course is that both Aaron and Scott and Joe all have respectfully on PluralSight in front of the masters are excellent resources in general.
Something else that I’ve been playing a little bit with lately is NightmareJS. Pretty neat stuff. So I’ve been doing a lot with Phantom lately, doing end-to-end testing. And it’s kind of monotonous at times and I find NightmareJS is kind of cool to basically trim down the syntax to play with that.
Second thing I’ll put out as a pick is I’ve been doing a lot of research lately on Restify, Cola, Hapi, Connect, and Express, just going down the road of all these different things that serve up APIs in the server. And one thing I didn’t really think I do coming out of this was think that, “You know what, all these are pretty darn cool.” So my pick in that case is, it’s an amazing Node ecosystem that we have to be able to say we can choose Restify, Hapi, Cola, any of these guys and actually build a robust web API out of them. So I’m picking Node, man.
CHUCK: Do you have a tip?
JOHN: My tip in this case is actually use tools like JSCS, JSHint, JSLint, ESLint, because even though you might write good code and solve code, those tools can really help you find issues in your process, especially, on large teams. So my tip is all those linting type tools.
CHUCK: All right. Aaron, what are your picks?
AARON: I’m going to pick a project called Angular Custom Elements, which it’s kind of a directive system for Angular 1.2, 1.3 that allows you to kind of start using some of the web components stuff. And I hate the web component API. I think it’s really hard to learn. I don’t think most people will love it, but putting it behind this Angular custom elements will allow you just write your regular Angular code and take advantage of custom elements in the browser. So that’s my pick.
And my tip is make your Angular apps performant. I did a talk at AngularJS Boston last week, and it was epic on performance. So go check it out.
CHUCK: Awesome. Joe, what are your picks?
JOE: My pick is going to be the movie Fury with Brad Pitt. I just went and saw it last night. Really enjoyed it. It’s a lot like Saving Private Ryan in its presentation. So it’s kind of like brutal show, but it was a good one. I didn’t like it quite as much as I liked Saving Private Ryan, but I’m a big fan of World War Two military movies and I really enjoyed it. So that will be my pick.
And for my Angular tip, my tip will be to learn to use resolve when doing routing. The resolve feature is really neat. It’s very powerful. It can help you when you’re doing authentication, authorization or when doing loading screens. And it’s just a really cool feature. So that’s my tip is learn to use resolve in routing.
CHUCK: Awesome. My pick, I’m just going to remind everybody about the MobileJS roundtable that we’re doing. So go ahead and check that out again. And you can just find out about it by texting “MobileJS” to 38470.
And my tip is you can use the angular.module not only to define modules, but also to look them up. And that way you can avoid polluting your creating global variables to keep track of your app.
Scott, what are your picks?
SCOTT: Sure. The last book I’ve read, I enjoyed it was Lock In by John Scalzi. I was a Robert Heinlein and his book always remind me of some of the Heinlein works because he has the ability to explore social and political issues involving technology, but he does it with a compelling story.
Another pick would be PhysicsJS. Just something I played around with a few weeks ago or a couple of months ago. It can make things move around in the canvas, and it’s pretty easy to use. I even had a blog post back then about how to wrap PhysicsJS with some custom directives and services with Angular to make it really easy to use, make it very declarative.
And another pick would be for those people that travel a bit, or even if you don’t, travel.stackexchange.com. It’s one of those sites that falls under the Stack Exchange and Stack Overflow umbrella. But it’s fascinating if you just want to see different questions and answers about airline luggage rules and people that get into trouble with the Visas. And sometimes it’s just plain funny. I mean you see people in there asking questions like, “I just bought a live tarantula. Can I take this on an airplane?” [Chuckles] It’s bizarre.
And as a tip, something I’ve found this week is the browser.pause() API. If your writing protractor tests that aren’t working and are driving you crazy, if you call browser.pause(), it will break into the debugger and you can actually play with developer tools in the browser and play with variables in the debugger.
CHUCK: Very cool. All right, thanks for coming, Scott.
SCOTT: Thank you for having me on the show. This was fun. I enjoy the podcast – all of them.
CHUCK: [Chuckles] That’s because we have awesome hosts. All right, I just wanna thank everyone again for listening and we look forward to talking to you again 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.]