Transcript from the "Benefits of Types" Lesson
>> Mike North: So first I want to do the best I can to convince you that Types are a good thing to use. Any time you can catch a bug at compile time instead of run time, you are better off for that. You basically want things that are gonna break.
[00:00:40] So this is not, it will help catch newbie mistakes, this is a tool that will help keep us honest and keep us writing things in a well defined way regardless of level of experience. So Types provide a better developer experience. It is not like all these little auto complete hints you've been seeing pop up when I code.
[00:01:22] We know what type it's gonna be, and therefore, it's easy to use what is called this TypeScript language service to say, okay, give me all of the functions that are available on this object. Tell me what are the valid completions here. And you can present that in the UI and the IntelliSense like auto complete.
[00:01:43] Third point here is you want your code to be an expression of your intent as a developer. So if I had this function here and I passed in two numbers, what do you think that this function would do? That's a question for you. It's not a rhetorical question.
[00:02:02] So if I had a function add and I pass in three and four, what would you expect to happen?
>> Speaker 2: Add it together?
>> Speaker 3: Three plus four.
>> Mike North: We'd get seven, right? We'd be doing arithmetic. Now if I had a function like that and I passed in as the first argument, an array, and the second argument I parse like an object, what might you expect to happen?
>> Mike North: I think, maybe we should concat that item into the array, we should push it into the array. So this here, this is a poor expression of an intent, right? This, without knowing what types of objects these are, this is ambiguous, right? This could mean there are multiple interpretations of add.
[00:03:08] Something like that. But just adding the types there, that would help us understand, all right, this is what we're working with here. This is what I should be passing in here. Even for options objects, if you've ever used Fetch or Ajax, you're passing a URL as a first argument, that's pretty straightforward.
[00:03:26] But then you have this options object and we don't know, you have to go and look at the documentation to figure out what are all the properties here. Like is there a well defined structure for this object and if so what am I allowed to use? If we have Types, then we say, okay, well, somewhere in code it is the structure of this object is defined.
[00:03:45] Show me that, right click on it, show me the type definition. Like, now we know exactly what this is designed to receive. So, it goes a long way in terms of helping us build more intent into code. I don't remember, I wish I could credit the person that I heard this from, I don't remember it.
[00:04:03] But there's a nice quote I like which is, the signature of your function, this what you're seeing on your screen, that is almost like a hypothesis and the implementation of the function is the proof that it works. So, you need to have a well defined statement of what you're trying to do in order for there to be any hope with it like people are going to use it properly.
[00:04:33] Finally, you by writing things in a way that is aligned with a strongly typed language, you avoid situations where your code can be de-optimized. And I could go much deeper into this topic, but let me do the best I can to see if we can just touch on it.
[00:05:25] If your code is found to be reliably behaving in the same way. Meaning, it's an object that has consistent properties on it, it always has the same names of properties and the values of those properties are always of the same type. We would actually call this the shape of this object is the same.
[00:06:05] That runs right on the architecture that that particular browser is built for. And it ends up running a lot faster, right? Compiled code is a lot faster in general than interpreted code. So, you're in the fast lane now. We would call this code hot, like this is a hot function, it is now optimized.
[00:06:25] If you break the rules once, if you basically like change the type of one of those values and now you sort of break with the assumptions or break, you deviate from that consistent behavior that got you into the fast lane, you're back into slow lane again. And potentially code that's around that, that's using it, also back in the slow lane.
[00:06:45] And it becomes de-optimized. And you're in the penalty box basically forever. I mean, until the next page load, until you basically start the program again. So, writing code in a strongly typed way where you're forced, you basically get errors or warnings whenever you add a property that wasn't there before, or you change the type of the value of a property, you want to get those errors.
[00:07:10] You want to detect those while you're developing so that your code is more likely to remain in this fast lane, in this optimized compiler and to not fall out.
>> Mike North: So when you're optimized, even the assembly that's used to sort of set up the initial function invocation, maybe it's just taking arguments and making them available on the particular names and sort of allocating memory for the closure.
[00:07:40] That assembly code is actually cached and reused over and over and over for repeated function invocations or repeated use of an object. So you kinda get the benefit of caching and reusing stuff, and you're dealing with compiled code, not interpreted code. So you want to be strongly typed, or consistent use of property names and types will get you into a position where you're more likely to be optimized.
>> Speaker 4: You might have a question in chat you haven't addressed.
[00:08:32] So in order for ES6 to just be a collection of features that are added on top of ES5, for it to be just the next version of the same programming language, we can't really add Types to it. Now remember, there are Types in ES6 but it is a dynamically typed language.