TypeScript 3 Fundamentals, v2 Rationale

[00:00:00]
>> Mike North: So why would we wanna add types? Why would someone bother to make this project? First, it gives us the opportunity to take assumptions and constraints we have as authors when we write a piece of code. It gives us an opportunity to make those a part of our code.

[00:00:17] So if you have a function that's designed to take a string as an argument, you actually have a place where you could say, this argument must be a string. Now, if we were just looking at regular JavaScript, you could write a comment saying, please only pass string to this function.

[00:00:33] But you'd be relying on people reading your source code and finding that. You could assert that it's a string like within the function, throwing error if the type of this value is not a string, but that starts to add up. It starts to get towards something we would call defensive programming.

[00:00:55] Which is where you basically don't trust any of your inputs and it introduces a lot of overhead and complexity, both performance overhead and cognitive overhead, right? You hire a new person to your team and they're gonna have to weave through the stuff and figure out where are the assertions and what's this function actually doing after it's satisfied that the data is correct.

[00:01:18] It makes things a little difficult to maintain. So this types assist us in taking all of our developer intent and encoding it into the code we write. Types help us catch common mistakes, like a spelling error. I make spelling errors a few times a day, at least leading up to my second or third cup of coffee, spelling errors are very common.

[00:01:46] So because there's a validation that you're only accessing the properties that you should be accessing and that you're naming your arguments correctly. You're less likely to make those with types because you've defined what should be accessed, and everything else you should not be trying to touch. An incomplete refactors and other good example.

[00:02:12] Imagine you have a function that you're using in four places and you add another required argument and you only update three of the call sites leaving one out of date. The compiler will let you know that there is a mismatch here, so it helps catch that kind of thing which is very difficult to catch in JavaScript.

[00:02:33] You'll see throughout our work today that we're moving a lot of errors we would find at run time up to compile time. So we're getting earlier feedback and we're getting feedback as a result of static analysis. Which is an analysis that just looks at your source code and comes to conclusions.

[00:02:53] As opposed to runtime analysis which requires you to actually go through and execute every path of your code. So you could catch some of the stuff with tests, absolutely. But while you're writing your code and maybe you haven't written your test yet, or maybe your test are incomplete, is anyone here worked on a project that has an imperfect test suite?

[00:03:17] I have, all hands should go up right now. All of your test suits are probably imperfect. So, this means you are not depending on tests to catch this type of error. You certainly can make other types of errors. And then finally right away, you're gonna see that TypeScript is the foundation of a great developer experience.

[00:03:36] It's something that the JavaScript ecosystem has kind of been missing relative two typed programming languages. So I started out as a Java developer and I used a wide-range of IDEs to write my code in. And I've got a lot of outlines showing me these are the classes and these are the members of the classes, and these are public and these are private.

[00:04:01] And I got great auto-completes because the language was setup in such a way that you could know what you're supposed to be accessing and what you're not. And what is the value of the thing you are accessing? This is much harder to figure out in a dynamically typed language like JavaScript or Ruby.