This course has been updated! We now recommend you take the TypeScript Fundamentals, v3 course.

Check out a free preview of the full TypeScript Fundamentals course:
The "Adding Types" Lesson is part of the full, TypeScript Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Mike reviews reasons for adopting types.

Get Unlimited Access Now

Transcript from the "Adding Types" Lesson

>> Mike North: Why would we want to add types? We saw that JavaScript does some potentially unintuitive things to convert primitive types just with operators. And when we think about checking for equivalents and other things like that, there is often no effort to convert or even define the type of things, right?

[00:00:23] There's no effort to define whether the structure of an object is equivalent to the structure of another object.
>> Mike North: So one of the things we hope that types will help us do is take some run time errors and move them upstream into compile time errors. This is always a good thing.

[00:00:37] You'll always want to be the one that catches the error on the devbox, not to get a bug report from your user. Types serve as the basis for excellent documentation to your fellow developers. So has anyone here tried to write a Webpack configuration? Right, so it's a pretty involved object, is it not?

[00:00:56] And when you say, export this object from your Webpack config JavaScript file. You have to go to the documentation and you have to read, here are the various properties and these are the values those properties can have. And eventually, you end up having this thing that works. In the Typescript world, we would say, well no, that's not just a regular object, it's an object of this type.

[00:01:19] And we have upfront defined the valid properties you can define and the valid types of values that those things can have and as a result, that is right there, right in your editor. It's not something that you have to go flip back and forth between documentation and code form.

>> Mike North: So, [LAUGH] this fourth point here, clever abstractions that you're so excited about are now safer to use. So I am fortunate enough to work with some really amazing programmers in the Ember ecosystem. And some of these programmers like Yehuda Katz and Tom Dale, they're involved with TC 39 where they define the JavaScript language standard.

[00:02:07] That's the standard body there. So these are good JavaScript programmers. They have been working on a project called Glimmer for a while now, and this is the rendering engine for Ember. And I don't think they would have a problem with me, say they ended up before writing it in Typescript, tripping over their own shoelaces several times.

[00:02:31] It's an extremely complicated task that they're trying to perform. It's a very involve project that involves virtual machine style architecture and Typescript is what let them actually, on like the third attempt or something, get it working. Because even for those expert programmers, the loosely typed nature of JavaScript just kept snagging them again, and again, and again.

[00:03:00] We can only do so much, we're humans, right, we can only remember so much. We can only keep so much straight, and these are not training wheels, these are tools for kind of taking on more ambitious challenges, and being able to get past that point where. And I think we've all been there or we all will be there one day, but that point where things are so complex that a project is basically starting to collapse under its own weight or under its own complexity.

[00:03:34] So Glimmer is a great example there of something that due to Typescript now is going very well. And previous attempts, which involved regular JavaScript, they basically fell flat again and again. Last reason, not the last reason, but my final reason here to add types. We have to take into account that modern JavaScript run types are written in typed languages like C++.

[00:04:03] So, if we just to give you a sneak pick here, I don't think we'll talk about this in too much depth, but the idea of how Chrome works under the hood is there an interpreter and a compiler. The interpreter starts running your code, right? Runs, say a function that you've defined.

[00:04:27] And if you are very consistent about the way you use that function and you start to use it over and over and over and over again. Chrome will say, well hey, we've got some information about the use of this function. And it seems that the same number of arguments are being passed in, the types of those arguments are the same, I wonder if we could start to kind of optimize this a bit.

[00:04:51] And it will promote it from the interpreter and it'll let the optimizing compiler handle it. If you hear the name Ignition that's the name of the interpreter, TurboFan is the name of the compiler. And at that point it's basically gonna turn your JavaScript into assembly code for the architecture that your machine's using and cache some portion of that assembly code for reuse on the subsequent function calls.

[00:05:21] So if you, the term a lot of people use here is that function just became hot code. Meaning it's running fast and it's in this optimized mode. As soon as you mess with the types, as soon as you break the rules of the strongly typed world, that code goes back into slow mode again.

[00:05:44] So Typescript gives us some constraints that help us get into that hot mode and stay there.