02:27 - Alex Eagle Introduction

02:54 - Jonathan Turner Introduction

03:30 - What is TypeScript?

04:40 - Google + Microsoft = <3 (Angular Adopting TypeScript)

07:18 - TypeScript Accommodating Angular

09:28 - Surge of Interest in Adopting a Typechecker, Type System

14:21 - Angular: Creating a New Language

16:46 - The Angular 2 Component System and How it Uses New Annotations for Classes

18:01 - Annotations and Decorators

22:06 - TypeScript and Babel?; Adding New Features

25:25 - Non-Angular Users Adopting TypeScript

34:55 - Tooling and Setting Modes for Linting and Static Analysis

36:58 - Using Libraries Outside the TypeScript Ecosystem

38:11 - Type Definition Files

40:15 - Content of the Type System

43:19 - Duck Typing

45:12 - Getting People to Care about TypeScript 

49:16 - The Angular and TypeScript Relationship

Picks

f.lux (Aimee)
Jafar Husain: Functional Programming in Javascript (learnrx) (Aimee)
Startup Timelines (Jamison)
Friday Night Lights (Jamison)
React Rally (Jamison)
Evan Farrer: Unit testing isn't enough. You need static typing too. (Dave)
AngularConnect (Joe)
ng-click.com (Joe)
mdn.io (Joe)
Sonic Pi (Chuck)
Error Prone (Alex)
AudioScope-ng2 (Jonathan)
The Nintendo World Championships (Jonathan)

Special Guests: Alex Eagle and Jonathan Turner .

 

I want to start a programming language called Type, and that way, people can say, "Is TypeScript like Type?"

Hey everybody and welcome to episode 167 of the JavaScript Jabber Show. This week on our panel, we have Jamison Dance.

Hello, friends.

Aimee Knight.

Hello.

Dave Smith.

Hi, everybody.

Joe Eames. I'm Charles Max Wood from DevChat.TV. We have two special guests this week. We have Jonathan Turner.

Hey.

And Alex Eagle.

Hello there.

Do you two want to introduce yourselves?

Sure, Alex, do you want to go first? I mean, alphabetically, you come first.

Okay, yeah. That's been that way all my life, yeah.So my name's Alex Eagle. I work at Google, I'm on the Angular team. I started at the beginning of this year, after coming from a few years doing developer tooling at Google, mostly around build, test, and release. So I have a lot of background in developer tooling. And now, I've been working on the TypeScript migration and TypeScript tooling for Angular.

Cool. And I'm Jonathan Turner, I'm the program manager for the TypeScript team. I started that right before we went public, so in 2012. I've been doing that for the last three years or so.

Now you'reat Microsoft, right?

That's right.

Okay, I was just making sure you both weren't at Google and my mind hadn't gone whoa!

So Microsoft and Google are friends?

I thought that was the more mind-blowing part.

I guess that's the other mind blowing part, yeah.

I guess bothcompanies are made of people, so people can like people.

Can you talk about how that came about? Well, actually, before that, you should talk about what TypeScript is.

Sure. So TypeScript, I guess the kind of the rundown that we always kind of give is, TypeScript is a typed superset of JavaScript. It's just based on the standard JavaScript language that everyone knows and loves. And on that, we have a couple of additional features. So it used to be back in 2012, those additional features were things like ES6 features, like classes and modules and arrow functions, but now everyone has those, right? So the superset includes features from ES7, so future versions of JavaScript, those kind of features.

And of course, TypeScript, in the name, types. You have this type system that you can use to find bugs and get good tooling in your code. The TypeScript type system is a bit different than a lot of type systems because it's optional. You can use it in places that you want type checking, but there's also ways to turn it off, so you can use what's called the Any type and turn off the type checking. So those kind of features together, the type checking and being able to compile JavaScript down to earlier versions of JavaScript kind of is what TypeScript is.

So TypeScript has been around for a few years, I feel like it was the first typed JavaScript dialect that I was familiar with. Can you talk about the journey to Google and Microsoft kind of joining forces on it?

Sure. I think probably the one to precede us was the Google Closure compiler. You could put type annotations in comments. The TypeScript syntax is a little bit simpler, you can write the type annotation directly beside the variable or beside the function parameter. How did we get started on our journey of the Google and Microsoft working together? Back last year, around ng-europe, I think just before ng-europe, we got on a phone call with the Angular team. At that time, Rob Eisenberg was kind of helping out with the Angular2 project and had suggested...it sounded like the kinds of things that Angular2 needed to do good tooling, there was a lot of emphasis on being able to do a good tooling story for Angular2. And, of course, what TypeScript already cared about, which was tooling. He was like, "You guys should really just get on the phone and talk to each other, and see if there is a good overlap in what one side can provide and what one side needs."

So we started talking around October, November last year, if I recall right. At that time, they were well on their way to creating this thing called AtScript, which was ostensibly a superset of TypeScript, just like TypeScript is a superset of JavaScript. So we flew down and talked with them for a while about, can we take the features and the philosophy of AtScript, and can we fold that into what TypeScript can do? How much do we overlap? And if we overlap enough, it seems like this is kind of silly. Let's just take those features and that capability and make TypeScript be able to do that. And that's kind of how things got started.

So this is like the opposite of the XKCD problem where there are 15 different versions. And when someone finds a problem, they're like, "Oh, I will make a sixteenth version, and the sixteenth version will solve all the problems.”

There's actually an interesting blog post where the guy basically referenced that same cartoon and talked about the same thing. You never see consolidation of tools in the JavaScript world. So when it does happen, it's worth trumpeting over.

Yeah, yeah. It's pretty exciting, actually.

Yeah, and thank goodness, because even though the Angular team is very high-output, it would have been a big challenge to make AtScript something that everybody could use and get all the right tooling around it.

Oh yeah.

And Misko's an ambitious guy, and I wouldn't put it past him, but I think we're all really fortunate that we were able to convert it completely to TypeScript.

