Benefits of Types

[00:00:00]
>> 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:14]
You want them to break hard and break right now, so that you can identify them and fix them and those things never make it out into production. And these type errors, type mismatch errors, they happen all the time in JavaScript. They happen for very experienced developers. They happen for people that are on the TC 39 like JavaScript's standards body.

[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:02]
This is not magic from Visual Studio Code. It's just simply that we know exactly when we're working with an object that that is a promise or that's a window object. And it's not just an arbitrary JavaScript thing and we're gonna see what happens when we run our code and hope that all those properties that we need are there.

[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?

[00:02:25]
>> 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:02:44]
There are multiple interpretations of remove. And so being able to say, this function is called add, and, well, first of all, I've picked terrible variable names here. That's mostly what we do as JavaScript developers. We might try to add some better intent here by saying add, and then the first argument's array, and the second argument is item to add into array.

[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:04:49]
So let's look at one popular, modern JavaScript runtime, Chrome, or the V8 engine inside Chrome more specifically. That's where your JavaScript runs. So there are two pieces of program machinery inside Chrome, one is called ignition and that is an interpreter for JavaScript, right? It works the way all interpreters work in that it takes your source code directly and basically like statement by statement, expression by expression, it's going to build things up as it goes and execute what you told it to execute.

[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:05:44]
Where shape simply means, names of properties, and the types of the values of those properties. If that's found to be consistent, your code gets promoted into this second, faster piece of the V8 run time and it's called Turbo Fan. And that is a compiler for JavaScript. It actually takes your JavaScript and makes assembly code out of it.

[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.

[00:08:07]
Yes?
>> Speaker 4: You might have a question in chat you haven't addressed.
>> Mike North: Question from chat. So why does ES6 not support Types? Simple answer there is ES6 is designed to be a super set of ES5. And adding Types in that is not backwards compatible, really. And for that matter, it would be changing the fundamental nature of JavaScript, which you really can't do.

[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.

[00:08:51]
There are no strong Types, right? Which is why we can have an array and put two strings and then a number and then a function, and then another array, and then the window object. That can all exist quite happily in the same array. So we want to make sure that when we say, next generation of JavaScript, we are not crossing a line and saying that that's not okay anymore.

[00:09:15]
It may be that it is not okay anymore, if you want your code to be fast. But we can't make that disruptive change to JavaScript.