WARD:
On the road, still on the road.
JOE:
Still on the road to NG2...
WARD:
Further down the road.
JOHN:
Further down the road with NG2. I would on the river to NG2.
LUKAS:
Yeah.
WARD:
Well, on the entrance ramp, [chuckles] getting on the road--
JOHN:
Finding your car keys!
WARD:
[laughter] Or say, "Oops, I lost my keys." [laughter]
JOHN:
I would going off to Rails on the NG train. [laughter]
WARD:
That would really confuse them because they think we're talking about a different technology.
JOHN:
[singing] Going off to Rails on an NG train... [laughter]
WARD:
Wow.
[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco and New York and LA get on JavaScript developers providing to put the salary and equity upfront. The average JavaScript developer gets an average of 5-15 introductory offers and an average salary of over $130,000 a year. You just can either accept an offer and go right into interviewing with the company and neither with that any continuing obligations. It's totally free for users, and when you're hired, they'll also give you a $2,000 signing bonus as a "Thank You" for using them. But if you use the Adventures in Angular link, you'll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired to get a $1,337 bonus if they accept the job. Go sign up at Hired.com/AdventuresinAngular.]
[Ready to master Angular? 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 our classes in St. Louis or San Francisco -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!]
JOE:
Hello, everybody! Welcome to Episode 60 of Adventures in Angular. My name is Joe Eames, I'll be your host today. Chuck is out. We have on our panel, the illustrious Ward Bell.
WARD:
Hello!
JOE:
Lukas Reubbelke.
LUKAS:
Hello!
JOE:
Also equally illustrious...
LUKAS:
Thank you.
JOE:
And just slightly more illustrious, John Papa.
JOHN:
Hey!
JOE:
Today, we are going to be talking about Angular 2. A few weeks ago, we had an episode called The Road to Angular 2. We ended that talk that we were going to be doing more work with Angular 2 over the coming weeks and months, and we're circling back around. That's going to be our topic today-- what have you been doing with Angular 2, what's it like, it's still on alpha right now, our experiences with it, where it's headed, our thoughts and impressions. Let's get started.
JOHN:
We last talked, it was several weeks ago, but it was lot of fun. We've all been doing different things with Angular. Maybe we can talk about what those different things are. Of my perspective, at the time when we did that podcast, I was doing a lot of work in TypeScript and ES6 with Babel and SystemJS, and just trying to get those things working around Angular because it was early alphas and I was just trying to figure out, "Okay, if it's early alpha, I'm going to go ahead and make sure all the other pieces that I need to use are in place." But since then, I've been doing quite a bit of Angular 2 coding, too, writing little sample on demo apps. What have you guys been up to?
JOE:
Ward?
WARD:
Well, I'm right there with John. I have been spending some serious time with the Angular 2 alphas with particular focus on how to unit test something. I'm in there and I'm ready to talk about where things are and where things are headed and what you should do about it.
JOE:
Have you actually gotten unit testing going then, Ward?
WARD:
I have, as a matter of fact. I doesn't sound like many [laughter], but I have over 40 tests.
JOE:
[chuckles]
WARD:
Because what I'm trying to do is figure out how to test the range of things that you would do on a normal app. I've been [?] each of the different areas or functional feature areas of Angular 2 and learning how to test each of them. It's not really about a test coverage of a deep app; it's about like, "Okay, how would I test the service? How would I test the component? How would I test this? How would I test that?"
JOE:
Awesome. We definitely have to circle back and talk more about that. How about you, Lukas?
LUKAS:
I had been admittedly a bit scared of the transient state of the alpha release so I've been focusing on ES6 and wrapping my mind around that, as well as using Gulp, using Webpack, and writing my 1.x apps in ES6 style, which then, I believe, will translate over well to Angular 2, as well as being a community person-- I am working, actually, with Jeff Cross, Patrick Stapleton, and Dan Wahlin, they're coming out, and we're doing an Angular 2 Hackathon in Phoenix-- as well as trying to get good resources out via Hackthon's and feedback. That is where my really focus is-- how do I get good content out to the masses as well as good feedback to the Angular team.
JOE:
I've been doing a bit of speaking about Angular 2. I spoke at that conference [?] for Pluralsight and building demos oriented around that. As a Pluralsight author, I'm always interested in new topics to author on. That's been my experience with working with Angular 2-- mostly, just in the demo and speaking about phase, talking about it. I think it were really fun talk about Angular 1 and Angular 2 directives couple of months ago at a conference, which I really enjoyed giving. That was at Angular U, Ward Bell's conference.
WARD:
Hey, it was Peter Kellner's, but I was there.
JOE:
[laughter] Helping from the wings, right?
WARD:
Yeah, that's it. That's what I do.
JOHN:
That was interesting at Angular U, on our den night to the session, on getting ready for things you can start doing. At the time-- this was 4 months ago now-- we were building an app with Angular 2, with ES6, and TypeScripts. There were definitely some differences between building it with those two technologies that struck me as I went through it. It was actually, I felt at the time, it was easier for me to build it with ES6 than it was TypeScript. For me-- I don't know about you, guys-- that's completely flipped for me. I've been writing apps to TypeScript with Angular 2 for weeks now, and it feels much more comfortable in TypeScript than it does in ES6 for me. Maybe it's because-- I know them both equally well-- but maybe it's because the tooling, it's what I'm thinking. The tooling is helping me catch stupid little things that I'm doing since it has more information.
WARD:
That manner is because, right now, there are a lot of things that are all have to be lined up, and it seems like you're saying the same thing a couple of different ways as you're connecting all, you're wiring up the dots, and the tooling can really help you there.
For example, if I import a foo and then I go use a foo some place else, it's pretty helpful when the tooling tells you that you didn't spell foo correctly, which I'm quite capable of doing.
LUKAS:
Out of curiousity, John, what idea are you using to get that? Is it Visual Studio Code? I'd love to hear your toolchain for that.
JOHN:
I've used a couple with it over the last couple of months. I've used the Atom VS Code-- Visual Studio Code-- and I've used WebStorm as well. I'm back on Visual Studio Code for writing Angular 2 because of the power of the different features that they're adding in there. VS Code is actually built on top of TypeScsript, which is one of the reasons why it has got such great TypeScript tooling built into it, so it's right on top there.
JOE:
I did not know that.
JOHN:
It's pretty impressive how they do it. It's actually built with that. What's nice is-- it's interesting. We talked last time about how the different players are in this game. To use Angular 2 is not just Angular; you've got to learn what tool are you going to use, what transpiler you do want to use-ES6 or TypeScript, or you could do ES5, although, I don't know anybody who's doing that. Ward made fun of me last time, doing a joke on that one [chuckles].
WARD:
Actually, I wrote an ES5 sample.
JOHN:
Good. You have some--
WARD:
Angular 2 with ES5 as a matter of fact. That's going to be one of the things we have to all know how to do because there are going to be people who want--
JOHN:
Right.
WARD:
let's say, "I don't want to mess with this stuff." The Angular team is very adamant that people who don't want to move to TypeScript or ES6 or something that should still be able to program at Angular 2 so I've been looking into how you would do that just a little. At least, I've got something going.
JOHN:
I think that the hard part has been, for me-- at least as well a couple of months ago when we do the other podcast-- was every writing a couple of samples for Angular U and some other things, I quickly realized that it's not just Angular. My struggles weren't with Angular 2-- its alpha and it has got its own little gaps because it's alpha-- my struggles were with the things around it. It was with, TypeScript is still evolving to add some of the decorators at the time (which it now has), the tooling was catching up with things that's going to be coming down the road with ES6 and ES7 even, and then also, the module loading story with SystemJS or JSPM or Webpack. I feel like I've got a better hand on those things because I focused there for a bit and I circled back to Angular 2, which its funny part was, there were weeks where I'd go and I didn't write any Angular 2. I was just writing TypeScript stuff, or I was writing JSPM or SystemJS stuff trying to get to work. Now I'm back on the Angular 2 stuff and able to dive deep into what's happening there. But I think for people getting started, the lesson at this might be, "Look, even if you're not familiar with Angular 2, you might and you don't want to jump in right now, like Lukas has done. You might want to jump some of these other things because they're all going to be equally valuable to know. The important part here is, Angular 2 isn't forcing any of these on you. You could use ES5. But if you're going to do JavaScript in 2015, 2016 and beyond, you really need to start learning ES6 or TypeScript or one of these things.
JOE:
Right.
LUKAS:
I would even say, if you're not using a build system like Grunt or Gulp, then you really should implement that into your workflow as soon as possible just the advantage to start staggering. This has actually been a good opportunity for me to even just sharpen the saw on that as well. But I'm going to think, any kind of modern web applications, you have to be using a build system, too, to help out. That's, I think, an implied benefit of moving in that direction.
JOHN:
Yeah. I think a build system and a module system, right?
LUKAS:
Yup.
JOHN:
Because you have something to load these modules, and these modules in Angular 2 are not the modules that we're familiar with in Angular 1. The modules in Angular 1 are more like name spaces, if you have a Java or .NET background. In Angular 2, their traditional modules from the ES6 are what is it, 2015 now, syntax.
JOE:
I recently had an interesting experience with ES6, even though there's reason to learn it because it's how we author Angular-- well, it's not how you author Angular 2, but that's what a lot of the demos right now, at least, are produced. There's a lot of interesting stuff going on in ES6. I always felt like outside of just the module system and maybe the fat arrow that just had a lot of little cool things, but they were little sort of niche features. Even though I've actually done a course on ES6 so I know it pretty well, but recently, I was doing some work and I saw that somebody was doing destructuring in ES6. It was like the back of their hands so every time they were doing anything that they could use destructuring, they're using destructuring. Just watching them work, I was like, "Holy cow! This is actually really cool," and it has become my new favorite feature in ES6. I think it's one of those--
JOHN:
Joe, can I interrupt you? Can you explain destructuring to people who may haven't seen it?
Because I agree, it's pretty cool.
JOE:
Yeah. It's easy to go online and find these little tutorials that show you, "Hey, if you have an array of two elements and you want to swap their place in the elements to use destructuring, which is you set up a var and you create multiple variable names, and then the equal sign, and then you play it on array or at an object. And based on whether you're playing it on array or an object, you can use, on the left hand of the equal sign, square brackets or curly brackets to match up. If you're destructuring an array, use array brackets." It's hard to describe over audio, but certainly, look up a tutorial if you're interested.
It's a way to basically point at a more complex object either in array or an object and plot just the pieces that you want and get variables that point at them. The idea seems great, but until you see it in a useful scenario, you're like, "Oh, that's cool." But once you start seeing it in useful scenarios, all the six features are going to be like this, "They seem cool," and then you start seeing the useful scenario, especially if you can see the useful scenario where yourself could use it frequently, then you start to see, "Wow! This is actually really cool. I'm going to start doing this a lot more now that I can see where this can benefit me." In this case, it's a matter of, "Hey, if you got a function that returns an object and that object may have five variables or three variables and you want to work with them, it's really easy to grab those three variables into their own variable names-- foobar and baz, for example, and work with them. Or, if you have a function that's returning 10 things, you only care about two of them, then it's easy to grab just those two and put them in variables really quickly. That's destructuring, again, difficult to describe over audio. But it wasn't until I really saw somebody working with it second nature that really struck me as well. That's really cool.
JOHN:
In a way, I look at that with modules because when you're importing it from a module even, which is a form of that, too, you're able to--
JOE:
Uhmm-hmm.
JOHN:
It's almost like you're able to reach into the module and grab just the piece you want by doing destructuring bacause then you're saying, "Hey, this module may actually expose seven things, but now I'm only grabbing the one I want." Or, as you mentioned, sometimes you got an object literal or a class or whatever in ES6 or TypeScript, and you want to take that and you want to pull out just the properties you want into other variables.
JOE:
Right.
JOHN:
So there's lots of great applications to that that just make coding easier, I think.
JOE:
Yeah, so I'm waiting for that experience with TypeScript. You guys--
WARD:
You have destructuring in TypeScript.
JOE:
Oh, yeah. No, no. I'm saying, I'm waiting for that experience of, "Oh, wow! That's really cool. Now, I'm excited about using it." I'm waiting for that experience with TypeScript. One tutorial of TypeScript is see code in TypeScript, and I'm still waiting for that "Oh, that's cool" moment.
WARD:
Yeah. The way-- I don't know how it's cool because it's the thing that every other languages had. But the fact that you get in IntelliSense, the fact that you get typing support, the fact that you can do refactoring comfortably and say, "Oop, someone rename foo to faz." Or, more challenging, you've got a variable call data and you want to do that and you don't want to do a global replace of the word data; you want to just change the variable whose name is data. Only with TypeScript plus tooling that you get that.
JOE:
Right.
JOHN:
Yeah, and auto-complete and filling things--
WARD:
Auto-complete and all that's catching of the silly stuff that can really bug you down, that's the like, "Okay, I'm glad to have that now."
JOHN:
But the good news is here, too. You could use-- to be clear, I'm a TypeScript guy, too. I've done a lot of ES6 with Angular, probably more than TypeScript at this point, which is oddly, but you can use either. This isn't one of those things where I think somebody has to go and then get married to one or the other.
JOE:
That's true.
JOHN:
I don't think there's a huge learning curve to go from one or the other, to be honest with you.
WARD:
Yeah. I agree with you, John.
By the way, for what it's worth, I'll throw this in there. The JavaScript code that the transpiler has been producing, the TypeScript transpiler producing is very readable.
JOHN:
It is! Isn't it?
WARD:
In fact, what I've done, and I learned this from Igor, when I'm debugging, I actually turn off the maps and I debug in the JavaScript that was generated. I have no trouble finding where that code was back there in my TypeScript source.
LUKAS:
Pro tip! Write that down. It's a pro tip.
JOHN:
Let's be fair, too. I think in some cases, that works if you keep your code tight still. Like if you did-let's say you broke all the rules, and I say these are mythical rules-- if you built an application where you've got 10 views, 10 components, and you're putting them all into one file, for example, it may be very difficult to debug that transpiled output whether you sourced maps or not.
So if you follow good standards and you keep all your things tight and only make them fall a single responsibility, I think it's really easy and reasonable to debug either the TypeScript or the ES5 transpiled code.
WARD:
Yup. No question.
JOHN:
So let's talk about Angular 2 for a minute.
WARD:
Why not?
JOHN:
We had this thing in Angular 1. Let's draw some comparison because I'm a dumbo here, I can't figure out what I'm doing, and that's me for real. I'm trying to figure out how do I go from Angular 1 to 2, I had this thing called a Controller, and then Directive, Gulp, Transclusion, and all these stuff. The first thing I was trying to figure out is, "Hey, they're not mentioning MVC," at least I haven't seen mentions of it. Is that a problem? I got to tell you, the pattern is not-- I still love it, it's great, MV star-- but doing Angular 2, I feel like I'm there anyway even though it's not through MVC. Meaning, I still have models of data, I still have views, my templates, and I still have something that's like a controller with my component.
So to me, it felt like I'm at home. It hasn't been this massive leap of, "Wow. I got to learn new pattern." How do you guys feel about that?
JOE:
I've been doing a lot of consideration of what's underneath the hood. For me, I actually find that it's very different. I do see the similar patterns, but I find that as very different myself.
WARD:
Interesting. Because I had the same reaction that John did. It's almost hard to get away from. I think of it as MVVM, but if you want to call it MVC, that's fine. Because when you have a component, and the component by definition is something that has a view and wedge it to controlling code, and the controlling code is usually producing data that could be a binding, too, that's your model. So a component is a view and a controller just almost by definition. So I'm curious, Joe, about how that didn't come across to you.
JOE:
Well, I also am of the camp that there's no such thing as MVC; there's just one guy believes as MVC, and the next guy believes as MVC [chuckles].
WARD:
Yeah. So if we will loosely define it as the view as HTML and the controller is the stuff that interacts with that HTML and controls that HTML, if we could agree to that, then are you cool with the view can see separation?
JOE:
Yes.
JOHN:
I think the important part here is not so much-- I agree, Joe, I don't think it matter so much if you call it MVC or Ward, you call it MVVM, MV Star, whatever. To me, when we try to go to new things, we try to draw similarities based upon our experience in the roads that we've travelled. With that, I was trying to look for anything I could hang on to and say, "Alright, everything has changed. I need to figure out what isn't different. How would I do what I did before in this new place." I was very comfortable that at least those concepts to me were similar comparisons. For example, to me, things I do before in the controller or directive, I now do in a component. Things I used to do in a factory provider service, etcetera, I now do those in just a regular class. To me, that simplified things, too, which was easier. Now I only have two things I got to deal with, really. I've got components that are classes, and I've got regular old classes that are just regular old classes instead of 18 different words I had to remember in Angular 1.
JOE:
Right.
LUKAS:
Pro tip!
JOHN:
The things disappeared, too. Like $scope, where do go? How does data get up to the view? How do we do that in Angular 2?
JOE:
Right.
WARD:
You're going to have to use different patterns. But, it's there. The thing is that, John, if you'd been evolving your external app to try to explore the primary features that would be of interest to an application developer, you found the things you needed, right?
JOHN:
Most of them, right? There has been all the major things have been there. The things I haven't found against alpha are things that I've raised either on GitHub and somebody has already raised them and said, "Hey, we're needing this." Or,they were things that were like, "Oh, yeah, we need to add that," and literally within a day, the team has been able to put that thing in there. To me, it's almost like clocking the trim around your house. It's not like, "Hey, we forgot a room," it's more just, "Oh, yeah! I forgot that little piece there," or, "We need to tie this one up over here." I feel like the state of it now at-- what do we at, alpha 36-- is much closer to something that we can actually start seeing what it's going to look like later.
WARD:
John, if you were to enumerate the key things that you were trying to-- to make sure that as an application develop, we're in there-- what are those key things?
JOHN:
My top seven: Data binding-- being able to display data in a list. Dealing with like an ngRepeat and things like in Angular 1, which is ng4 now. Doing master details is the third one-- some way to do that and everything involved in it. Number four is built in directiives-- basically, all the things that I need to be able to do inside of an app, what does Angular get me out of the box to get there. Number five is multiple-related components and separation of things into the right places-- making sure I've got components and services and bootstrapping and things like that all alone. Number six is routing-- a single page app isn't much fun with one page. And then, number seven is being able to talk to HTTP with asychronousness.
Those seven things in my mind need to be there. From what I found, they are there.
WARD:
Yeah, I think so. Dependency injection is still there...
JOHN:
Yup.
WARD:
It's actually there as much up a bit. So when I reached for something major, I found the answer there. We all come from Angular 1 and when I set up, boy, I used to do that in Angular 1, I pretty much am at the point where I can say, "I know how to do that in Angular 2." That includes the one that-- if you've been listening to our shows and you've heard me beating the drum about where is two-way data binding-- I think that they've got a syntax there that achieves what we're looking for when we ask for two-way data binding. We could call it two-way data binding if you really wanted to squint at it. It's not technically that, but the things you were trying to achieve with two-way data binding, I have found I've been able to achieve with template syntax in Angular 2.
JOHN:
All the basic core stuff. Let me take a step back in that. I think, there are things in Angular 1-- this is where I'm going with the tutorial type and working on that Ward and Chuck has been talking about-- everything you learn in Angular 1, if you watched any of my sessions or the presentations or any of the other guys out there doing them, the things you learn are those the data bind, the HTTPs, stuff like that, routing, if you know those things in Angular 1, you can learn them in an hour, and you've got 80% of what you need to build an application, and you can really have a lot of fun. I feel like that kind of story can be built for Angular 2, and that's what I'm trying to figure out how to articulate that. I don't think this is going to be any harder, or any easier to be fair, than getting into Angular 1 with the only exception of now, the whole JavaScript world has evolved from being script kiddies, as Ward has said in the past, to being more of a real language. You've got ES6 or TypeScript, we've got module loaders and the tooling, so we've got more things we had to think about that has nothing to do with Angular; it's just, the environment has changed. But I think, if you just look at Angular 1 versus 2, the concepts, in a lot of way, some got harder and some got easier.
Overall, to me, it felt very similar.
WARD:
I agree with you, John. The thing that's the hardest right now, at least it was the harderst for me, maybe you can chime in, it's getting in the front door; how do I get my node models loaded, how do I get the SystemJS or whatever I'm using for package loader to come and behave, how do I just get it so the pieces arrive, [?], or it's how the modules work. That is largely out of the control of Angular 2 because they made a commitment to the ES6 style of things.
JOHN:
Yeah, talk about that story, Ward, where we were putting it together in Angular 2 app, and for a week, we didn't touch Angular. All we did was try to figure out how do we get SystemJS in its current beta form, Angular in its current alpha form, and TypeScript 1.6 in its current beta form, to play well together.
WARD:
That was painful.
JOHN:
It was hard because you had to know the right-- every time I looked around, somebody had a
working example using three alphas ago of one. Or, I've pinned to this beta of SystemJS and I said, "No--"
WARD:
We went from version 0.16 of SystemJS to 0.18, and that just shot us. That was just pain.
JOHN:
Yes.
JOE:
One of you spent a week trying to get that to work, you probably went through a version or two of alpha.
JOHN:
We did. Little things happen. For example-- again, this is alpha-- little things happen. It was contributing factor, SystemJS changed the way that they handle the configuration to load the module so I had to adjust my system and config quite a bit.
TypeScript had some things that made it difficult to import things at the time because they're now-the way they import specs working, I guess, you can put padding in a different style, so they had to adjust to that. On top of that, Angular had something with the old SystemJS built into the way that module loading beta Angular Dev release.
I had to get all three of those people through GitHub to figure out where do I go in this direction because me being me, I'm not willing to pin into an older version. I want the latest. Give me the latest release you've got, and I want to make it work.
WARD:
Before the audience goes running for the hills, we should take a step back and say, "Look, the story we're telling you here is what it's like to be at the bleeding edge."
JOHN:
Yes.
WARD:
The fact of the matter is, that although we may have suffered to get there, once you learn the right incantations, once you learn how to issue the magic spells, it works and they're going to shave off the rough edges. So, by the time you, dear audience, are facing this, the way forward should be pretty clear and you won't even know that all of this pain happened. So really, what weren't telling you about are our struggles here; we're telling you about what it's like at point in time as you're trying to approach this thing that's called Angular 2 alpha. We're saying that right now there's pain, but we can see a future-- not a distant future, but a future not to far off-- in which you just follow the cook book and you're there.
JOHN:
I agree. I think I've gotten at least my personal steps. I've written my old little Read-Me's on how do you get started with this stuff now to get, I called, the ecosystem. How do you get pass the ecosystem so you get to actually working with the code. I've gone it down to just a couple of steps now. It looks easy now not knowing at the time with all the motive parts, that was the hard thing. But now, it's easy once I know the right way to go, and I think it's going to get even easier there. This is what it's like to be on a bleeding edge. None of us-- at least, I'll speak for myself-- I'm not building production apps with Angular 2, I'm trying it out. I'm taking it for a test drive to see what it feels like.
JOE:
One of the things that occured to me a little bit ago when we're talking about ES6 and TypeScript was ES5. What have you, guys, done with Angular 2 and ES5, and what are your thoughts and comparisons between that and ES6/TypeScript?
JOHN:
I have done very little with ES5 in Angular 2.
JOE:
Same here.
JOHN:
That's been intentional.
WARD:
I have done very little, but I've done some, perhaps, more than others. I'll tell you what-- again, I've gotten much beyond the Hello, World example in straight ES5, but let me say that they have introduced a DSL-- I'm trying to remember what DSL stands for [laughter]...
JOE:
Domain specific language.
WARD:
Thank you. You know how you throw these terms around, you don't even remember what they stood for. Basically, you dot your way to bliss. So, you're going to have a class, the equivalent of a class, they've written a way in which you can author the code so that you progress by specifying what the component's features are, the equivalent of what you were doing in annnotations, then specifying what the view will be about in the same way that you would do in annotation and ES6 with TypeScript, and then finally, you do the body of what would be your class in ES6. So it is clearly ES5 JavaScript, plain old JavaScript, but it's structured so that you can communicate all of those things in approximately the same way you would if you were writing in ES6. I think that's going to read well. When I read my sample, something that's describing a component this way, it reads well. I think that they're going to have some bridge sauce in there that's going to make writing it in straight up ES5 okay.
JOHN:
Yeah, and they have a blog post out right now where they're talking about how Angular 1 and 2 can actually co-exist together. They're doing a lot of things on how you can use ES5 with Angular 2, how you can live with Angular 1 and Angular 2 in the same app even. I encourage everybody to go read that blog posting to [?] about that.
WARD:
That's if you want to mix Angular 1 and Angular 2. But I was saying, suppose you want to-- I thought you were asking if I wanted to write Angular 2 in ES5 rather than ES6, can you do it? The answer is, yes, you can. It's not-- in my very limited experience, it actually looks like ES5 that you would feel comfortable writing.
JOHN:
Let's talk about some of the stuff that we're actually typing. It's hard to talk about code over the air, but imagine yourselves, close your eyes-- unless you're in a car-- close your eyes and think about developing a component right now. A component being, let's say, a list of customers. You want to have some HTML, you're going to want to have some CSS on there for that component. It's probably going to become some kind of a tag in element and HTML, maybe called My Customers, and then you're going to need some logic to go with that, some JavaScript. All of that can be done with components. The way that they're creating this now in Angular 2 I've noticed is, I create a class called My Customer component, and I add the properties and things that I want to that. The way I inject things under there is, I actually use the constructor for the class to say, "Hey, inject my data service," or, "Inject the router," or whatever the heck I want to inject, and then we use these (I always get confused) attributes or annotations-- I get confused with these two decorators--
WARD:
Decorators, uh-huh.
JOHN:
Decorators.
WARD:
It's decorators. That's good. Some of the things--
JOHN:
It's a thing with an @ sign [chuckles].
WARD:
Yeah, the thing with an @ sign. The language here has to be refined.
JOHN:
Yes.
WARD:
But, the most common way I'm referring these things is annotations.
JOHN:
So these annotations are important because what they're doing, at least for my stuff, is I'm top of this class for customers, it's got an @ component, which defines something like, "Hey, what is the HTML tag I'm going to be using for this thing? What's the selector? My customer." And then, it's got an @View. It describes where is the HTML locator for this, or is it in line using this string interpolation with ES6? What directives am I going to be using on this? Where are my styles? So you think of these @ things, these decorators, on the class as metadata that describes the component that they're building, which helps it tie it altogether. If you think about the power of that, if you can describe everything your component needs and put it all in one place like that, think of the tooling opportunities and better yet, think about the situation. You're writing your code, large application, either write yourself or 10 people or 150 people, normally, you write your code, you run through CI, and then you still have this squeezy feeling of, "I need to see it run to make sure it works." Now, with this, you can actually catch some mistakes before you ever go to CI just by looking at your code and having the tooling tell you, "Hey, you got the wrong property, you pointed to the wrong thing, that file doesn't exist, it's the wrong data type," all that kind of stuff jumps right out at you before you ever push, end up into GitHub, or any of your CI processes.
You're talking about what's exciting about TypeScript to me, or even Angular 2, Joe, for me, that's the power I'm seeing. I've worked on a lot of really large apps, and there are so many things. I'm like, "Yeah, that's going to bite you when you run it." Sometimes, I don't even see those things because there's so much code, but these are the kinds of things that having metadata and having tooling around it that really helps uncover early.
JOE:
All three of you have pretty strong Microsoft background, right?
WARD:
Yeah, I guess I qualify.
JOE:
I probably qualify in that, too. But aren't all three of you pretty actively still doing Microsoft work?
WARD:
Uhm-hmm.
JOE:
So for the last four or five years, I've been only new to open space work and haven't really touched .NET in any significant manner in that time. I'm getting so used to using Sublime to do all my development, although, I'm doing Visual Studio Code a little bit. But, what do you think it's going to be like for that segment of the front end world that I suggest used to using Sublime; they're just open source devs using Sublime. Are they not going to see by often TypeScript? Are they just going to end up just authoring their Angular 2 in ES6 or ES5?
JOHN:
I think they're going to start to use ES6 and ES5. I've seen people do that. I've got folks that I work with who are dabbling in this arena. Some of them use Bracket, some of them use Sublime, some of them use WebStorm...
JOE:
Let's even talk Vim and Emacs.
JOHN:
Yeah.
JOE:
There's plenty of them out there.
JOHN:
Some of them use Vim like crazy. The funny thing that's been happening is, as we've been doing more and more dabbling-- this is all perfect concept stuff they're doing at our particular place, they're doing more dabbling in TypeScript-- the people who are using editors that have TypeScript support are getting the envious looks from the ones who don't. So if you're using Sublime and you don't have a TypeScript plugin in there, you're missing out if you're doing TypeScript. It's not going to be a fun experience. You're not going to gain the value of a lot of these things, unless you use an editor that's got that. I'm willing to bet that all the major editors are going to have full TypeScript support soon, and most of the major ones do already.
WARD:
Yeah. Like Sublime has--
JOHN:
Yup.
WARD:
You can wire it in. WebStorm has very strong TypeScript support.
JOHN:
Oh, yeah.
WARD:
My colleague, I'm writing in VS Code, but my colleague here with [?] is writing in WebStorm, and I liked that we're approaching the same code base with two different editors so that we can learn the pluses and the minuses of those different approaches. So, I think that you're going to be able to use the editor of your choice in this world.
LUKAS:
Let me jump in here real quick. There is actually, if you just Google TypeScript-Sublime, there is a plugin and interestingly enough, if you follow that rabbit trail, it's a repo from the Microsoft account.
So they've actually done a really good job of making TypeScript available for additional editors.
JOE:
I wonder what that story is like. Since it's from Microsoft, I would assume it's actually pretty good story. But--
WARD:
It's the same TypeScript service. They're really concerned that when you're running this stuff-- and they can make it happen because it's all JavaScript-- they're making sure that everybody gets the same TypeScript service. So if you want to differentiate as an editor, you differentiate an editor features that support you provide, but nobody is getting a better or worst TypeScript engine under the hood, everybody gets the same one.
JOHN:
This all comes down to-- there's two flavors of TypeScript if you think about what's under there. There's the TypeScript client and there's the TypeScript server. I'm probably not using the exact right terms here, but the reason that Visual Studio Code is so good on top of TypeScript is because it's letting you type in the TypeScript client and use the compiler, but it's also using the TypeScript server to actually make sure the tooling is there. That same TypeScript server can be used in any editor so you can actually use though as in these plugins can take advantage of them, or minimally, the plugins can simply just npm install TypeScript globally or locally in their own projects like for Atom or for Brackets and take advantage of tsc. So, I agree with Ward that--
WARD:
That's the compiler, tsc is the compiler--
JOHN:
Yup.
WARD:
And the TypeScript service is the thing that helps you learn about what's going on in your TypeScript and get information back, and it's an open API so if you're editor is very good at interacting with other language services, then it should be able to take advantage of the same kinds of hooks that Visual Studio Code is leveraging when it talks to TypeScript service. That's part of the design goal. They're dead set on making sure that every tool that's out there that can take advantage of the service has access to it. I think that the story has the potential to be a really good one for whatever you choose.
JOHN:
Yeah, and I don't think it means you have to go this route up, obviously, and I'll bet that there's editors that don't have the support because there's so many types out there. But if you think about people who don't use Visual Studio because-- Joe, I'm in Microsoft world, but I don't do Microsoft coding as daily basis anymore; I'm doing a lot of open source as well because that's the demand that I'm seeing-- but if you look at the people who don't use Visual Studio, the one thing they do is they know about it, they know it exist, and they hear that it's great because they hear worst like IntelliSense and auto-complete and things like that. Other than that, they think of this big tool that, "I don't have time for it, I'm going to use my Sublime." But, wouldn't it be great if they will say, "Hey, if I could get just those couple of features in my existing tool..." nobody is gong to switch an entire tool to an IDE (maybe some people wlll) to try out that stuff. What I see more frequently is if somebody really likes the editor they're in, they don't have to switch. They can just pull in TypeScript support. They can pull in auto-complete. That's why the package managers for things like Atom and Bracket and WebStorm and VS Code have become popular; there's all these open source packages and plugins that you can extend to the tool that you want. So, you don't have to go find the tool that you like; you can stay with the tool you like already and just pattern more packages to it.
WARD:
I think this is also one reason why the Google team decided to abandon their own private language, their scipt language because probably--
JOHN:
Thank you.
WARD:
Yeah. Let the rest of the world handle that one. I'm seeing other frameworks besides Angular that are seem to be getting on the TypeScript bandwagon. I believe that Aurelia is converting their code. I don't remember specific, but I thought I remember seeing that they were converting their code to TypeScript as well so that they could take advantage of this whole toolchain. So I think it's got a real potential.
JOHN:
We're getting closer to the end of the show here. I'd like to make sure we've got some learning lessons to people that we seen here. I know I've learned a lot the last couple of weeks and months. Lukas, why don't we start with you. What have you learned about going down this road with ES6 and Angular?
LUKAS:
I started programming, actually, with ECMAScript 1 and then we went to ECMAScript 2 and 3, which was very similar to ES4 which I have forgotten over the last couple of years. But now, it's interesting to be back into a classical paradigm. I think, thinking in terms of classes and constructors is a bit new for me again, but honestly, the biggest thing that I would call out if you're moving in this direction is take a moment to really learn the build system. For instance, Webpack is stilll a bit of a mystery to me. Fortunately, I had Scott Moss to hold my hand and help me through that. But like every five minutes when I was getting started, I was like, "Scott, how do I do this? How do I do this?" Again, I think it's not so much just syntax, but I think it's the ecosystem, the pumping the ceremony that goes around that. Once you get comfortable with the hoops you have to jump through, then it really become second nature and you really ramp up your velocity. Even though you're going to take that hit upfront, once you understand the tooling, it's actually much, much better.
JOHN:
That's a great tip. Joe?
JOE:
I would say the main thing that has come out from me has been the inability to appreciate the forest when you spent too much time looking at the trees. I feel like I've just been so deep trying to look at little tiny pieces of Angular 2 that I don't really step back so that I can get a better grasp of Angular 2 as a whole and appreciate it. I have a great appreciation for Angular 1, love Angular 1, and I'm looking forward to that taking an opportunity with Angular 2 when I can start building something bigger than just demo projects and starting to really appreciate it for what it is.
WARD:
I guess if I were to say what to take away from me is that, although, if this podcast goes to press, it's nowhere near ready for anybody who doen's have a lot of time on their hands to do anything with just that. The prospect for a solid framework are good and I feel much more comfortable with what is going to happen here in Angular 2 than I did back when we met long ago. I should mention by the way that it's very hard right now to get online information about the state of Angular 2. You wouldn't really want to make much out of the current Angular.io documentation because it's frozen in an old state and is, as I understand it, it is being reworked. So although you know you just can't, unless you got time to burn, you're just not ready to go jump right in the second. But, I'm getting much more encouraged about the prospect for something we can feel good about by the end of the year.
JOHN:
I have a few learning lessons that I'd like to ravel. I guess these are our tips, aren't they, for the show. The first one is, I would pile on what Joe said. I feel like there's times when I've been trying to dive deep into Angular 2 features really to understand how does that thing work. I've really beat head against the wall. What has really helped me is to say, "Stop it." It doesn't matter how that thing deeply works, maybe it does, but the more important thing is how does that work in a context of an application. So I changed my direction and said, "Instead of trying to figure out each individual piece, let me go ahead and build a puzzle." And I've been trying to build sample apps and demo apps. If you're interested, you can see the evollution of these things up at my GitHub repos at github/johnpapa. There are all various dates and to me, it's been very helpful to see how the different pieces interact with each other and how I use that. That's been a lot of fun. The real thing surprised me-- it shouldn't, I guess, since I wrote the style for Angular 1-- is it's been immensely helpful for me to start developing my own conventions for naming of things for files, folder structures, names of components and classes, and just general conventions on how I write the code. It's been helpful for me to do that with the Angular 2 stuff to see some patterns that I can pick out for what kinds of things I have to do when I'm building these components. It doesn't mean that I'm really, really [?] by any means smart, but it's been helpful to at least start to drive these kind of conversation to figure out how do you build real application with this.
WARD:
And you actually-- you have, behind the scenes, you have been evolving prototypes for the starndards for the style guides that will go with Angular 2. There's no question about it. Every step you've been taking, you've been looking at it and saying, "Okay, step back. As an application developer, how would I want my projects laid out? What would my folder start should be? What would I name things? Where would they go?" You're starting to do all that stuff right now, and I think you're coming out with good answers.
JOHN:
Yeah. We will see how it turns out. I think we should do another follow up on this in maybe a month or two months as well and see where things are.
LUKAS:
The follow follow-up.
JOHN:
[laughter]
JOE:
Let's move on to picks. John, do you want to go first?
JOHN:
I have no picks. You can skip me. [laughter]
JOE:
Alright.
WARD:
This is a long show. I hope it was worth it for people. I have no picks and I think people would be greatful not to hear them.
JOE:
Awesome. Lukas?
LUKAS:
I do have a pick, and that is Pascal Precht. He's just been killing it on the Angular 2 content lately. If you go to blog.thoughtram.io, there's a ton of really good Angular 2 content out there. I've really been enjoying it. If you [?] into some kind of meteor, then just a 5-minute quickstart, I think this is the place to go.
JOE:
Cool. I also don't really have any picks, although, I will reiterate the announcement about ng-conf. Tickets are going on sales, September 22nd to the winners of the lottery so lottery tickets are available now. After the 22nd of September, lottery tickets are still valuable because there will be more tickets being disseminated for quite a while after September 22nd, probably for several months.
WARD:
Excellent.
JOHN:
I think it's going to be one of the first big Angular 2 conference. It's what I would hope and pray.
JOE:
Yeah.
WARD:
I've entered in the lottery under several different pseudonyms so I'm hoping I get lucky.
JOE:
[laughter] Yeah, all duplicate entries are going to be removed.
WARD:
Oh!
JOE:
Yes.
JOHN:
[laughter]
JOE:
But one thing we are doing, along with what John said, we're not doing the CFP yet because we want to have very relevant content. So the CFP will actually have in quite a bit later.
WARD:
CFP?
JOE:
Call for proposals.
WARD:
Wow.
LUKAS:
I thought that was call for pants, which is why I did MC Hammer pants last year.
JOE:
[laughter]
WARD:
I know. I was looking down and I see your pants.
JOE:
Yes.
JOHN:
Lukas, you're still on how you take your pants over the last ng-conf.
LUKAS:
Yeah.
[laughter]
JOE:
Alright. Well, thanks everybody again for coming. It's a great show. Thanks everybody for listening in. We'll see you next week!
JOHN:
And he's out.
[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!]