So how did TypeScript have to change in order to accommodate Angular's needs?

There's a couple of features that AtScript added to the kind of thing that TypeScript already did, which was the type checking piece of it. One of them was what we’re calling at the time ‘annotations’, the ability to put metadata onto your functions and your classes. When we started working on it, that was one of the first ones we tackled. I sit on TC39 sometimes, that's the JavaScript standards body, and I knew then that Yehuda Katz, who you may know. Have you guys interviewed Yehuda yet?

He was one of the original panel members on the show.

Nice, nice. So yeah, I knew Yehuda was already working on something similar for the ES7, so we're like, "All right, Yehuda, why don't you and us work together on this?" And Rob Eisenberg, who I mentioned earlier, also was thinking about, how does this work with his new framework called Aurelia?

So we started brainstorming, and we dug up Yehuda's old notes, and we looked through the things that Angular2 was going to need, and we said, "Well, there's enough overlap that we think it's just one feature we're trying to describe. We just have slightly different philosophy on that." And it took us a little while to settle on something that would do the majority of the cases for both groups. But there again, I think it's one of those, instead of making two separate standards, we worked extra hard to try to make a single standard that worked for different libraries. So that was one of the things that we needed to add, so Yehuda and I have been working up the spec and working on TC39 to try to standardize this feature.

One of the other things that AtScript had was a runtime type system. You could take a class and say, "Give me all the dependencies, so I can do a dependency injection. And I want to know all the types of all those dependencies, so I can make sure I instantiate it correctly." So we were also working on things that you can do that in TypeScript. It's a little bit more experimental, because there are some limitations to how it works, but you can get some of that same functionality.

Since we talked about, like Jamison said, TypeScript being around for a while, and I see that it has been, and this is probably going to get into another library that we talked about before, but what do you think the surge in interest has been in getting something like this into JavaScript? What is driving that?

The surge of interest around getting something like decorators?

No, just like a type checker. We were talking about how Angular had included now TypeScript instead of AtScript, and then a couple episodes in the past, we had Flow. Coming from someone who's a little bit newer to this, I'm curious what the surge in interest is in having something like this in JavaScript.

Sure. I think there's a couple of factors. I wouldn't say I can put my finger on one thing that was causing this, but I think a couple of them; one would be people are writing larger and larger apps in JavaScript, and so it's kind of handy to have the type checker be a lightweight set of unit tests for you. So these are unit tests that you can just sprinkle in your code, and the compiler can do a set of initial tests for you, so you don't have to take extra time and write the unit tests. So there's some nicety there, having a better tooling story. For example, if you spend a lot of time in vi or TextMate or something, and that's where you do most of your writing, maybe you don't have experience with AutoComplete and being able to do really smooth refactoring code navigation. But people coming from editors like Eclipse or Visual Studio, it's nice when you get used to that, you want that to translate whenever you move to a new language. So moving to JavaScript from something like Java or C#, you want to be able to still have that nice tooling experience. And I think TypeScript lets you straddle those two sides. So you're still writing in JavaScript, but you can give the IDE just enough information that it can give you good refactoring and good error checking and navigation at the same time.

One thing that I've seen with TypeSystems and the arguments for and against is that it's really convenient to do things with duck typing. So instead of expecting a particular type, say it has to be a number, or it has to be a particular class, as long as it implements the interface that we expect. And I know I'm setting things up nicely for an argument from TypeScript, because I went and played with it, and I was like, "Oh, that's really cool." But anyway, we kind of rely on the interface to give us our typing, as opposed to explicitly checking to see what it is. So why do we need a TypeSystem, or when is the tradeoff worth it? And what does TypeScript give us that allows us to do that kind of thing?

Sure. I think that line is going to be different for different people. Some people want that error checking and want that extra confidence earlier rather than later. Some people feel like the unit tests are plenty, and that's fine. I think that kind of variety is great to have in the community. We should always have that kind of variety. Like you're saying, though, TypeScript does give you a lot of stuff that maybe a lot of TypeSystems generally don't, so you can do something that's more duck typing. I can just say, "As long as the object that you're passing me has a field called 'name,' that's good enough," and that's the only thing I care if the type checker checks. And you can describe that in the TypeScript TypeSystem.

Yeah, I think that's really critical. One of the things that's been most useful to us on Angular about using TypeScript is that we can very incrementally move our code over. In our case, we were moving over from AtScript, which is pretty similar, but even for some of the other projects we've worked on, the ability to say, "In this spot, we're expecting something with a name," without having to go and find all of the call sites and change the types there, or declareanything on the types there, is really powerful. And of course, then if you renamed "name," or if you said, "Oh, I'm expecting 'name' and also 'address’," then the compiler can help you to see all of the call sites, whether those two properties are available. And then you discover, "Oh, I thought I had 'address' on everything I was passing into here, but it turns out, in this spot I didn't."

One of the other things that we're doing more recently, to the earlier question. Not just annotating types on your functions or parameters, but inside the function you might say something like, "If X is an instance of something or X is a type of something," in that if check, I know if it's an instance of a particular class, or I know it's the same type of number. So let's just have the type system know that, just because of the context that it's in. So we're starting to add stuff like that, more natural JavaScript patterns. You can do more and more flexible duck typing, and then inside the function body, you still get good type checking.

Can you talk about the thought process that the Angular team had around creating a new language? To me, the idea of solving a problem by creating a new language is scary, because I don't have a background in compilers. But how do you decide whether it's worth it in general, where you say, "This problem is large enough that we'll spend a bunch of engineering time on this thing that isn't our core problem, but it will help us solve our core problem." Does that make sense?

Sure, yeah.

Actually, related to that, there was that thing on Hacker News recently about FogBugz, and then moving away from their proprietary language, so it's kind of a theme that's come up lately - the tradeoffs between creating your own language and not.

