This course has been updated! We now recommend you take the Deep JavaScript Foundations, v3 course.

Check out a free preview of the full Deep JavaScript Foundations course:
The "Introducing Types and Coercion" Lesson is part of the full, Deep JavaScript Foundations course featured in this preview video. Here's what you'd learn in this lesson:

Kyle starts with an overview of first core foundation of JavaScript language: Types and Coercion

Get Unlimited Access Now

Transcript from the "Introducing Types and Coercion" Lesson

>> Kyle Simpson: Let's jump into JavaScript. We're gonna start with that first core foundation of the language, types and coercion. I want us to look at the primitive types in JavaScript, and right off the bat that might be a little counterintuitive to you because some of you may have heard before, JavaScript's a dynamic interpreted language, it doesn't have types, false, it absolutely has types.

[00:00:22] It absolutely has value types. If you read the spec, which I happen to have done, turns out there are built in primitive types in JavaScript. The only difference between C++ and JavaScript on the topic of types, the difference between the two is not that JavaScript doesn't have types.

[00:00:38] The real difference is what is typed. In a statically typed language which language is like C++ and Java they fall under that umbrella of statically typed. In a statically typed language we refer to a type as a description for what can go in a variable. In other words the variable itself is typed.

[00:00:59] In dynamic languages, there are still types but we don't focus on the variable, the container having a type. We focus on the value itself, having the type. So, we think about them as value types as opposed to container types. Now, people will disagree on the usage of the word type and you shouldn't call it that, whatever.

[00:01:20] That's a bunch of academic nonsense. If I open up the JavaScript spec, it says primitive types. It uses that word, so let me just give you a definition for that word, type, that we can use, a very pragmatic definition for that word type. The set of intrinsic behaviors that we can expect, given any particular value.

[00:01:42] That's it. Given the value 42, there are behaviors that we can expect. We can expect that we can do math on it. We can expect that we can add, subtract, multiply and divide that number. We can format it to have different number representations like in base 10 or base 16.

[00:02:00] We can expect to do specific things with that number. The value quote 42 on the other hand, while visually they look almost the same, that value has a different set of expectations. Those expectations are well we can access the individual characters. We can do input output with it like print it to the console or add it to a DOM element.

[00:02:24] It's the value types that matter. So we want to look at these primitive types. Natives this actually frankly a kind of confusing part of JavaScript. It's a bit of some historical baggage that we get from the language having been designed to be attractive. It's interesting that JavaScript was designed to be attractive to Java developers, but I've never met any crowd other than the Haskell folks.

[00:02:46] I've never met any crowd in all of programming that hates JavaScript more than the Java developers of the world. And I'm not making that too broadly, obviously there's plenty of people that like to write both but it seems like when I teach the most vocal opponents of JavaScript are those that come from the Java land.

[00:03:04] So interesting that natives were added as one of the ways to try to make JavaScript more palatable to Java developers to make it look more familiar. If you don't know the history of JavaScript, it's Brendan Ike went to Netscape in 1995 wanting to put schema in the browser and in the job interview they're like yeah yeah yeah come put schema in the browser.

[00:03:23] And then when he showed up they're like no no no that's crazy. We're not going to put schema in the browser. Anybody ever had that before? They tell you one thing on the job interview than on the job. [CROSSTALK]
>> Speaker 2: Job was getting hard, right?
>> Kyle Simpson: Java was getting hot and they said now, we need something a little like JavaScript, it can be right a way cuz we can't put Java in the browser.

[00:03:42] that would be crazy to put like a Java plugin in a browser. Make it look like Java then, don't make it look like scheme because that's just academic program. So there's a lot that was added to the language, affordances, if you will, to try to make it look more like that.

[00:03:59] And the truth is, JavaScript actually has a lot more in common with Scheme than it does with Java or C++.
>> Kyle Simpson: It appears on the surface syntactically to be more from the C family of programming languages because we have curly braces and semicolons, everybody's favorite syntactic affordances, right?

[00:04:19] It appears on the surface to be more like that but actually under the covers, it's way more related to scheme. More on the functional nature of JavaScript later. All right, some natives, they are confusing part how we should approach and how we shouldn't do it with them. Then everybody's dreaded topic coercion.

[00:04:41] I really wanna dig into coercion and I want you to understand more about how this is and how it works, and why it's not actually a negative of the language. Coercion is actually a very necessary part of the programming language. And I wanna give you a frame of reference or a different way of thinking about it that suggests that it's something that we actually should embrace in our code.

[00:05:06] And that will lead us into a discussion of equality which is the most common of the misunderstood parts of the types system and the coercion system. How coercion interplays with equality checks