Interview with Mohamed Hegazy

QCon: What makes TypeScript different than other transpilers we might be familiar with?

Mohamed: TypeScript has two value propositions:

The first is static types. Adding static types to JavaScript allows you to really do large scale application development. Once you go beyond 100 100K lines of code or so and have more than one team working on the code base, JavaScript becomes very hard to manage. Any Other large scale application development tool has constructs like interfaces, modules, and classes that make it easier. JavaScript doesn't have that. So TypeScript tries to add these constructs by adding an optional and a gradual type system on top of JavaScript. We just overlay on top of JavaScript, so that we're not introducing a new language per se, it's more like TypeScript extends the existing tooling.

The second value proposition of TypeScript is we add enabling features from the future. So TC 39 (the JavaScript Committee) has been doing awesome work and adding a lot of features. But for people writing applications for the web today, it's going to be a while until they can have a browser that supports all of these features. You cannot control your browser users on the web. So the other thing that TypeScript gives you is transpiling these features down to ES3 or ES5, where you're sure that you have a browser that supports them.

QCon: You mentioned an optional and gradual type system. Can you explain that?

Mohamed: Mohamed: Most of the type systems for popular languages (like Java, C#, or C++) are not an optional type systems.

You have to give types to things. You cannot say that this guy is a variable, and I'll tell you about its type later. That type of thing increases the barrier of entry in a language. Say you're a seasoned JavaScript developer who isn’t buying into types, why would you even consider something where all the sudden you are forced to use types everywhere?

You’ve been developing without types for years. So what we decided to do was if you have the time (or you have the need), you add types to your code. If you don’t, things still work.

There's multiple things here. The first one is that type limitations are optional, they're not required. You can go and annotate things when you want and when you annotate things, we help you more. So if you say “var x” (and you do not give it a type), we do not know what the type of “x” is. We will not enforce our checks. We're not telling you that any assignment to “x” is wrong, because you didn't tell us what the type of “x” is. But if you do provide the type, we'll flag any assignments that are wrong.

The other part is that we flow types as much as we can. We flow types from declarations, so if you say “var x = 0”, we know that x is a number and that's that. You don't have to tell us about it. So it boils down to, you write types when you think they are useful to you.

If you do not think they are useful, we do not force you to write them.

We also have an option on the compiler as well called the “no implicit any” “--noImplicitAny” flag. Which means do not assume anything about the shape of my objects. If you couldn't infer something (or I didn't annotate it), make it an error. This gives you a total guarantee that there is nothing that went unchecked in your code. It’s like you have a fully typed system, and we know the types of everything coming in and coming out. Once you do that, we can give you the most help we can. Things like: helping you in the tooling, giving you code completion in an editor, or giving you the right errors for your assignments.

QCon: What are your main objectives in the talk?

Mohamed: The main objective would be two things. First, it's going to introduce you to Typescript, like the general description of what Typescript is, how it works, and the tooling around it. The second one is to sell you on adopting Typescript, and that goes into things like how easy it is to adopt Typescript because of it’s gradual and an optional type system. Then the benefits that you would get out of that.

QCon: How do you go about that given you have a very senior audience?

Mohamed: So what I usually do is have a small demo that shows what the tooling is like. I usually show different tools to make it obvious that you are not going to be locked into a product. We're not selling you a license. It's an ecology that is available in different tools and different platforms. Then I show the output (the actual JavaScript output to show you how close is it to your input). The idea is you're not taking a huge risk by converting your source code into TypeScript.

So you get the tooling experience but the code looks more or less the same. I'll probably show code samples with React or Angular.The other code example I like to show is a new thing (which people tend to like) is async. I will show how easy is it to write when you don’t have to worry about promises or callbacks and things like that with TypeScript.