Yeah, I wasn't on the team at the time, my secondhand understanding of it that I can relate is that, with Angular2, the team is taking a little bit wider view of the problem, and a lot of the issues that people had in using Angular 1, we would like to solve, whether or not it's typically within the framework's boundaries. For example, providing a CLI tool to help you get your build process bootstrapped isn't something that shipped with Angular 1, and that's something that we would like to work on for Angular2. One of these kind of problems was what do we do with really large-scale applications? As Jonathan pointed out, there are now a number of very large applications at both Google and Microsoft written in JavaScript, and it's hard for a large distributed team to be able to reason about and safely make changes to that code base. So while it may not be important for a small-scale quick prototype kind of application, as you start to climb this maturity ladder in how long you want your application to be able to live, we found that it was really important to be able to specify types and to declare metadata in a really clean way that's more maintainable and more readable.

So I think, if you think of it as use case-driven design, the use case here was somebody writing code in Angular2 really needs to be able to express it in this way. So at first, writing a new language, as you say, it's not typically a good idea, and the team was able to do it pretty quickly, because we were using traceur as the ES6 to ES5 compiler, and so by simply extending traceur, we were able to add support for the sprinkle of new language features that we needed. As far as developing Angular2 itself, doing that in AtScript was pretty doable, but of course, making AtScript available for everybody else in the world to use, there's a lot more work to put into that. I think that's where it would have been impractical, and so the idea of making a new language, fortunately we didn't have to follow through on it.

Would nowbe a good time to describe the Angular2 component system and how it uses these new annotations for classes specifically, to decorate them and declare them and then make them useful for your application?

Sure. I'm not going to go into that in too much depth, as far as how to wire together a whole Angular2 application. I think there are probably better resources for that, but specifically for using the TypeScript language features. So the idea is, to declare a component in Angular2, you do that with an ES6 class, and there's the metadata that you want to be able to attach to a component, like what HTML template should be used to render its view. So we have a view decorator, you would say @view above your class, and you would be able to say where the template is, or you can specify the template inline. Something like ES6 string interpolation literals are great for that.

So specifically we're talking, this replaces the .directive function, where you used to register directives in Angular 1, right?

Yeah, I believe so.

Can you talk a little bit more about the annotation? Isn't that related to decorators in ES6? I'm a little fuzzy on that specific feature of ES6.

Yes. Jonathan was touching on this earlier when he mentioned that there were a few different use cases to take into consideration. For most users, you can't see the difference between what we call a decorator and what we call an annotation. They're both an @ sign followed by some identifier, followed by parentheses, followed by some arguments, but internally, there's a difference in what's a valid expression to put after the @ sign, and also how it gets evaluated. So decorators is the thing that will become, hopefully, part of the ES7 standard. And annotations are in Dart, and since Angular2 compiles to Dart as well, internally we have to be able to talk in both annotations and decorators, but for everyone using it in JavaScript or in TypeScript, decorators is the thing that you will use.

What about the difference between annotations and decorators?

I think at this point, it's probably more helpful just to think of everything as decorators. The ES7 decorator proposal allows you to do things like attach metadata, which make it feel more like what AtScript would call an annotation. So I just have an @ sign, and that invokes a function, but the only job of this function is to stick a little bit of metadata on the class or whatnot. It's not actually doing anything that would change the class behavior at all, and so that's kind of the more declarative that annotations are. Decorators are a little more flexible, they can do more than just attach metadata. But the standard is just the decorator piece, being able to describe doing that, and then we're also working on extensions to the metadata API in TC39, so that we can describe, "Okay, so you call a decorator, but then how do I describe what the decorator is doing when it's attaching metadata?" That's another thing we're trying to standardize.

So is it fair to call annotations a subset of decorators?

If you say that, Misko will kind of look at you funny. [Laughter]

For people who aren't Misko, is it okay for them to think of it that way?

I don't think that anybody will need to use the word "annotation," so we should probably just strike it from your vocabulary, unless you happen to use Dart. Decorators is the thing.

I think it's funny, because in Angular2 there was supposed to be this thing called decorators, but once the naming committee for TC39 picked up decorators, then they wanted it to be annotations, it became decorators, so then they actually had to pull something out of Angular2.

Yes. The namespace for names in Angular2 is hotly contested.

Yes.

We've had whole meetings about what "viewport" is.

It's like domain squatting almost.

Yes, it is, exactly. It's too bad that there's only a single namespace for us to choose from.

And that namespace is English, right? [Laughter]

You'll have to start picking Japanese words.

No, it's not just English, it's sensical words from English.

Not to harp on decorators and annotations too much, because I understand it's a nuanced topic, but are decorators as proposed and as implemented by TypeScript, are they closer to Python decorators, or closer to C# annotations?

They're closer to Python decorators in spirit. This thing is powerful enough that it can replace the declaration of the thing that you're decorating. So I could replace a class, and then it comes out and it does something different than it came in doing. Or a function expression could come out different. It could call into a log, do a log thing, and then come back to your function, or not even invoke your function. So it's pretty powerful.

I really, really enjoy Python decorators. Super powerful, and you can implement the concept of annotations with them, because they're powerful enough to do that, right?

Yes, that’s right.

Yes, and I believe that Angular doesn't have an intention of using those kinds of meta-programming features. For us, it's only declarative metadata that we intend to use decorators for. But obviously you, in your application, if you're writing in TypeScript, you could make your own decorators and have them do more of the meta-programming kind of things.

So we've talked a little bit about the overlap between TypeScript and ES whatever, ES20XT6.

[Chuckles] Good one.

Can you talk a little bit about where the balance is between implementing these new features in TypeScript and farming them out to something like Babel? Not to get your hackles up, but we did talk to another typed JavaScript implementation, and one of the…

Don't tell them that! [Laughter]

They'll rage quit on us.

They're actually waiting on the line now.

Yeah, there we go. [Laughter, crosstalk]

