DEV Community

Cover image for Comparing Apples to Oranges in JavaScript: Implicit Type Coercion
Anthony Chung
Anthony Chung

Posted on • Updated on

Comparing Apples to Oranges in JavaScript: Implicit Type Coercion

While it is unusual to compare apples to oranges in our everyday lives, it is quite common to do so in the world of programming where we often perform operations on numbers, strings, and other data types. This is especially true for JavaScript since it is a weakly-typed (or loosely-typed) language, where we are not required to declare the data type of a variable before operating on the variable. This is unlike a strongly-typed language, such as Java, where variables need to be bound to specific data types. You might now be thinking, "Why don't we just make everything loosely-typed since it seems more convenient?". Well, the thing is, loosely-typed languages can be more of a headache than it seems...

What is Implicit Type Coercion?

To expand on the headache, we first need to know about how JavaScript interprets and manages loosely-typed variables. When we perform an operation on two values, as shown below, JavaScript automatically converts the type of one value to match that of the other if they do not match initially.

const x = 1; // this is a number
const y = "thing"; // this is a string

x + y; // returns "1thing", which is a string
Enter fullscreen mode Exit fullscreen mode

This automatic conversion is also called an implicit type coercion since a value's data type is forcefully converted.

Some strongly-typed languages like Java can also perform limited implicit type coercions. For example, the above expression of 1 + "thing" would similarly return "1thing" in Java. In addition, Java can implicitly convert smaller data types to larger data types under certain contexts.

So this seems convenient so far, right?

Well, let's now look at a different example:

1 + "2" + 1;
Enter fullscreen mode Exit fullscreen mode

What do you think will be returned from this expression? You might think that the "2" would be converted to a number so that the overall expression would evaluate to 4. However, the expression actually returns something else:

1 + "2" + 1; // returns "121"
Enter fullscreen mode Exit fullscreen mode

We get a string of "121"! This happens because of two important reasons:

  1. Whenever there is a string operand during a + operation, JavaScript automatically assumes that the + is the concatenation operator and combines the two operands as if they are both strings.
  2. JavaScript reads the expression from left to right (and follows the order of operations specified by PEMDAS) so that it is only performing one operation at a time. For the example above, 1 + "2" would first evaluate to the string, "12", before it encounters the + 1 on the right.

As you can see, the implicit type coercion behavior of JavaScript can become more and more perplexing as the expressions get more and more... funkier:

true ^ null; // returns 1
(NaN == NaN) + {}; // returns "false[object Object]
{} + !null + []; // returns "1"
((1001 - "1,001") == null) == "" // returns true; 
Enter fullscreen mode Exit fullscreen mode

You will probably never have to encounters the funky examples above (hopefully) so don't worry too much about not understanding them.

Should we ignore the elephant in the room?

Due to the seemingly unpredictable nature, implicit type coercion is generally considered a JavaScript feature that is best avoided when possible (which makes it *ehem* the elephant in the room). However, I would argue that it is resourceful to study up on since it will likely help you track down any type coercion-related bugs in your programming future.

In addition, implicit type coercion allows you to use nifty shortcuts such as:

!!value; // two !("bang") operators coercively returns the value's boolean value
+value // converts the value to a numeric value
"" + value // any value that comes after the "" is evaluated as a string
Enter fullscreen mode Exit fullscreen mode

Although, it is discouraged to use too much shortcut in programming (since it makes code less readable), the above shortcuts are used widely among programmers and are universally deemed as syntactic sugar.

Conclusion

At first glance, JavaScript's implicit type coercion feature may seem unfamiliar and even too convoluted to effectively utilize. However, once you get a better handling of how weakly-typed languages work, you will soon be able to embrace implicit type coercion as a pro rather than a con as you progress through your programming career.

If you are curious to know more about how implicit type coercion works, feel free to check out the resources below. Alternatively, you can try your own cocktails of mixed data types to generate different (and oftentimes surprising) responses.

Have fun!

Resources

Top comments (0)