[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on JavaScript developers, providing them with salary and equity upfront. The average JavaScript developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with the company or deny them without any continuing obligations. It’s totally free for users. And when you’re hired, they also give you a $2,000 bonus as a thank you for using them. But if you use the JavaScript Jabber link, you’ll get a $4,000 bonus instead. Finally, if you’re not looking for a job and know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept a job. Go sign up at Hired.com/JavaScriptJabber.]
[Let's face it. Bookkeeping is hard and it's not really what you're good at anyway. Bench.co is the online bookkeeping service that pairs you with a team of dedicated bookkeepers who use simple, elegant software to do your bookkeeping for you. Check it out and get your free trial today at Bench.co/JavaScriptJabber for 20% off today. They focus on what matters most and that's why they're there. Once again that's Bench.co/JavaScriptJabber.]
[This episode is sponsored by DigitalOcean. DigitalOcean 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 VPS’s are backed on solid-state drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code JavaScriptJabber you’ll get a $10 credit.]
[This episode is sponsored by Rangle.io is putting on a free webinar that introduces Angular 2 components. It will be April 25th from 12 to 1pm Eastern Time. To sign up, go to JavaScriptJabber.com/Rangle. That's 'JavaScriptJabber.com slash R-A-N-G-L-E'.]
CHUCK:
Alright. Welcome back to JavaScript Jabber. This is the AJ and Chuck at Build sequence. We're sitting here today with Anders… how do you say your name? Hejlsberg?
ANDERS:
Hejlsberg.
CHUCK:
Hejlsberg, yeah. From the TypeScript team. And we're excited to talk to him on JavaScript Jabber. So, do you want to introduce yourself really quickly and then we'll dive in?
ANDERS:
Sure. So, I'm Anders Hejlsberg. I'm a technical fellow in the Cloud and Enterprise part of Microsoft's business. So, more specifically the developer division where I currently work on the TypeScript project that I've been involved with since its inception. And I'm also the Chief Architect of C# which I worked on almost ever since coming to Microsoft. I've been at Microsoft for about 20 years. And before that I was at a company called Borland. I wrote a product called Turbo Pascal and a product called Delphi. So, I've been doing development tools for a long time. [Chuckles]
CHUCK:
Oh, nice.
ANDERS:
Yeah.
CHUCK:
I remember doing Pascal. I don't know if it was Turbo Pascal or not, for one of my math classes in school a few years ago.
ANDERS:
Yeah, yeah. Yeah, yeah. It starts to go back quite a long way.
[Laughter]
ANDERS:
At this point, yeah.
CHUCK:
Yeah. And we've been trying to get you on the show for a while to talk about TypeScript. But I guess you're a busy guy.
ANDERS:
I suppose, yeah, yeah.
CHUCK:
You must be important.
ANDERS:
But no, nah, not really. But I'm…
CHUCK:
[Laughs]
ANDERS:
I'm happy to do this, yeah. This will be fun.
CHUCK:
Terrific. And I've talked to Jonathan Turner and a few other folks about TypeScript and I know… I've also talked quite a bit with the Angular core team about their involvement with adopting TypeScript and some of the things that they've been doing with it. I'm really curious if you could tell us where it came from. I don't know if I've heard the background of the language so much as just why people like it. But yeah, where does it come from?
ANDERS:
I think… so going back probably I'm going to say five, six years ago, everyone inside Microsoft or a lot of teams inside Microsoft were starting to realize that JavaScript is going to get big because the world is becoming very heterogeneous with all these different platforms, mobile platforms, the web, the cloud. And then only language that's going to run everywhere is JavaScript.
CHUCK:
Right.
ANDERS:
And we were starting to write larger and larger apps in JavaScript like take all of the Office Online applications for example, or Outlook, or many really big apps. And we were seeing teams do crazy things in order to write these big apps. It's like realizing that oh my god, writing hundreds of thousands of lines of JavaScript is impossible. Why don't we write it in C# and then cross-compile it to JavaScript so we can get better tools? And the same thing was actually happening at Google with GWT or G-W-T, right, where your people are writing in Java using Eclipse and then crosscompiling to JavaScript.
But of course if you're going for best [of breed] it's hard to imagine that the way you get best [of breed] JavaScript is by writing it in a different language and cross-compiling it. There's always going to be impedance mismatch. It's going to be really hard for you to pick up frameworks without first having to write an encapsulation of them in this other language. And so, when we were thinking about “What can we do to make this a better experience?” we made an early decision that, “Let's not try to make people code in a different language. Let's try to fix the things that are broken about medium and large-scale app development in JavaScript. But let's stay true to the ethos of the language and the community.” Do you know what I mean? Let's make sure that we're open source. Let's make sure that we start with JavaScript. Let's make sure that we track where the standards committee is going. But let's also make sure that we do those things that enable you to write large apps, like having optional static types, like supporting classes and modules and so forth. And then let's down-level transpile it and so forth.
And so, there was the genesis of TypeScript. I'd say we started close to five years ago now internally. We went public about three and a half years ago now, in October of 2012. And it's been great. It's been a lot of fun. I really am still a very, very strong believer in not trying to create a different language but rather let's just work with what's there. Because that's really what the community wants.
CHUCK:
Yeah. And I think I remember at some point… I think it was at ng-conf last year. They had this slide that basically said you have ES 5 and then you've got this superset of it that's ES 6. And then it was kind of a superset of that was TypeScript, which was really interesting.
ANDRES:
Yes, yes.
CHUCK:
So, ES 6 is valid TypeScript.
ANDERS:
Yes. Basically TypeScript starts with JavaScript and then we add to that optional static types. Plus we basically allow you to use all of the latest features from ECMAScript even the ones that are not even in the standard yet like async/await for example but are on their way to becoming standardized. And then we really, we do two things. We give you excellent tooling based on the static types such that you get statement completion and code refactorings, go to definition, navigation, et cetera, et cetera. All the things that you're accustomed to in large projects, right? And then the other thing we do is we give you the ability to down-level compile your code. So, you can close the feature gap. The gap between what you would like to code in and what is actually available on the web. There's state of the art JavaScript and then there's state of the web JavaScript.
CHUCK:
Yeah, exactly.
ANDERS:
And there's a gap in between those.
CHUCK:
Yeah, what the browser will run and what you want to write.
ANDERS:
And that's the gap that we aim to fill. So, those are the two things that we do. And so, we start with JavaScript, give you these capabilities, and then when we compile it just becomes JavaScript again. And honestly, we strive to produce beautiful JavaScript. So, the output that comes out of there, all your comments travel along with it. And if you someday get tired of TypeScript you can throw it away and continue with your JavaScript, because it's your code still.
CHUCK:
Yeah, Rob Wormald yesterday when we talked to him actually said the ES 5 that comes out of TypeScript is probably better ES 5 than you would write.
ANDERS:
[Laughs]
CHUCK:
And yeah, I thought that was fairly interesting.
ANDERS:
Well, there are certain idioms, right? Like the way you do classes and so forth. We've gone through a lot of effort to find the best practices and encode them in our emitter. So, yeah.
CHUCK:
So, one of the things that I hear people complain about… of course, before they used TypeScript but they look at it and they go, “Static types in JavaScript.” It's like, “Ew you got types on my dynamic language.”
ANDERS:
Yeah.
CHUCK:
And I'm wondering, what do you see is the advantages of having static typing, or optional static typing as is more appropriate to say about TypeScript, in TypeScript versus what's in JavaScript?
What problems does it solve?
ANDERS:
There are several things that it helps you do. When a codebase gets to be beyond a certain size, let's just say for the sake of argument a couple of thousand lines of code. It gets increasingly hard to do project-wide things like refactorings. Let's say I have a property called name on this kind of object. Now sadly I have lots of other things called name in my codebase. I want to change this one here to be full name or last name or whatever. But I don't want to change all of the other things called name, right? In JavaScript without semantic understanding of what your code does, your only choice is a global search and replace, which almost is guaranteed to get it wrong. Or manually visit every place where the identifier name occurs and decide whether this is the one I'm renaming or not.
CHUCK:
Right.
ANDERS:
That's madness. And the larger your codebase gets, the slower you go. And these are the kinds of problems that compilers and language services are excellent at reasoning about. But they need help. They need you to say, “This name is different from that name.” And the way you say that is by adding types. And if you add types to everything, now it doesn't mean that you have to explicitly add the types. In most cases we can infer the types. As long as you add a type up here, then we can flow the type through your expressions and through your statements and through your property accesses and then we can understand just from a single annotation what all of the types in a function are often. And then we can give you safe refactorings. And I do this daily. The TypeScript compiler is now close to a hundred thousand lines. The compiler and the language services that go along with plugging it into Visual Studio and all of the other editors, right? And with regularity. We refactor across the entire codebase. I need to rename this property here. Poof. It just did the 57 places it occurred even though it had a very common name. But all these other places were left alone.
CHUCK:
So I guess I'm wondering. I can see what you're saying but I don't quite make the connection in the sense that if I have say 10 different classes that all have a name property on them and all those name properties are string, are you talking about the optional typing on the name property that are all strings or optional typing on the class and stuff.
ANDERS:
No. No, the class. It's actually there. You don't even have to give it a type. The fact that you declared a name property inside this class and inside this other class, well we know that those are two different name properties. And if you say rename this one, then we can rename it in all the places where you are dotting off an instance of that class but not the other one.
CHUCK:
Right. So, I annotate in my other functions and things that I'm expecting a person type.
ANDERS:
Yes. Exactly, exactly.
CHUCK:
And so, then it knows, “Okay, so since I know this is a person type and you're refactoring on the person type the name property then I can [inaudible].” Okay, I just wanted to clarify that.
ANDERS:
That's one of the advantages. Another one of course is just the ability to easily navigate around in big codebases. Here's a call to a function call foo. Oh, let me see what foo does. I want to just press F12 or whatever and jump there. Well that again, you need to know which foo. [Chuckles] if it has a common name, then there could be many and we can jump you to the right one. Statement completion. Knowing what properties could I write here. If I'm working with jQuery I don't remember the entire API. Tell me. When I press dot just show me what could go here and I'll pick the right one. Documentation. If you're writing a framework say or a big codebase you probably want to document what you meant here so that when another developer comes in later they don't have to start all over and actually deeply understand ever bit of the code before they can make even the minutest little change. So, there are many things that this helps with.
CHUCK:
One other question that I have about TypeScript, and I think I know the answer to this, but in JavaScript one of the nice things about having things be dynamic is that if two different object types or two different classes have the same function or the same property on them then I can pass either one in and call 'dot name' on it, right?
ANDERS:
Yes, yes.
CHUCK:
So, can you annotate in your function that it should be a person or some other type that has a name on it?
ANDERS:
Yes, yes. In fact, not only that but the whole way the type system is built in TypeScript is that it's a structural type system. And that means that it's really a formalization of duck typing [chuckles] if you will. You can declare an interface or just yeah, an interface type and say it has a name and an age property. A name is of type string and age is of type number.
CHUCK:
Oh, interesting.
ANDERS:
Anything that has a property with name of type string and age of type number or something that derives from string or number is assignment compatible with that.
CHUCK:
Oh, that's interesting.
ANDERS:
And you don't have to do anything else. You don't even have to give the type and name. You can just write the type annotation inline using curlies and then anything that has that. So, when you write an object literal it is automatically assignment compatible to anything that has the same set of properties.
CHUCK:
I see. So, you can basically do a type annotation on the interface instead of the object.
ANDERS:
Well, you can just do it straight on a variable. There's no difference between… you can write the same interface 10 times, give it different names, if it's structurally the same, they're all the same.
CHUCK:
Interesting.
ANDERS:
Yes. So, the name doesn't actually matter. It's the structure that matters.
CHUCK:
So, one other thing that I'm wondering about though is that TypeScript the way that you've explained it and explained the benefits center a lot around tooling. So, why use TypeScript instead of just having better JavaScript tooling?
ANDERS:
Well, TypeScript is better JavaScript tooling.
CHUCK:
Okay.
ANDERS:
Because it starts with JavaScript but then you realize, and I think we're not the only ones to realize, that in order for the tooling to get really smart you need to know more about the code than is apparent in the code itself. Now you can start thinking about places to put that information. You can put it in a different file. That's probably not a good idea. Now I got two files to keep in sync. You could put it in comments. That might be a good idea. Google Closure does that with JSDoc annotations. But it's not…
CHUCK:
Yeah, it's nice until your comments get out of sync.
ANDERS:
Exactly. And it's not a great place to host a type system. So, why not just allow you to add type annotations to the code itself, right? And we talked about this other thing earlier, this thing called the feature gap in JavaScript. And because of the feature gap a lot of modern JavaScript dev shops use a transpiler of some sort, like either TypeScript or Babel or whatever. And honestly if you have a transpiler in your tool chain anyway, then why…
CHUCK:
Yeah, why not inform it, right?
ANDERS:
Why not also get all of these other benefits that we can deliver through type annotations, right? So to me, that is just a slam dunk. I don't see why you wouldn't.
CHUCK:
So, we get to the point where we're like, “Okay, so we're going to build TypeScript and it's going to solve these problems. It's going to make tooling easier.” How do you actually turn it into a language that people can use?
ANDERS:
[Laughs] Well, I've been doing programming languages now for 35 years. So, I know a few things about what works and what doesn't. But even so, the thing that intrigued me about this project is that it's a very different way of thinking about type systems. Type systems traditionally have been for correctness of course. But it's also very much been about gathering information that then you use when you emit the code. So, you need to know what the type of this variable is so you know what kind of machine instruction to use.
CHUCK:
How much memory to allocate.
ANDERS:
Exactly. All these things. But then what's happened in the last decade or two is that compilers have actually changed fundamentally or the way we use compilers has changed. It's been a very gradual shift. So, no one's really noticed. But compilers have become these things that are actually behind our editors and guide our every interaction with our code and help us. They serve up helpful hints . The red squigglies. They do all these things for us, right? But below all of that is a compiler. But the compiler is very different. It's not your traditional command line compiler where the code generates a backend. It's a piece of machinery that has all of the same components but is built more like an API the can be plugged into an editor that can work highly incrementally.
And in the case of TypeScript that actually doesn't guide the code generation because we generate source in a sense. Well, it guides it somewhat. But not really, right? And so, in a sense what we have here is a type system for tooling and productivity's sake. And it turns out that there's so much of the job that a compiler does is now that, that it's actually valuable in and of itself now as a new thing. And that's sort of what's interesting about this opportunity, because it's new. That hasn't really been the case before.
CHUCK:
Right, where it breaks it down into an abstract syntax tree and then…
ANDERS:
Oh yeah, no, our compiler is… well, it's just like any other compiler. And then in many ways it's very different. It's actually I think a beautiful piece of engineering because if you had told me five or 10 years ago that oh, Anders in five or 10 years you're going to be writing compilers in JavaScript that can handle hundreds of thousands of lines of code and keep up with the user typing, I would have gone, “There is no way that's going to happen.” And here it is and it's happening. And that speaks to a couple of things.
First, the tremendous evolution that JavaScript runtimes have gone through and the wonderful work that Google has done with V8 for example and that we've done in our Chakra engine. And the capabilities now and speed that you can get with JavaScript that we all previously thought was never going to be possible. But then also, we have actually thought very, very deep and hard about how to make a compiler sing in that kind of an environment. And so, our compiler in some ways is built as a traditional, there's a scanner, there's a parser. It builds abstract syntax trees. But then it starts to look very different thereafter. We build these immutable ASTs and then we cache them for each file in your project. And as long as you're not modifying that file we can just keep the AST around.
And so, if you have a 200-file project and you're just typing in one file that's the only file that we build new ASTs for. Then we furthermore say, “Well, if we have the old AST around and we know where in the file you were editing then we can use piece of the old AST also. So really, all we're changing is the little corner of the AST that you're roaming in and then the spine going up, because we use an immutable data structure to stitch together a new tree from the old tree. And then we run the type check on that. But of course we can't type check all of it. If you're saying 'da-da-da-dada dot' and now you need to know, what is the type of this thing? Well, then we just analyze just enough.
So, our compiler is what we call the pull mode compiler. Compilers traditionally start top-down and analyze everything and build a big symbol table and whatever. Our compiler's totally different. You start inside out. You sort of helicopter into the middle of the piece of code and say, “I'd like to know what the type is right here.” And then we incrementally bind just enough to deliver the answer quickly.
CHUCK:
That's amazing.
ANDERS:
And that is… no school teaches you how to write a compiler that way today. There are lots of schools that teach you about writing compilers but they don't teach you about writing those kinds of compilers.
CHUCK:
Well, it's because those kinds of compilers are all about the resulting machine code or…
ANDERS:
Well, they're about a whole… it's about the new way of using compilers that I talked about earlier. It's compilers for tooling's sake. Which is a different thing than compilers for code generator's sake.
AJ:
So, as I understand it, when you run the TypeScript compiler, that's… at least the way I used it with the tooling setup I had in vim, it ran as a server, not as a one-time thing, because it had to keep all these caches and do all that.
ANDERS:
Yes, yes.
AJ:
Because if you try to run it just once, it's really slow. So, you have to have that server so it can have those caches and doesn't have to recheck everything every time.
ANDERS:
Sure. A couple of times. First of all, if you run it once it's not actually really slow. The original compiler that we had was about five times slower than the compiler that we have now. We actually did a complete rewrite of the codebase about two years ago. And then the codebase one now is very, very fast. Compiler compiles itself in two or three seconds. And that's a hundred thousand lines of code.
CHUCK:
I love that. The compiler compiles itself.
ANDERS:
Well, of course. It's all written in TypeScript, right? Yeah. So, that's fast for a compiler. But you're right that what we do is we package a version of the compiler as a Node module called ts.server which you can run as a separate process. And then you can talk JSON to it. And that's what our VS Code plugin does, our Sublime Text plugin does, and literally the editor… you then write an editor plugin and all it's saying is, “I'm in file this and that on line 214, column 17. The user just pressed dot. I'd like to know what to show him.” And then the oracle coughs up an answer and delivers it in JSON.
CHUCK:
[Laughs]
ANDERS:
Do you know what I mean? And the oracle [chuckles] in this case the compiler, is actually keeping a mirror state of your entire project. It's known from crawling up your directory tree, where's the tsconfig. From that we can figure out and watch all of the files. Then we can load them up, build ASTs, and hold them in a separate process, and then just be told about the little changes you're making and updating our image there. And then we're able to cough up answers on millisecond scale, which is fascinating, really.
CHUCK:
Yeah.
ANDERS:
It's so much fun to work on.
CHUCK:
That's just amazing.
ANDERS:
Yeah, yeah. So, that's how we're building the compiler actually. So, there's the command line compiler but that's really just one way you might use it. And of course we also support watch mode. It's very popular in JavaScript tool chains to… everyone wants to just have the experience of edit, save, and refresh in the browser. And if you put on auto-save, you don't even have to save. You just go refresh. [Laughs]
CHUCK:
Yeah.
ANDERS:
And we know full well that we need to support that. And so, you can run the TypeScript compiler in watch mode where it basically sits and just watches file system change events. And whenever they occur, it recompiles just that file. It re-emits and whatever. And so, you can just have the same workflow that you've always had. Plus we're also embeddable. So, tools like Webpack and use us at packaging time. Or loaders like SystemJS can use us as an in-browser transpiler at runtime, which is a dev setup that's popular with Angular. So, you never compile. The compile happens as the file is downloaded to the browser. Of course, you wouldn't do that in a production environment.
But for development it's actually super handy.
CHUCK:
That's just cool.
AJ:
So, if I just want to stick with ES 5 but I want… are there any features of TypeScript I can use without having it be TypeScript? Is there anything I can use from the tooling of TypeScript without actually adding things that change the syntax?
ANDERS:
You want the artifact to be ECMAScript is what you're saying. But you want some of these benefits?
AJ:
Yeah. Like I really don't like… I don't do Babel. I don't like transpilers. I don't like having my tool chain… I mean, it gets complicated.
ANDERS:
No, I understand what you're saying.
AJ:
But I really love the idea of adding… do you call it strong typing? Firm typing? It's not really typed but it's typed enough to get you tooling benefits.
ANDERS:
Yeah. So, one of the things that we've worked on most recently and that we released actually in version 1.8 which is now in Visual Studio Code and in Sublime Text, is the ability to use the TypeScript compiler to analyze JavaScript and to give you help on pure, unannotated JavaScript. And there's a limit to how far we can go.
But one of the things that's happened in the TypeScript community because of its popularity over the last few years, a lot of people have written down what we call declaration files or typings for all the popular JavaScript frameworks like jQuery, like Lodash, like Angular, like React. You name it. It's all collected on a GitHub site called DefinitelyTyped. And [there are] more than 1500 declaration files there now for every popular JavaScript framework. And all of that information, it's describing how the JavaScript works. And so, wouldn't it be nice if we could actually use that even if you're writing JavaScript? And it turns out that we can.
So now, we allow you to basically drop a tsconfig file in your root JavaScript directory and then just tell the compiler which libraries you're using or which typings you should include. And now when you're sitting in JavaScript you type 'dollar dot' then poof, all of the sudden the oracle kicks in and shows you everything that could go here. And it keeps going as you're dotting because we can infer types. Even though there was no type annotation to start with other than the dollar, everything that flows from that first dollar [laughs] of jQuery…
CHUCK:
That's amazing.
ANDERS:
We can… so, we can keep going for a good long time before the types run out, so to speak. But at some point they run out. And if you're unwilling to put type annotations then there's not much more we can do. But one thing that we do, do now is we actually slurp up JSDoc type annotations also.
AJ:
Ah. Okay, that's something I'd be interested in.
ANDERS:
Okay, great. Well, it's in the shipping product right now. So, go check it out. I actually demoed it in my talk yesterday.
AJ:
So, what is the tsconfig file?
ANDERS:
The tsconfig, it's just a file that tells you that this is the root of a project. And then it tells you what are the options that you want to enable on the compiler like what things and which files should it look at. Just so it doesn't go [inaudible] and look at the… there may be a lot of JavaScript files around here that are not necessarily part of how you're going to package your program. Do you know what I mean? You've got to tell us which files. [Chuckles] Then we can deliver all of this.
AJ:
So, is something like jQuery where it's not written in TypeScript, is it basically, like you take as if it had JSDoc annotations and the export that out to a metafile or metadata?
ANDERS:
So, that was what I was talking about, the declaration files that you can find on DefinitelyTyped.
AJ:
Okay.
ANDERS:
So, there's a file called jQuery.d.ts.
AJ:
Okay.
ANDERS:
And you can just drop… so, one of the ways you use TypeScript typically is you have… you put a tsconfig file in your root directory. Then in there you can say specifically what files to include and you can just say, no include all files except for these directories. So, that's the default mode. So basically, it just says anything that sits in this tree, I'm going to look at. And so, as long as you drop a jQuery.d.ts into some subdirectory somewhere underneath your root like a directory called 'typings' for example, then we'll pick it up automatically as you're sitting there typing your JavaScript. And then we'll give you statement completion if we can figure out a type. And if we can't figure out a type, then you can add a JSDoc annotation and then we'll pick that up and then go from there.
AJ:
Okay, cool.
ANDERS:
Yeah.
AJ:
I like that. I'm glad to know that the JSDoc…
ANDERS:
And then we actually also…
CHUCK:
They love you too, AJ.
ANDERS:
[Chuckles]
AJ:
No, I mean because I really love the idea of it. I really want the tooling. I just don't want…
ANDERS:
No, I understand that point of view. I totally do. And we're very much about allowing you to set the dial wherever you want to set the dial. And now we're allowing you to go all the way to zero.
AJ:
Yes!
ANDERS:
[Laughs] And then you can ramp it up and you can even mix TypeScript and JavaScript files in the same project if you care to. And it's…
AJ:
I would imagine that at some point there could be complications when you're mixing TypeScript and JavaScript where you're saying, “I want this type,” but then actually you're requiring a JavaScript file or something.
ANDERS:
But you know, the funny thing is there isn't actually. Because from the type checker's perspective JavaScript is the same as TypeScript except there are no type annotations. Oh, but we're already prepared to handle that. That just means that we give it type any.
AJ:
Okay.
ANDERS:
Type any means oh, you can say anything after. You can say blob dot and anything you want, right? So, TypeScript… JavaScript, it's just like…
CHUCK:
It's TypeScript that has a whole bunch of anonymous types.
ANDERS:
It's TypeScript but, but, but, but… exactly, yeah, yeah. We have no problem handling that.
CHUCK:
Yeah.
ANDERS:
And then the one thing that we do now is we… but we say, “If you're in a JavaScript file and you have JSDoc annotations, let's get it from there.” That's really the only thing that changed.
CHUCK:
That is pretty darn amazing.
ANDERS:
That's fun stuff.
CHUCK:
So, are there limitations to TypeScript as far as where you can use it or what you can do with it? Are there things that people do with it where they go, “Oh, when I try and transpile it, bad.”
ANDERS:
You have to be in a scenario where it makes sense. I think if you're going to write five lines of code, it probably isn't worth the effort to get yourself set up with the tool chain and all that stuff. But the larger your project gets, the more valuable it is. And like I said earlier, by the time you get to a couple of thousand lines of code, it's a slam dunk. It really is. And I think we have enough. Just look at our usage numbers and the testimonials we're getting. And it's pretty clear that we are really delivering some productivity value here. We've actually over the last year, our download numbers of npm have gone up about 20x. And we just went over a million downloads per month now in February.
CHUCK:
Wow.
ANDERS:
Of course these are not individual users.
CHUCK:
Oh, of course.
ANDERS:
But it just means that we're becoming a part of a lot of other tools that pre-provision us. Do you know what I mean? And that's really a sign of your adoption by the community.
CHUCK:
So, one other thing that I've seen with… I've been to a bunch of Angular conferences lately. I was at one in Amsterdam. I was at ng-conf. I think I was at another one last fall that I'm just not thinking of at the moment. But anyway, a lot of the examples are in TypeScript. And the way that those files are organized is very nice, is very clean. And one thing that I haven't quite been able to determine is if that's because they're using TypeScript or if it's because they designed it to look that way in TypeScript.
ANDERS:
Well, it's a combination of things I think. Because TypeScript fills the feature gap you are now… basically you have permission to write the latest version of ECMAScript. [Chuckles] Even, we're ahead of the standardization committee on certain features. As long as features raise to a stage three is typically, we go, “Okay, it's time for us to consider having this as a supported feature,” even though it's not actually in the standard yet. So, you can write state of the art JavaScript. And that helps. Because that means you have modules. You have classes. You have arrow functions. You have a lot of things that make your code look nicer. And then you also have features that are not even in there yet, like decorators, that allow you to do dependency injection in Angular for example. And that certainly looks a lot nicer than having underbar thingies with strange names that are recognized by the infrastructure. Do you know what I mean? So, a lot of that helps.
But then also, I think the fact that the extensions that we've added are very, very natural. Our type annotations look like they belong there, like they were always there. They flow totally naturally in the language. And our interface declarations look kind of like object literals. They say types instead of values and it feels natural. So, there's a certain aesthetic to it that I think is there, too.
CHUCK:
Yeah, it does sound like it's a little bit of both. You did mention that anything that makes it into the standard at stage three, and talking to people here and talking to other people on TC-39, I hope people understand how that works and maybe we should show a little more depth. But if something gets to stage three and then they decide not to put it in the spec for whatever reason, do you pull it out of TypeScript?
ANDERS:
It hasn't happened yet, so…
[Laughter]
ANDERS:
At this point I think…
CHUCK:
Because it seems like stage four is…
ANDERS:
[async/await] is at that stage and I think decorators are at that stage. And they didn't make it into ES 2016 but they're looking like they'll be in 2017. So, that's fine. We have yet to be in a position where we have to pull something out. And we'll see what happens there. We can always [park] something under a backwardscompatibility switch on the compiler. The thing about compilers is you can never take anything out. [Laughs]
CHUCK:
Yeah.
ANDERS:
You can park it.
CHUCK:
That's what I was wondering. So, what do you do?
ANDERS:
But you can. You can and we continually see people try to do it in their languages. And then the community goes crazy.
CHUCK:
Right. I was using that.
ANDERS:
Because you're just taking the cost and you're putting it right back on the community. You don't want… I don't want my old code to be broken. I want my new code to be better. So, give me a switch that allows me to use the old stuff and then I'll clean it up whenever I have time, or maybe I
never will because that's on the way out anyhow. But for the new stuff I want you to tell me “What's the right way to do it?” So, you got to be sensitive to both sides.
CHUCK:
Gotcha. Do you have anything else you want to ask about TypeScript?
AJ:
No, I'm…
CHUCK:
Because I'm really curious. You mentioned, and I'm going to change the topic is why I was giving you a chance AJ, but language design. What does it take to be a language designer? Because that just seems so…
ANDERS:
[Laughs]
CHUCK:
It seems so fascinating to me. C# or TypeScript or some of these other languages. And you see people, they're designing new functional languages. Or they're designing new sort of objectoriented languages where they pick and choose features that they really like from other places and then you get something that actually kind of works. And so, I'm curious. As a language designer what skills do you have to have and what do you do to explore the areas you could go into and then make decisions that go into a language?
ANDERS:
Yeah. It's a tough one. A couple of things I would say that have worked for me. One is, try to keep it as simple as you can. Don't go for all the bells and whistles. Because simplicity also means if it's simple it's easier to understand. And it will also tend to run faster [chuckles]. So, small is good.
CHUCK:
Yeah, but some of those complicated feature are very powerful, too.
ANDERS:
They are. So, you got to understand every good language feature typically has more than one use. Like take lambdas or take interfaces or whatever. It's not like they're a one-trick pony that you add into the language. Oh, let's put XML literals in the middle of the language. That would be cool, wouldn't it? Or something. And then you discover that… we had with C# big debates about whether we should support XML. Because there was a time when XML was like, my god, it was the best thing ever.
CHUCK:
Yeah, and the last five years I've heard so many jokes about XML.
ANDERS:
And if you didn't say XML then you just weren't with it, right? And so, of course there was a lot of pressure to… can't we somehow put XML into C#? And then, oh my god, that'll just be fantastic. And I actually sort of fought it, because I felt that these fads have a way of petering out. And if you hitch yourself to that wagon, you go down with it. And so, you got to be careful. Because you…
CHUCK:
Well, and a language has a job to do. And those features feel like they're…
ANDERS:
No, but it's like what we talked about, right? You can always put stuff in but you can never take it out.
CHUCK:
Oh, gotcha. Yeah.
ANDERS:
At least, well there's one exception. Unless you have no adoption. [Laughs] But show me…
CHUCK:
But then you have another problem.
ANDERS:
Show me a beautiful language with no quirks in it and I'll show you a programming language with no adoption.
CHUCK:
[Laughs] That's so fair.
ANDERS:
It's true.
CHUCK:
Yeah.
ANDERS:
Stuff accrues over time. And all you do is you just get more and more baggage. So, you got to be real picky about what you put in. and it's okay to say no. but sometimes you got to say yes. [Chuckles] So, it's hard. And some of it just comes down to developing a feel for it over time by doing it for a long time. I think like with anything, you got to be passionate about it. I'm very passionate about programming languages. I've been doing it for 35 years. And I got to a start in this business not because I wanted to make money. I was doing it because I couldn't help myself. I couldn't stop. And oh money, that was nice. I got to eat, too. But I still want to do this.
CHUCK:
[Laughs]
ANDERS:
So, you got to be passionate. Because that's how you get good at something. It's by putting in the hours.
CHUCK:
Yeah. I'm also curious. If you had unlimited budget and unlimited time, resources, what kind of a language would you design today?
ANDERS:
[Laughs]
CHUCK:
Because there are so many interesting things going on. It's like, how do you pick?
ANDERS:
Yeah. It's tough. I think the thing that's interesting about programming languages is that they are all 90% the same. We all stand on the shoulders of giants. There's so much good work that even if you invent a brand new programming language, 95% of it is going to be something. Everyone… you're going to need a type system. You're going to need a syntax. You're going to need… like one of these concepts that we're accustomed to like functions and whatever. But then there's new stuff that's sort of… but programming… like functional programming for example that we've all learned a lot from over the past decade or two. But even functional programming language, if you look how… the thing that's interesting about programming language is how slowly they evolve. Look at Lisp. Lisp is the grandfather of all the functional programming languages. That language is 50 plus years old. It's like, we were walking around in diapers when they invented Lisp. It's not like the evolution of hardware where we've got new generations of everything and we're talking about tens or six orders of magnitude improvement over decades. No. No. This is…
CHUCK:
Well, the other thing is you mentioned Lisp. And we see things like Clojure and some of these others that are very similar to Lisp except they've added a couple of features that make them a little bit more modern, a little bit easier to use.
ANDERS:
Oh, they've added type systems, yeah.
CHUCK:
Right. So yeah, specifically with Clojure they're added a type system that allows complex types and simple types. And yeah, you could see that as a major leap forward. But then they really haven't changed Clojure a ton after that. And the next thing will be another deviation in one direction and then yeah, and that'll be in another few years when somebody says, “I like Clojure but I need this other thing on it.”
ANDERS:
Sure. But I think, like I said, there's a lot of interesting stuff happening in functional programming that I think we've learned a lot from. And certainly, when you look at say the type system that's in TypeScript it is actually more closely aligned with functional programming than with object-oriented programming. We support classes.
CHUCK:
Oh, of course.
ANDERS:
But we have a structural type system with generics and F-bounded polymorphism and all these fancy things. We have union types, intersection types, that work over generics. Type inference, very, very, very rich type inference. These are all things that come straight out of functional programming. So, like I said we're all learning from each other.
CHUCK:
So, one other question that I have, because you're paying attention to the space of these languages that transpile to JavaScript. And I keep hearing more and more people, except for AJ…
ANDERS:
[Laughs]
CHUCK:
Who are saying that that's just the direction we're heading in now. That more and more modern
JavaScript apps are going to be written in languages that are not JavaScript but transpiled to JavaScript and that that is going to inform the web moving forward. Is that something you agree with?
ANDERS:
Yes. But with a twist. I think there are a lot of languages that compile to JavaScript. And then there are few languages that are supersets of JavaScript. I'm a believer in that category. That's the category that we very explicitly chose to put ourselves in. we specifically did not want to be a brand new different language, because we knew that the only way you get adoption in this space is by adding value, not by telling everyone “First you got to throw away all your code. And now, let's talk about the value we add.” Well, okay you start out with minus a thousand points right there and you never win them back.
CHUCK:
Yeah.
ANDERS:
But if you can be a superset then you start out at zero and everything you do is positively accrued. And that's why we're very serious about being a superset and about tracking the work that the standardization committee is doing. But then on top of that, we do types and tools as our natural domain. We're adding value. And I think that formula has worked out really well for us and is very synergistic with what's going on in the community already without trying to substitute something different. And also, I still believe that the only way you get best of breed in this space is by being that superset. Because if you're some other language then there's always impedance mismatch. There's always something that I could have done in JavaScript that I can't quite do over here. And now, I have to contort myself to try and do it. And it just turns into hackery at that point. So, now you're just trying to appease some compiler that doesn't really have anything to do with your core problem anymore.
CHUCK:
Yeah. Now, AJ may be a little surprised to hear me ask this question because I really do like ES 6 and TypeScript. But the argument has been made that ES 6 is a deviation from ES 5 and not a
superset of ES 5. That it's a change and not an addition to.
ANDERS:
Oh, it's a change. A lot changed. A lot was overdue, right?
CHUCK:
Yes.
ANDERS:
From ES 3 to ES 5, 10 years with a failed on in the middle. And then it was another six years from ES 5 to ES 6. And there were actually not a lot of new syntax in ES 5 other than strict mode which wasn't really syntax. And so…
AJ:
I don't think there was any new syntax in ES 5.
ANDERS:
Yeah, yeah, yeah.
AJ:
I think the only thing that was done is that keywords that were never used were released so that they could be used. And then things were taken out of the language like 'with' and 'eval'. And then other things [that] would generate silent errors or really weird behavior were correct. I think that if you did 'new boolean false' the value would be true.
[Laughter]
ANDERS:
Well of course, it would. [Laughter]
AJ:
And there was something else. Like a couple of things like that, they were just way out in left field. They were errors. And ES 5 was really about removing garbage and not very… other than things like the arrays that were all polyfills.
ANDERS:
Well, removing the garbage you can remove, yeah, without breaking everybody too badly. Yeah, yeah. Yeah, I think you'll like the stuff that we're doing with the non-nullable types. You should check out the presentation I did here and then some of that work.
AJ:
I will.
ANDERS:
It's really cool, because it gets to the very core of some of all of these quirks about the differences between truthy and falsy checks and double equals and triple equals, and what does it mean for my types and how do we actually check that you wrote the right thing? We're doing a lot of fun stuff here right now.
CHUCK:
So, is ES 6 too much change?
ANDERS:
By and large I think they did a fine job. The vast majority of things that got added I think have a place in the language. I think lambdas are great, destructuring is quite useful. Classes for sure. I do understand that… and modules, absolutely.
CHUCK:
Yes, absolutely. And it gets it a lot closer to what I think a lot more people who use modern languages are accustomed to.
ANDERS:
Oh, yeah. You really need to write code with modules with controlled scopes and understanding whatever API it is that you've defined across this boundary and then having these packaging tools or modern loaders be able to either prepackage everything into a single downloadable artifact? Or do all the transpilation on the fly. That's wonderful. I think that's goodness. Now, there is and there always will be I think a big debate of the OOP camp versus the functional camp. And JavaScript is one of those few languages that equally well-supports both styles. And I think it's fine. Because honestly, this debate is just going to go on forever. And there is no single answer in that debate. It really depends on, do you like speaking French or English? Well, it sort of depends on what I grew up with. But both are good. And I think…
CHUCK:
What are you doing and where does it hurt?
ANDERS:
Exactly. And I think both actually fit in very nicely. So, I'm pretty [inaudible] on it.
CHUCK:
Very nice. Well, I don't know if I have any other questions or anything to add. How about you, AJ?
AJ:
No. No, I'm satisfied.
CHUCK:
Alright. So, I've been wrapping this up first by just throwing a thank you a Richard and Carl for inviting us here to be able to talk to the folks here at Microsoft and get to talk to you. One other thing that we do during our shows, of course we've done six or seven interviews now. So, we're not doing it but we would like to ask you. At the end of our shows we do what we call picks. And basically what that is, is just whatever you're into if it's a TV show or a movie, music, or whether it's coding tools or a programming language or anything like that. Just, what are you into these days?
Are there one or two things that you just want to shout out about?
ANDERS:
[Laughs] I don't know. I just… you now the thing I'm into in a sense is getting back to my roots and writing code.
CHUCK:
Ah, yeah.
ANDERS:
The thing that often happens when you become an architect and you rise, it's like it becomes very easy not to write code. And I was finding that I was writing less and less code and doing more and more high-level design work. And there was something I was missing. And I couldn't quite figure it out. And then when I got involved with the TypeScript project I started writing a lot of code and I'm writing a lot of code in the compiler and I'm loving it to death. So for me, it's like I just think it's important to be true to your passions, because that's what makes you happy. And that's when you do your best work. So for me, that has been a thing I'm into, if you will. [Chuckles] It's writing code again.
CHUCK:
That's actually really insightful. I think a lot of people, they get into code and they write code for a living and they really enjoy it and they just take for granted that they have the opportunity to do that. And for me with the podcasts and everything else, I spend a lot of time doing other things. And so, I definitely identify with that where I finally got to the point at one point where I was like, I don't think I've written code for three or four weeks. And so, I sat down and I just cleared everything off and wrote some code and just built something and experimented with stuff. And it is, it's a core thing to who I am.
ANDERS:
It's therapeutic. [Laughs]
CHUCK:
Yeah. Yeah, it is. It's relaxing and yet stimulating at the same time.
ANDERS:
Yeah, yeah, yeah.
CHUCK:
Well, thank you very much for talking to us.
ANDERS:
Oh, my pleasure. This was fun, yeah.
CHUCK:
Yeah. Well, we'll have to see if we can get you on the Angular show because I know that they'd love to talk to you too.
ANDERS:
Yeah. Yeah. That'd be fun.
[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]
[Do you wish you could be part of the discussion on JavaScript Jabber? Do you have a burning question for one of our guests? Now you can join the action at our membership forum. You can sign up at
JavaScriptJabber.com/Jabber and there you can join discussions with the regular panelists and our guests.]