And now they're in your office, and you have to arm wrestle or something. One of their big struggles was keeping up with the new developments in the language, because people are—if you're using pure JavaScript, you just get them when Babel implants them. It takes longer for them to implement them in their own language. Is there a way to farm them out to something like Babel, so you don't have to duplicate the work of copying every new ES-whatever feature into your language?

I think that's a great question that we're still kind of wrestling with ourselves, to be perfectly honest. The actual transpilation part isn't generally as difficult as coming up with a really easy-to-use TypeSystem that works with all the features, and so a lot of the time that we spend...So once we focused on getting ES6 features into TypeScript, it still took us a little while to be able to do that. But in large part, that was just design meetings around how to make a TypeSystem that really feels good as you use it; it doesn't get in your way a lot, but it still helps you catch errors and do all the things that a TypeSystem should do. The actual being able to transpile class expressions or whatnot down is generally not as bad. Things like generators actually can be a little bit hairy, but most features are fairly clean output. That said, though, I'm still talking with Sebastian and some of the Babel guys about what are ways that we can work together, and I think we're still going to continue brainstorming that.

That was a very diplomatic answer.

Yeah, that's fair, I mean...

I'm all about collaborating and trying to find ways that projects could work together, maybe that's my favorite thing.

I wanted you to say, "Yeah, you can do it today, and here's how. Press this button on your keyboard," but it sounds like it's more of a future goal.

You can, of course, use TypeScript as the transpiler, and you can do a lot of the things that you do with other transpilers. We just added, for example, system.js support, so you can transpile on the fly in your Web pages.

The tricky thing is there's always another feature, and I found that in keeping up with Flow. As soon as they implement one new feature, we're excited, and then we're just like, "When can they get this next thing done? Ugh." So I just want it all at once, I guess, is what I'm saying. I'm really impatient and ungrateful for all of your hard work.

That's fair. It's tricky, too, because there are so many things that we want to do. We get ES6, we're starting to wrap that up, and we're already hot on the trail of things like JSX support, that just landed, and we're trying to do ES7 features. So yeah, keeping busy.

We've talked a lot about Angular and TypeScript, and you just said JSX support, so how many people do you see using this not in Angular? I guess I'm asking maybe some naive questions, just because in the people that I talk to, it's just not hot on their list of things to check out, so I'm just curious.

Sure. So you're asking how many people outside of Angular users are using TypeScript?

Yeah, it just seems like the people I talk to who aren't using Angular, it's just not strong on their list of things to look at, so I'm curious how many people you guys see that are doing that.

We did a survey close to six months to a year ago, and we just wanted to get a sense for how people were using TypeScript. We knew that we don't have every user's phone number in our Rolodex, where we can call up everyone and ask them how they're doing, what they're doing.

Oh, I thought Microsoft had that.

[Chuckles] Yeah, that's right, that's secret feature we don't tell people about.A lot of people use it in internal development, so it sounded like over 50% of people were using TypeScript for internal development. So we're not even sure what libraries they're using it for or what systems they're using it for. I can tell you a lot of big-name software and hardware companies use it, a lot of big financial institutions use it, and so I think, like Alex was saying before, there's just kind of a sweet spot. If your team grows to a particular size, there definitely gets to be more and more interest in "How can we manage a larger team or multiple teams working together on a project that's largely JavaScript based?" Does that kind of answer the question?

Yeah, somewhat.

I [cut] TypeScript, and I think it's great, Aimee.

I've just read in the channel, I think I've been brainwashed maybe by people around me who...I don't know, when I Google, though, I feel like a lot of, and I guess I'm playing devil's advocate a little bit, but so many people who just want to stick with ES6 and Babel. And then if they want, they could add Flow on top of that for things. Just trying to make you guys have a good argument for why people should look into this if they're opposed right now.

Sure. I think it's funny, I'm almost going to do Babel's job for them. Babel basically just comes out and says, "Look, if you want vanilla JavaScript and you want to write it today and use all of the new features of JavaScript, use us." And that is a very clean, straightforward story. You're just, "Oh, yeah, I can just use JavaScript, I can use Babel, and then it's good." With TypeScript, you're basically saying, "Oh, there's additional things I want. I don't want just compiling down clean JavaScript. I want these other things that TypeScript provides."

Yeah, definitely.

I have to say, though, that one thing I see is, I see people that are still on the ES5 bandwagon that are like, "Why should I change at all?" Because as soon as you move to ES6, then you have to have a compiler, and you have to have this tool chain.

That's not really true, though. Modern browsers can run ES6 just fine, right? [Laughter]

As long as all the users are on Chrome.

Not quite yet.

But no, it's coming, and you can always look at the compatibility table and judge which ES6 features you imagine your target users will have, but it's a risky approach to take.

To further try to sell people who might be opposed, what about using this on a project that already exists? Because I've also heard the argument, "Well, if you already have the project that already exists, it's just going to be too hard to go in and do that." So I know you guys said at the beginning that you didn't think that was a problem, but...

Sure. Just to kind of sanity check, this morning, actually, I took a project and moved it over from JavaScript to TypeScript. I grabbed the latest Bootstrap and said, "All right, let's say I don't know much of anything about this—"I actually didn't know how Bootstrap was structured when I grabbed it, I just grabbed it and said, "Okay, I don't know anything about this project. Let's just pretend I'm one of the Bootstrap developers moving to TypeScript and see what it feels like." And there's definitely a couple of rough spots as you get started, and I think people generally, if they try it and they hit a rough spot, and it just hits them wrong, they're going to be like, "Ugh, this is not worth it." For example, they have to learn a little bit about how the TypeScript TypeSystem works, or they're not going to be able to answer the compiler's questions of, "What type is this expression? I don't understand it." If you can get over that hump, where you're using a set of tools—In Bootstrap's case, they're built on Grunt, so you have to get the grunt-ts extension to build the TypeScript stuff in Grunt. Okay, that's not too bad. If I learn a little bit of the TypeSystem, I know just enough to shut the TypeSystem up when it's complaining about little bits and pieces, and in Bootstrap's case, I can just repeat myself. Once I understood that pattern, I could just repeat myself a few times, and then largely, things just started going through the compiler without any complaining.

