Talking TypeScript with the engineer who leads the team
Q: How long have you been with the TypeScript team?
A: I started on the TypeScript team about six months before our initial release, in February 2012. So I’ve been working on it for about eight years now.
Q: Interesting, so pretty close to the beginning. Do you remember why the team came up with TypeScript, why you wanted to release something like this?
Q: Was there a point where you saw an adoption point of no return? Was there something that came along where people were like, oh, yeah, we do TypeScript now?
A: Oh, it was definitely Google announcing that they were going to use TypeScript with Angular. That’s kind of lost to time now. But if you look at the graphs for TypeScript, literally any graph—GitHub stars, downloads, pull requests—you can see the exact point when that Angular announcement came out. And the graph just changes. It never looks back. You can’t see that little bend in the curve anymore because the curve kept going. That was a real inflection point. And I think it’s been interesting that people thought at the time that TypeScript was going to be just what Angular people use and not much else. That didn’t turn out to be the case. Obviously, we’re still popular among Angular devs. But that was a real momentum builder for us.
From our tag trends tool.
Q: In our most recent Developer Survey, TypeScript is the number two most loved language, rising up through the ranks. Why do you think people like it so much?
A: Huh? Because it’s great!
Q: I think we need an answer we can defend objectively.
Q: It seems like static typing is sort of having a moment now. I’ve seen a lot of comments about appreciating the duck typing in Rust, the hints in Python. Why do you think static typing is so popular right now?
A: I think because people have tried to build large applications without it and seen how painful it is. I mean, the same thing is happening with Hack at Facebook, where they’re adding types to PHP. So I think people have realized that you can write a small program without static typing pretty easily, but you quickly hit a threshold where, without it, things just become too painful. It’s too hard to reason when you’re trying to maintain them and guessing at typing and such.
I think my favorite thing that I see is people on the Internet saying, ‘I did this huge refactoring in TypeScript and I was refactoring for three hours. And then I ran my code and it worked the first time.’ In a dynamic language, that would just never, ever happen. There’s a very satisfying element to being done when the type checker says you’re done. That might only be eighty five percent accurate. But that’s a lot better than zero. It’s just a much better way to develop, especially during big refactoring like that.
Q: I’ve seen some folks resistant to static typing. Do you think there is a place for the more dynamic typing?
Python’s the same way. Very few people have working Python type annotations, but Python is incredibly popular. I think the data speaks for itself—I think Python is number three in the survey (ed. note: It is, but by a hair). I guarantee you that a very small proportion of those Python developers have static types. Whatever your problem domain is, that might be the best fit for you.
Q: Right, the ability to learn a language that you’re going to be able to use no matter where you end up at, unless you’re a COBOL developer working on a government system or something.
Q: So what are you guys on the TypeScript team doing to keep TypeScript as a well loved language?
Vue is up and coming. There’s just too many to list, really. But as the different UI frameworks or underlying data manipulation libraries get more popular, we need to make sure that the language is able to represent those. GraphQL is getting popular. Well, can our type system accurately express the things that you need to do with GraphQL? Are there any gaps there?
But we also want to grow very intentionally. Popular programming languages, like you said, are twenty five, thirty, thirty five years old now. And we’re at year eight. If we only have a quarter of the features that we actually need, we’re still on pace.
A: Deno is super cool. I love that someone’s built this tech and is seeing what would happen with it. I think the browser case is really interesting because it seems like it makes sense. Then, every time I walk five steps ahead in my head, it all breaks down for me.
So for me, it’s like, OK, you’re going to serve TypeScript to the client. And then the clients can interpret the TypeScript. Well, if you don’t want type checking on that file that you sent down, then there’s really no point. Stripping off the type annotations is a very mechanical process and there’s not a lot of value there. You can send down source maps or whatever, but that’s more of a diagnostic debugger experience. So we get into this mode where we’re sending this down as TypeScript so it can be type checked by the client.
My first question is, why is this the client’s job? Because you push this TypeScript code up to the server, and I hope that it type checks at the point that you did that. If it didn’t, it’d be weird to consider why you would have done that. And again, development scenarios are just totally a different beast here. I’d like to see more investment in the development space for questions like, would it make more sense to have that?
But anyway, let’s say we keep going and type checking on the client. Well, you can’t really start this type checking process until you’ve pulled all your dependencies in. And then you’re gonna end up sending down .d.ts files that don’t really do anything. And how did the .d.ts file get on your server?
It becomes a question of if you’re debugging or loading, say, production HTML that references the .js files. Where in the process do we actually get the .ts file instead? Never say never. But to me it’s kind of a not soon situation. Deno is completely its own thing because there it’s a new runtime. So that scenario makes a lot more sense to me, at least to be type checking during the first time you run a script and making sure that you’ve got some compatible environments.
Q: What is the status right now of the team at Microsoft? How much has it grown since you joined and how large is it?
A: The whole time we’ve been working on this, we’ve had between four and eight core compiler engineers, one or two PMs, and four to zero dedicated testers. That’s been pretty constant. We’ve been growing the team a little bit more intentionally lately.
We historically have had a core compiler team and then another team working on the Visual Studio side of things, because integrating into a large product like Visual Studio turns out to be a pretty large amount of work. But some architectural improvements on the VS side have freed up some engineer power over there. So we’re roping in that team to help us out with refactoring and Go to Definition and that kind of thing. Same team size overall, except that now we’re gonna have more people working on the core compiler services you see on the GitHub repo.
Q: Could you give me a little perspective on outside of Microsoft—where do you see people helping you to build this in different ways? We talked about Deno and what it does with TypeScript. Where do you see other people helping to build out this ecosystem?
We are utterly dependent on the ecosystem to make a product that works in an integrated environment. So whether that’s webpack or the plugins like ts-loader or how we work with rollup or Parcel or… name your bundler, right? That’s all very complicated.
This doesn’t compute (is incomprehensible): “if you’re if you don’t want type”
like the main thing you should focus your efforts on and you could have started working on this way back ago is to create an actual typescript native compiler that complies typescript into machine code. such thing doesn’t exist! even deno actually does ts -> js before running. you don’t want to stay js helper tool forever, d you?
Just to mention, typescript 4.4 has been released in beta version which focuses on different performance improvement parameters.