Chapter 1: Types

Most developers would say that a dynamic language (like JS) does not have types. Let’s see what the ES5.1 specification (http://www.ecma-international.org/ecma-262/5.1/) has to say on the topic:

Algorithms within this specification manipulate values each of which has an associated type. The possible value types are exactly those defined in this clause. Types are further sub classified into ECMAScript language types and specification types.

An ECMAScript language type corresponds to values that are directly manipulated by an ECMAScript programmer using the ECMAScript language. The ECMAScript language types are Undefined, Null, Boolean, String, Number, and Object.

Now, if you’re a fan of strongly typed (statically typed) languages, you may object to this usage of the word “type.” In those languages, “type” means a whole lot more than it does here in JS.

Some people say JS shouldn’t claim to have “types,” and they should instead be called “tags” or perhaps “subtypes”.

Bah! We’re going to use this rough definition (the same one that seems to drive the wording of the spec): a type is an intrinsic, built-in set of characteristics that uniquely identifies the behavior of a particular value and distinguishes it from other values, both to the engine and to the developer.

In other words, if both the engine and the developer treat value 42 (the number) differently than they treat value "42" (the string), then those two values have different types — number and string, respectively. When you use 42, you are intending to do something numeric, like math. But when you use "42", you are intending to do something string’ish, like outputting to the page, etc. These two values have different types.

That’s by no means a perfect definition. But it’s good enough for this discussion. And it’s consistent with how JS describes itself.

A Type By Any Other Name…

Beyond academic definition disagreements, why does it matter if JavaScript has types or not?

Having a proper understanding of each type and its intrinsic behavior is absolutely essential to understanding how to properly and accurately convert values to different types (see Coercion, Chapter 4). Nearly every JS program ever written will need to handle value coercion in some shape or form, so it’s important you do so responsibly and with confidence.

If you have the number value 42, but you want to treat it like a string, such as pulling out the "2" as a character in position 1, you obviously must first convert (coerce) the value from number to string.

That seems simple enough.

But there are many different ways that such coercion can happen. Some of these ways are explicit, easy to reason about, and reliable. But if you’re not careful, coercion can happen in very strange and surprising ways.

Coercion confusion is perhaps one of the most profound frustrations for JavaScript developers. It has often been criticized as being so dangerous as to be considered a flaw in the design of the language, to be shunned and avoided.

Armed with a full understanding of JavaScript types, we’re aiming to illustrate why coercion’s bad reputation is largely overhyped and somewhat undeserved — to flip your perspective, to seeing coercion’s power and usefulness. But first, we have to get a much better grip on values and types.