Once I got to the other side of this, it probably took me—Once I got all the requirements for building Bootstrap down and I actually started the conversion, it didn't take that long. It was probably on the order of a little bit less than half an hour. So I've converted the lion's share of Bootstrap over from JavaScript to TypeScript. Now, at that point, I could open something like VS Code, which is our cross-platform editor, and I can open Bootstrap, all now written in TypeScript, and start working with it as a TypeScript project. And that's where it actually starts to see a lot of the benefits. I can give it a little bit of jQuery help, and now I have jQuery IntelliSense, so I can dot into $. and now I get all the help for what's in jQuery, for example. So that's where it really started to shine, but it takes getting over that initial hump to really start to see it shine.

I had some recent experience. This is actually a combination of Visual Studio Code that I was doing some testing, and man, Visual Studio Code automatically prompted me and said, "Hey, do you want to bring in the type library for Mocha and Chai?" So I said yes, and then all of a sudden I was getting all of this IntelliSense for how to do Mocha and Chai, and it was actually really cool. So that's one of the things that I like about TypeScript, and I will admit readily that I have not used it very much. In fact, I've used it very little, but I really liked that piece. And so, for people that are looking at TypeScript and saying, "Well, I'm not really interested," one of the things I really liked about it was, it's a very gentle—because it's a superset of JavaScript, it's such a gentle way to ease into using it and then slowly use it more and more if you want, or not use it at all. And you can use it just as a transpiler too.

Yeah, something we haven't mentioned is that it's even useful if the compiler is complaining, it will still emit your code anyway. So you really have a wide choice of options of how strict you would like the compiler to be and how much you want to turn the knobs and tighten it down as your application becomes mature. When you start, you can turn all those knobs to zero. And also, we didn't explicitly mention that there's a very large community that is creating the typings files, so you mentioned Mocha and Chai and how great it is that the IntelliSense just clicks on. That exists for a very large number of JavaScript libraries today, so you can continue using whatever dependencies you have, and in most cases you can just bring the typings in, so that your TypeScript code understands the shape of that API.

Now just to be clear, if I am testing, and I'm not using a system that does this for me automatically, do I have to compile my TypeScript before I can test it?

It depends, of course, what runtime you're using for executing your tests, but if you're running your tests in a standard browser that doesn't understand all the ES6 language constructs, then yeah, you have to transpile it with something for it to be runnable.

Okay.

It's true that there's no runtime actual interpreter for TypeScript, right? TypeScript always compiles to JavaScript and then is executed by the browser or by whatever JavaScript runtime you're using, right?

That's right.

Yeah, I wouldn't be surprised now that TypeScript has the system.js in it, if we don't see some of the testing frameworks being able to support bringing the TypeScript files into the browser and transpile them on the fly and make that a little bit more seamless.

And I may not have been clear about thiswhen I was talking about my example, but one of the funny things was I wasn't actually using specifically TypeScript. I was just taking advantage of the type definition file and Visual Studio Code's integration with it. So I wasn't actually using a TypeScript compiler. I think I was actually using Babel, or I was using nothing. But I was able to take advantage of the under workings of TypeScript and give me that IntelliSense into Mocha and Chai without actually really, truly using TypeScript, which I thought was completely cool.

Actually, VS Code has this cool feature where you can just be working on a JavaScript file, and then as long as you have the TypeScript type information lying around, so I think it sounds like you pulled some of these d.ts files from DefinitelyTyped, and as Alex said, it was like—

Yeah, it prompted me. It knew what I was dealing with. It knew that I was using Chai, and it said, "Hey, do you want to grab that Chai type definition file and bring it local so that we can use it?" I just said yes.

Sure, yeah. It's pretty cool that you can just stay in JavaScript, and as you call into those library functions, you get all the help. That's kind of cool.

So speaking of tools, this is something that AJ asked, but it's something I want to know about too. Mainly because I use a real text editor, I don't use Vim, I use Emacs. But he asked, the linting static analysis process is more than just profile analyses. To analyze your main app.ts pretty much requires analyzing every file you require. So how do you conquer that for tools like Vim or Emacs?

There's a couple ways that you can set the modes in the compiler. You can set it so that it will track down through all of your imports and anything that you reference, and then type check everything that it can find. And that's kind of the default mode, because for a lot of people, that's the mode you want. You're pointing at a file, and then that file represents the start of your project, and it's going to go find the rest of it for you. You can turn that off, so the compiler can be set to not track all its dependencies or all the references, but generally, that's a little bit more advanced, because you kind of have to know what you're doing at that point. But you can get into those extra modes.

Yeah, I was just going to say, typically, where you want the linting and static analysis is for things like your syntax highlighting and auto-complete, things like that. So if you set those up in Vim or Emacs, it's nice to have tools that can just tell you where you're at and what you're dealing with.

Yeah, that's right.

Jonathan didn't mention that one of the great things, I think, about TypeScript is that they started from the beginning with understanding what tooling was going to be required, especially in editors. And so TypeScript itself provides those TypeScript services, which can run and serve as a daemon that understands your code. It sits next to the editor, so the editor integrations are really very slim, and it just says, "Oh, the person hit whatever the keystroke is for completion, just ask the running TypeScript language services, for this symbol, what are the available completions." And that TypeScript services daemon can keep the state of your code and incrementally update. So depending on which editor you're in and how well that plugin has been written, maybe there was a case when you were trying it in Vim that it wasn't actually keeping that state around, and that was why it felt slow, but that's not how it should be.

Yeah. The other question AJ had was also somewhat related to this, and it was, "Most of the time, I'm also using libraries outside of the TypeScript ecosystem in my JavaScript. So I'm assuming that's other JavaScript libraries that aren't written in TypeScript. How can I use those without having to deal with dozens of errors each time I bring one in, or do I just have to clone the whole definitely typed repo every time I want to start a project, and hope that the lib I'm using there is in there?"

