## January 2021

## Java Script Fun and Curiosities

In this post, I want to show some of the funnier sides of JavaScript.

You know "null" for something that isn't really there. But if you ask JavaScript what kind of type this "nothing" is, the answer is that it's an object. But if you ask further whether this null is also an instance of an object, you get a no, since it is "nothing".

What some developers also know is NaN (not a number).

Again, you can ask JavaScript what type of NaN it is. But the answer you get is the astonishing answer that it's a number. But doesn't NaN stand for "not a number"?

You can still ask JavaScript a question, although the answer again surprises us a bit. If you ask if NaN === NaN, you get the answer: no. Since JavaScript gives you a certain amount of freedom, you should always consider what you are doing.

A good example is the undefined. Undefined stands for undefined, eg a variable that has been created but not yet initialized. So you can write the following code in JavaScript:

var variables; variable == undefined

As expected, JavaScript responds to the comparison with: True. But if you rebuild the code as follows, you get a different answer:

undefined = "not defined"; var variables; variable == undefined

JavaScript will now respond with False, since the variable is still undefined, but not "not defined".

JavaScript also supports you in some respects. You can do the typical apples-and-oranges comparison and get a meaningful answer, as you can see in the code example below:

vara = 5; var b = "5"; a == b;

Here an attempt is made to check whether the number 5 is equal to the text 5. JavaScript, recognizing that someone probably just wasn't paying attention, helps us by secretly forming both variables into numbers and recognizing that 5 equals 5.

As a developer, however, it may also be desirable to carry out this comparison correctly. There is a little trick for that:

vara = 5; var b = "5"; a === b;

Another = is added to the comparison. This not only checks what is in the variable, but also whether their data type is actually the same. So you get False as the answer to the query, since 5 is somehow the text 5, but a number is not text.

Unfortunately, JavaScript also has slight problems with arithmetic in some places. Each of us knows that 1 + 2 = 3. JavaScript agrees. However, if you change this calculation just a little, the answer becomes a bit more astonishing: If you calculate 0,1 + 0,2 and expect 0,3 as the result, you will be disappointed by JavaScript, since it claims that the assumption is incorrect.

This is due to machine accuracy. Unfortunately, this builds rounding errors into the calculation, so that the upper floating-point calculation has the following result: 0,30000000000000004.

But JavaScript can also calculate very funny things, and these don't always have to be obvious numbers. So you can add true to true and get… right, 2.

But that is very easy to explain. In the background, the representation of true is a 1.

You can also diligently calculate numbers and texts, since we have already learned that JavaScript thinks along with such actions. The only problem is that it doesn't always think along with you. In the case of the following calculation, the answer is somewhat suspect:

1 + "23" - 10

It's quite simple: We have already learned that JavaScript can turn text into a number. So all I have to do is calculate 1 + 23 = 24 and 24 – 10 = 14. Unfortunately, the JavaScript sees something different. JavaScript's answer is 113, because it calculates the following: 1 + "23" = 123 (the text is only appended to the first number) and 123 - 10 = 113. So we understood that JavaScript does not always calculate text and numbers, but also sometimes attached. Then the following is also clear:

"2" + 1

According to our current knowledge, the answer is 21, which JavaScript also confirms for us.

But what happens in the following case?

"2" - 1

Here the answer is 1 because now the string is formed back into a number. It's a bit confusing that JavaScript thinks along with you from time to time and then again doesn't.

But not only when calculating, but also when comparing, JavaScript does not always respond as we expect it to.

3> 2

We all know, including JavaScript, that this is correct. But what about the following question?

3> 2> 1

That is also clearly correct. But JavaScript sees it differently: 3 > 2 is correct for JavaScript, i.e. true, and we have already learned that true is also a 1 in the background. So the second part of the query would be 1 > 1 and that's not correct.

JavaScript also offers us various functions. One of them is sorting a list.

So if you sort the following list, then we all know what the result is, at least we hope:

[10, 1, 3].sort()

As we learned earlier, it would be too easy if the answer was [1, 3, 10]. No, the answer is [1, 10, 3]. But why is that now?

Unfortunately, the sort function forms the numbers into strings, i.e. text, and then sorts them. And as a string, the 10 in front of the 1 is a 3, which is of course smaller than a XNUMX. JavaScript can be quite confusing.

Finally, let's just make a banana out of a bacterium. How to do this is very simple: we string letters together to form the word bacteria and write it in lower case:

("b" + "a" ++"cteri" + "a").toLowerCase()

Yes, I did press the + twice, but that shouldn't be so bad.

So JavaScript now responds "banana".

But how could that happen?

What happens if we just don't write that in lower case?

("b" + "a" ++ "cteri" + "a")

Now the answer is “baNaNa”.

Now you can see that, oddly enough, NaN, i.e. not a number, is included. But isn't that just text? Unfortunately, the ++ now has the effect that JavaScript tries to increment the cteri by 1. But that doesn't work because it's not a number.

I hope I could make you smile a little. While these are some oddities of JavaScript, they are in no way meant to badmouth JavaScript. JavaScript is a very powerful and important language even today, which has its pitfalls.

**Author**

René Haberstroh

Senior Developer