Understanding Your Types

[00:00:00]
>> Kyle Simpson: So wrapping up our whole discussion on types in coercion, we're wrapping up this unit. Let me make some final observations. Number one, it is true, it is a fact that JavaScript has a dynamic type system, it is a type system, it just is dynamic. I've really bristle when people say JavaScript has no types, it definitely does, it's a type system, it's just not Java's type system.

[00:00:24]
It uses various forms of coercion but they're for value type conversions rather than variable typing. And we also have equality comparisons that can be coerced. The prevailing response to JavaScript's type system is essentially avoid as much of the system as possible and only use the triple to protect yourself so that you don't have to worry about them.

[00:00:51]
As I've said several times now, I don't think that that is an effective strategy. Part of the problem with avoidance of anything but especially an entire unit of of the language like that, is that it tends to systematically perpetuate bugs. That is to say it's not that one bug will happen or one bug won't happen but the mindset that says, I don't even need to understand this whole part of the language, perpetuates bugs, that's a systematic approach, and I would never recommend a systematic avoidance of any particular thing, that is avoidance of even understanding it.

[00:01:29]
>> Kyle Simpson: What this boils down to is that I just believe that you can not write quality JavaScript programs without understanding your types. You can write JavaScript programs that shift and run but they don't meet that bar of what I think we should be striving for in quality unless you understand those types and unless the readers of your code can understand those types.

[00:01:48]
So we have to do something. We've got to change the way we structure our code. We've got to use these mechanisms that are available to us to start signaling those typing things. And of course, you could go all the way to using a whole static type system, like a typescript or a flow.

[00:02:05]
And if that's your answer, I'm not gonna beat you up, right? Like that's okay, and that makes sense for a lot of teams. But I do think that there's a way to embrace that because I really think that's almost an avoidance of the issue as well. It's a different kind of avoidance.

[00:02:20]
You're basically saying JavaScript system is hopeless, so let's build a whole new system. That's a different kind of avoidance, and I'm not sure that it's healthy. So, [COUGH], I don't think JavaScript's types are inferior, I think they can be learned and leveraged, and I don't think it's that much more difficult.

[00:02:40]
In fact, I think it's less difficult for you to learn this system taught properly than to go learn all the complexities of a static type system. I mean like thinking about all the sophistication and typescript, I would consider that to be a very daunting task. And I think what I'm trying to discuss here is a much simpler and smaller thing to learn.

[00:03:00]
So my claim is that really the better approach is to embrace JavaScript's types and adopt the coding style which goes with that grain, that makes those things obvious. You are going to have better code as a result. By thinking about those things, you are going to structure your code better, that's almost undebatable.

[00:03:21]
But if you think about your code better and you think about your types and you design things so that you understand what they're doing, you'll end up designing better code, and that code will be more robust, it'll have fewer bugs. And that's if you do nothing with the double equals, just think about your types, right?

[00:03:35]
You don't even have to use the double equals to get that benefit. So if you hear nothing else about me, at least from me on this unit, at least hear that. You should be striving for that in your code. I think you can optionally choose to use other approaches, and maybe Typl is one of several that could begin to exist in the ecosystem that give other options besides these extremes.

[00:03:57]
So hopefully that is gonna open some different avenues of analysis, really that's all I ask, is that you go back and think about those things, test out the assertions that I'm making, and see if they make sense for you and for your code. But I'm quite confident that your code quality will suffer if you persist in the I don't need to know types, right?

[00:04:21]
Triple equals is all I ever need. I just don't think that's better code. So, hopefully I've given you some food for thought. That is it for the types and coercion unit of our course.