So with DefinitelyTyped there is quite a lot, but if it's something where you're like, "Oh gosh, I just don't even want to have to find this thing," let's take jQuery. I just want to start calling things off $. At the top of your file, you can say "declare var"and then the dollar sign, and that will basically say, "Yes, I promise you, compiler, there's something in the global namespace called $. Every time I call it, just leave me alone."And that way, you can shut up large swaths of type errors by just promising to the compiler that "Yes, there is something there. It will be available at runtime."

We've made use of that a lot too, if we have something that's just declared on the global object or on window. Since interfaces are open in TypeScript, at the top of your file, you can just say "interface window" and then declare a couple of extra methods or members, and that also makes the compiler happy.

I have one more question about the type definition files. For me, that part was actually a little frustrating, because the type definition files are great, it's great that there's this large repository, but it felt like it was painful to integrate them with my project. It was like going back to good old 2009, where you just copy and paste some code into a file in your folder. Is there a way to manage those like you would use npm to manage your modules, or something like that?

Yes, there's a program that's very much modeled after npm called TSD, which is TypeScript Definition, and it uses the Github repository called DefinitelyTyped as the package repository, and then you can have a JSON file locally in your project that indicates which of those typings you want, and it will pull them down. You can add a command in your package JSON that says, "Whenever I do npm install, I also want it to run the TSD program to make sure that my local typings are in sync." And so in Angular, we use that tsd.json file to keep the typings directories in sync across all the developers, and for the continuous integration to have the typings present.

Cool. Does that import them into the namespace as well, because I remember there was a little bit of stuff you had to do to point to where they were.

Right, so there's a couple of options. The TSD program creates a bundle file at the top level that just includes everything that you've brought in with TSD, so you could point your TypeScript files to that bundle for the definitions. A better option now in TypeScript, when TypeScript 1.5 is released, is that you can use a tsconfig.json file, which again is checking configuration and is a much better way to share this among your developers than for everybody to have their own local settings. And that file, as long as you've listed the type definitions in there, then you don't have to reference them from your sources at all. And the compiler will know to look at that config file and pull in all the libraries and all the dependencies that you need.

Cool.

Yeah, so we're using that stuff pretty heavily on Angular, and we're following the development of TSD to have a little bit of a future road map planned to add more of the things that we would like to see there. So yeah, it's really cool. And we're obviously publishing Angular's type definitions to DefinitelyTyped.

We haven't talked a ton, we kind of mentioned it in passing, but we haven't talked a ton, I feel like, about the actual content of the TypeSystem. I feel like a lot of people might have played with Java or C++, and some of those people might hate typed languages because they hate the TypeSystems in Java or C++. Do you want to talk a little bit about how TypeScript is different and better and magical?

Sure. Speaking of things to go watch, I was just thinking, I just talked a little about this in the Angular U talk, and they just posted those videos. So if you search for Angular U and my name, I think you should be able to get some of this. But the gist of what I say in that talk is that TypeScript's TypeSystem is a much more modern TypeSystem than things like Java. Not to pick on Java, but you know, it is a little bit long in the tooth now, and that's fine. But in Java, you had to repeat yourself a lot. I had to say something like "MyClass c = new MyClass" and blah, blah, blah. I'm like, "Why am I having to repeat so much? You can infer so much more about my code than you're letting on."

So in TypeScript, we do a lot of inference, so you can infer...For example, if I say "var x =" and then I give some expression, we can calculate the type of that expression and then say "All right, you created a variable with that type? Done." You don't have to say it explicitly, we can just infer from what you've initialized it with. We can go a step further, so for example, let's say I'm calling a function and that function takes a callback. When I pass the callback in, I'm typing that callback into my editor, we know the types of the parameters, because we know, let's say, the type of the callback. So that type information can kind of flow in multiple directions around your code. You don't have to type the type as often, it can be calculated by the compiler and let you muddy your code less and less with type annotations. So there's that piece of it.

We were talking about things are more structured, like "if it walks like a duck and quacks like a duck, it's a duck." We can just talk about just the little bit of structure that you require without making a whole class hierarchy and all of the gobbledygook that you're used to from things like Java. You don't have to do that, everything is really lightweight when you're saying, "Okay, here's just the pieces I need." And I kind of hinted at it before, but you can also use this thing called any, and any says, "I can be any type whatsoever." If I assign to an any or I assign from any to something else, don't check it. So it's a good way to kind of jump in and say, "All right, I don't know how to type this correctly." I'm just going to say "Boom, you have typed 'any' and that's it. Don't say anything else." And so I think it's important that the type checker helps you when it can come in and help you and error check, but it's also important for it to get out of the way when you don't need it there, so you can do your work.

So you mentioned the word "duck" in there, and I know earlier Chuck mentioned the word "duck" as well, so Duck Typing, as I understand it, is the idea that you don't have to declare an interface in order to implement an interface, but rather, the language can divine, based on what methods you're calling and things you're doing to an object, that whether or not it conforms to an interface, without actually having to have a first class interface declared. Python does this at runtime, Go does thisat compile time, Java doesn't have this at all, to my knowledge, you actually have to write the interface. What does TypeScript do with that? Or does it support that at all?

It does a little bit of one and a little bit of the other. Just like in Java, you can do an interface and fully write out the full interface, and then as long as something explicitly implements it, you can use it. In TypeScript, you can still use interfaces, but what you're talking about is the structure of that object. So as long as something matches, an object has at least what that interface says, then it succeeds and it goes through. Instead of writing a whole interface, you can just do what looks like an object literal in the place of the type, and say, "All right, as long as it has a particular field, that's good enough." And what I was kind of alluding to earlier, you can just elide that all together, and then in the function body you can say, "All right, if the type of x is a number, then treat it like a number." So in that case, you're just going from knowing nothing about it to doing a simple type check, type test, and then that's enough to say what the type is. So you have different levels of—yeah, go ahead?

