Values & Types

If you ask an employee at a phone store how much a certain phone costs, and they say “ninety-nine, ninety-nine” (i.e., $99.99), they’re giving you an actual numeric dollar figure that represents what you’ll need to pay (plus taxes) to buy it. If you want to buy two of those phones, you can easily do the mental math to double that value to get $199.98 for your base cost.

If that same employee picks up another similar phone but says it’s “free” (perhaps with air quotes), they’re not giving you a number, but instead another kind of representation of your expected cost ($0.00) — the word “free.”

When you later ask if the phone includes a charger, that answer could only have been either “yes” or “no.”

In very similar ways, when you express values in a program, you choose different representations for those values based on what you plan to do with them.

These different representations for values are called types in programming terminology. JavaScript has built-in types for each of these so called primitive values:

  • When you need to do math, you want a number.
  • When you need to print a value on the screen, you need a string (one or more characters, words, sentences).
  • When you need to make a decision in your program, you need a boolean (true or false).

Values that are included directly in the source code are called literals. string literals are surrounded by double quotes "..." or single quotes ('...') — the only difference is stylistic preference. number and boolean literals are just presented as is (i.e., 42, true, etc.).

Consider:

  1. "I am a string";
  2. 'I am also a string';
  3. 42;
  4. true;
  5. false;

Beyond string/number/boolean value types, it’s common for programming languages to provide arrays, objects, functions, and more. We’ll cover much more about values and types throughout this chapter and the next.

Converting Between Types

If you have a number but need to print it on the screen, you need to convert the value to a string, and in JavaScript this conversion is called “coercion.” Similarly, if someone enters a series of numeric characters into a form on an ecommerce page, that’s a string, but if you need to then use that value to do math operations, you need to coerce it to a number.

JavaScript provides several different facilities for forcibly coercing between types. For example:

  1. var a = "42";
  2. var b = Number( a );
  3. console.log( a ); // "42"
  4. console.log( b ); // 42

Using Number(..) (a built-in function) as shown is an explicit coercion from any other type to the number type. That should be pretty straightforward.

But a controversial topic is what happens when you try to compare two values that are not already of the same type, which would require implicit coercion.

When comparing the string "99.99" to the number 99.99, most people would agree they are equivalent. But they’re not exactly the same, are they? It’s the same value in two different representations, two different types. You could say they’re “loosely equal,” couldn’t you?

To help you out in these common situations, JavaScript will sometimes kick in and implicitly coerce values to the matching types.

So if you use the == loose equals operator to make the comparison "99.99" == 99.99, JavaScript will convert the left-hand side "99.99" to its number equivalent 99.99. The comparison then becomes 99.99 == 99.99, which is of course true.

While designed to help you, implicit coercion can create confusion if you haven’t taken the time to learn the rules that govern its behavior. Most JS developers never have, so the common feeling is that implicit coercion is confusing and harms programs with unexpected bugs, and should thus be avoided. It’s even sometimes called a flaw in the design of the language.

However, implicit coercion is a mechanism that can be learned, and moreover should be learned by anyone wishing to take JavaScript programming seriously. Not only is it not confusing once you learn the rules, it can actually make your programs better! The effort is well worth it.

Note: For more information on coercion, see Chapter 2 of this title and Chapter 4 of the Types & Grammar title of this series.