Is that "if" you're talking about, is that a compile time or a runtime check?

That last one is a runtime check, but the type checker understands it and says, "Ah, I understand the form of 'if' that you're using, and that 'if' is something that's like a type check. So I'll assume, inside of this 'if' body, that I know the type of the thing that you're checking.

There's one more thing I want to go to, and I think we've talked a lot about it, but I just want to call it out explicitly.There were a lot of questions about, "Well, what about these naysayers and what they think?" But I think the biggest problem that TypeScript and a lot of the other technologies that we're talking about face are really just getting people to care in the first place. Giving people that place where they see TypeScript or some other compiled JavaScript language or some build system as a necessity to their system and recognize that it's going to solve certain problems for them. So how do you explain to people what TypeScript is in a way that tells them that they need it?

For me, I think the way is like, "You need it if you want it."

Yeah, how do you do the same thing with ES6, really?

Yeah, like, "Do you need to use classes?" "No, no, I just use functions and closures." Okay. Right?

That's totally cool.

I would love to talk about this for a minute. Earlier, you mentioned that you use a real editor, rather than Vim, and with editors, we're all used to this sort of religious battle where everyone has their favorite and they don't really care to change that.

Yeah, I always say that kind of thing tongue-in-cheek.

Right, but we all have preferences. I work on a Mac, I don't usually use Windows, and some people usually use Windows and they wouldn't want to work on a Mac. We make these choices, and we kind of associate with them. But I feel like, as a software engineer, as you go through your career, you eventually are sort of forced to accept that it doesn't benefit you to take a stand on something like "Is more tooling better or is less tooling better?" And I think a much better way to think about it is, "How much tooling do I need to make myself productive and happy today, and also to make myself productive and happy tomorrow?" So if I'm writing an app that I expect to throw away, I'm throwing something quick together so that I can show it, and chances are people aren't going to like it, then of course you do no tooling, you do no unit testing, you don't need a compiler to do type checking, you turn all the knobs to zero, including use ES5. As you expect you're going to write a larger amount of code and it's going to live longer, then that immediate speed of execution starts to trade off against having to do maintenance work on this legacy code in a year or two from now. And in that case, you're really happy if you had tooling there to help you avoid making simple mistakes because you simply don't remember this code base anymore.

And so I think, just like somebody says unit tests are a waste of time, that's true for the first kind of app, and it's definitely not true for something large that you intend to maintain for a couple of years. I think adding typings, as Jonathan said earlier, is kind of a form of unit testing, the compiler is this tool that's telling you whether you did the right thing. And there are a lot of other tools that you can add, continuous integration and release tooling, that there's a right time and a place for that. If you think in terms of your risks, your risks are shipping a bug to customers or not being able to edit this app and having to throw it away and start over. You want to cover your risks without slowing yourself down.

Yeah, that makes sense.

I'm just not smart enough to understand my program, so types help with that. Something smarter than I am will check that some of my assumptions are correct or incorrect.

Yeah, it's like a note to yourself in the future, too.

Yep. I don't remember where I put my wallet five minutes ago. I'm not going to remember what this weird argument in the fifth position of this argument list is, that only gets used if the moon is aligned correctly or something.

That is a fantastic example.

I wonder if some of the people who are against it are the same people who don't think that they need to put comments in their code.

Or who never lose their wallets.

I know, I hate those moon alignment issues.

I once got a note from myself from the past, and all it said was, "You suck." [Laughter]

Aw, poor Joe. Kind of a pessimistic outlook.

And there's no way to tell past you, "No, you suck." You can only communicate to the future you. You can't go back the other way. [Laughter]

It's really frustrating.

Yeah, I'll say.

It's like those guys that send you a nasty message in a game, then they quit out. [Laughter]

That's past you.

Yeah.

Aw, poor past Joe.

How is the Angular and TypeScript relationship? I love the story you described of how it came to be. It's been probably seven or eight months now that this relationship's been going. Are you still meeting together, or is TypeScript basically like, "Oh, we've built enough for Angular and now we're done?" Or you know, what's the future?

It's been awesome working with the TypeScript team, and they're not paying me to say that. We have a Slack channel where we're on there all the time, asking questions back and forth. They've been really responsive about turning around new builds for us and adding things like the system.js support, and we're typically on bleeding edge, often on a fork out ahead of where TypeScript is right now. And so having their support has been really critical. Yeah, it's been awesome, it's made our developers more productive. And a couple people on the team are just like, "Oh my gosh, I'm so much happier now that I can safely refactor." So yeah, it's great.

From our side, I love those guys. I have a blast. Whenever we're hanging out at ng-conf or Angular U, I fly down and kind of just catch up. We end up spending half the time goofing off. Brad likes to say that the Angular team doesn't make partners, they make friends, and I really think that's true. They really put a lot of who they are into their projects, but who they are just kind of shows when you walk up to them at a conference and just start talking to them. They're totally who they are all the time. They're not just the corporate face or whatever, something like that. So it's been a blast from our perspective. Like Alex was saying, we've got this Slack that we chat back and forth on, but e-mail's always open, phone's always open, we fly down and try to at least catch up team to team once every couple months or so.

Yeah, we send each other pull requests on Github. I think our current, most up-to-date Angular2 example is actually under the Microsoft namespace, back from the ng-conf demo.

When you said the Angular team doesn't...I can't remember what you said already. But I just imagined that there was like a star shooting across the screen. It just sounded so poetic. [Laughter]

Can you guys edit that in later?

Yeah, like "doodly-doodly-doodly-do," kind of like that?

I was hoping that you'd actually have a star pop up on top of whatever podcast app that somebody's using.

There we go.

That’s better than a star.

All right, should we do some picks? Aimee, do you want to start us with picks?

Sure, I can go. The first one I was going to pick is something, I think it's called f.lux, and it is not the flux you're thinking, if I'm saying it correctly. But it's an application you can get, there's one for your phone, although it's not the greatest, but I use it on my laptop, and it dims your screen at certain times of the day so when the light's not as bright, and I absolutely love this for at night. Maybe I shouldn't be doing stuff at night as much as I do, but I do anyway, so it has helped. The other thing, I've been trying to explore observables a little bit and get more into functional programming, and I saw it tweeted out a bunch and also watched a talk on it once before, but it's by Jafar Husain, it's called learnrx. He has a course on it on Egghead, but there's also this browser tutorial that you can do on your own. So that is my second pick, and I'll put links up for both. They've been fun.

All right, Jamison, do you have some picks for us?

I totally have picks. The first one is a website called StartupTimelines.org, and it looks at the changes to websites of these different successful startups. So you'll see Dropbox's first website and Uber's first website, and stuff like that. It's just really interesting to see how humble beginnings some of these giant tech juggernauts had. And then my next pick is a TV show called Friday Night Lights. It ended a long time ago, but I just binged a lot of it on Netflix over the past couple months, and it is so good. Oh, man! It's great. It sounds really boring, especially if you don't like sports, because it's about a high school football team in this small town in Texas. But they do a really good job of making it interesting, even if you're not a sports fan. It probably has one of the most mature and adult and healthy-seeming relationships that I've seen on TV. Just like, what would you do if you weren't stupid and trying to create drama to make your plot interesting? What would you do if you were a normal, smart, forgiving human being in these weird situations? So that's pretty cool to see, too. One more announcement, so React Rally conference for the React framework, it's in Salt Lake City August 24 and 25, and tickets are on sale right now. So if you go to ReactRally.com, you can get yourself a ticket. We would love to see you there. And those are my picks, I guess.

All right, Dave.

Okay, I just have one pick to share with you today. It's an article written three years ago by a friend of mine called "Unit testing isn't enough. You need static type checking." And it's actually the result of his master's thesis, where he took several programs written in Python that had unit test coverage and ported them to a language with a strong type system, Haskell, and actually identified bugs in the program that their unit tests didn't catch that the programs had that the Haskell type system caught. It's a really cool read, it's actually pretty controversial. It generated a lot of buzz at the time it came. Anyway, it was pretty cool, and I recommend it as a good read. That's all my picks for you today.

All right, Joe, what are your picks?

All right, so I just got my acceptance to speak over at AngularConnect this Fall, and I'm pretty jazzed about that, so I figure I ought to give them a shout out and pick the AngularConnect conference in the UK in October, last half of October, I think. I'll be there speaking on something non-Angular, so I'm kind of excited about that. Yeah. I'll be speaking on empathy and listening to others in the workplace.

Shut up. I'm just kidding. [Laughter]

Exactly, that'll be kind of what I say is, "Here's how to empathize: shut up." So I'm excited to talk about some soft skills stuff. And then the other thing that I want to pick is actually two things. I learned it just this last weekend while I was out at Angular U from PatrickJS, who's also known as Patrick Stapleton: ng-click.com and mdn.io, I had no idea these things existed.

I have one pick, this is something that I'm really looking forward to playing with. We did an episode about it this morning on Ruby Rogues, and it just looks cool. Basically, what it is, it's Sonic Pi, sonic-pi.net. And the cool thing about Sonic Pi is that it has a really simple subset of Ruby that allows you to make music. Anyway, it's way cool, I really think it's awesome, and we were playing with it on the show. It's also got a curriculum with it where you can teach kids how to program, and basically they're just programming up music, so it's way cool. Alex, do you have some picks for us?

Yeah. I was going to mention AngularConnect, but it's too late, that was taken. Ao my backup is actually a little bit of shameless self-promotion of a project I worked on. And it's Java, so unless you do Java backends, it might not be that interesting, but the idea is to put static analysis into the compiler and check for a lot of bug patterns other than just language specs and text issues that the compiler typically catches. It's called error-prone, and we have an easy way to add additional checks to turn certain patterns into bugs. And the cool thing is we're able to use that to incrementally improve the Google Java code base by outlining each pattern as we fix it across the entire code base, and then we'll never have that bug again. And I'm hoping that I'll have a chance to do something like that inside of TypeScript also.

Very cool. Jonathan, do you have some picks for us?

I've got two picks. One is something that I just did at Angular U. I just kind of showed off it working. It's a simple JavaScript application, very simple, actually. But you can see a stage-by-stage move from the JavaScript app through adding classes and modules, then finally it gets into Angular2 and starts using more and more Angular2 stuff. That's kind of a cool little project. And then one that is totally not serious, but I was just thinking about, the Nintendo World Championship just happened a week or two ago, and I am a total e-sports nerd. So seeing the Nintendo World Champion kind of made me think I was watching The Wizard again, which is totally awesome. So I highly recommend going and watching that. If you watch any e-sports, you might recognize a couple of people in there. I won't give the spoiler away, but it's incredibly entertaining.

The Wizard, I remember that, I was a kid when...anyway. Well, thanks for coming, guys. If people want to know more about Angular or TypeScript or how they work together or anything like that, where do they go?

If you want to learn more about TypeScript, there's a couple of places you can go. You can go to the TypeScriptLang.org website, and that's the main TypeScript site. You can get a lot of documentation, there are samples, there's a playground that you can play with. The playground lets you write TypeScript on the left-hand side and see what the resulting JavaScript is on the righthand side. And then use that to explore TypeScript and its features. Alex, did you have any for the Angular2 stuff?

Yeah, for Angular2, the website is Angular.io, and obviously you can also take a look in the Github page. We have started to carve out some small issues that people are interested in contributing. Obviously, if you want to write an Angular2 application, the big question is, "Is it time yet?" And the answer is no.

All right. Well, let's go ahead and wrap up the show. Thank you guys for coming and sharing your expertise. And thank you, everybody, for listening.