cool facts

Cool Facts About Javascript

JavaScript is a great language. It has a simple syntax, large ecosystem and, what is most important, a great community. At the same time, we all know that JavaScript is quite a funny language with tricky parts. Some of them can quickly turn our everyday job into hell, and some of them can make us laugh out loud.
source : wtfjs

Examples:

`[]`is equal to`![]`

Array is equal not array:

[] == ![] // -> true

💡Explanation

The abstract equality operator converts both sides to numbers to compare them, and both sides become the number 0 for different reasons. Arrays are truthy, so on the right, the opposite of a truthy value is false, which is then coerced to 0. On the left, however, an empty array is coerced to a number without becoming a boolean first, and empty arrays are coerced to 0, despite being truthy.
Here is how this expression simplifies:

    +[] == +![]
    0 == +false 
    0 == 0
    true

true is false!

!!'false' == !!'true' // -> true
!!'false' === !!'true' // -> true

💡Explanation

Consider this step-by-step:

// true is 'truthy' and represented by value 1 (number),
'true' in string form is NaN. 
true == 'true' // -> false 
false == 'false' // -> false 

// 'false' is not the empty string,
so it's a truthy value 
!!'false' // -> true 
!!'true' // -> true

`NaN`is not a `NaN`

NaN === NaN // -> false

💡Explanation

This specification strictly defines the logic behind this behavior:

IfType(x) is different from Type(y), return false.

If Type(x) is Number, thenIf x is NaN, return false.If y is NaN, return false.

strict equality comparison

It's a fail

You would not believe, but …

(![]+[])[+[]]+(![]+[])[+!+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]
// -> 'fail'

💡Explanation

By breaking that mass of symbols into pieces, we notice that the following pattern occurs often:

(![]+[]) // -> 'false'
![] // -> false

So we try adding [] to false. But due to a number of internal function calls (binary + Operator -> ToPrimitive -> [[DefaultValue]]) we end up converting the right operand to a string:

(![]+[].toString()) // 'false'

Thinking of a string as an array we can access its first character via [0]:

'false'[0] // -> 'f'

The rest is obvious, but the i is tricky. The i in fail is grabbed by generating the string 'falseundefined' and grabbing the element on index ['10'].

`[]` is truthy, but not `true`

An array is a truthy value, however, it's not equal to true.

!![] // -> true
[] == true // -> false

💡Explanation

Here are links to the corresponding sections in the ECMA-262 specification:

Logical NOT operator

Abstract Equality Comparison

`null`is falsy, but not `false`

Despite the fact that null is a falsy value, it's not equal to false.

!!null // -> false
null == false // -> false

At the same time, other falsy values, like 0 or '' are equal to false.

💡Explanation

The explanation is the same as for previous example. Here's the corresponding link:

Abstract Equality Comparison

`document.all` is an object, but it is undefined

Despite the fact that document.all is an array-like object and it gives access to the DOM nodes in the page, it responds to the typeof function as undefined.

document.all instanceof Object // -> true
typeof document.all // -> 'undefined'

At the same time, document.all is not equal to undefined.

document.all === undefined // -> false
document.all === null // -> false

But at the same time:

document.all == null // -> true

💡Explanation

document.all used to be a way to access DOM elements, in particular with old versions of IE. While it has never been a standard it was broadly used in the old age JS code. When the standard progressed with new APIs (such as document.getElementById) this API call became obsolete and the standard commitee had to decide what to do with it. Because of its broad use they decided to keep the API but introduce a willful violation of the JavaScript specification. The reason why it responds to false when using the Strict Equality Comparison with undefined while true when using the Abstract Equality Comparison is due to the willful violation of the specification that explicitly allows that.
Obsolete features - document.all at WhatWG - HTML spec — Chapter 4 - ToBoolean - Falsy values” at YDKJS - Types & Grammar

Minimal value is greater than zero

Number.MIN_VALUE is the smallest number, which is greater than zero:

Number.MIN_VALUE > 0 // -> true

💡Explanation

Number.MIN_VALUE is 5e-324, i.e. the smallest positive number that can be represented within float precision, i.e. that's as close as you can get to zero. It defines the best resolution that floats can give you. Now the overall smallest value is Number.NEGATIVE_INFINITY although it's not really numeric in a strict sense.
StackOverflow

Number.MIN_VALUE

Adding arrays

What if you try to add two arrays?

[1, 2, 3] + [4, 5, 6] //
->'1,2,34,5,6'

💡Explanation

The concatenation happens. Step-by-step, it looks like this:

[1, 2, 3] + [4, 5, 6]
// call toString() 
[1, 2, 3].toString() + [4, 5, 6].toString() 
// concatenation 
'1,2,3' + '4,5,6' 
// -> 
'1,2,34,5,6'

Trailing commas in array

You've created an array with 4 empty elements. Despite all, you'll get an array with three elements, because of trailing commas:

let a = [,,,] 
a.length // -> 3 
a.toString() // -> ',,'

💡Explanation

Trailing commas (sometimes called "final commas") can be useful when adding new elements, parameters, or properties to JavaScript code. If you want to add a new property, you can simply add a new line without modifying the previously last line if that line already uses a trailing comma. This makes version-control diffs cleaner and editing code might be less troublesome.
MDN

Array equality is a monster

Array equality is a monster in JS, as you can see below:

[] == '' // -> true
[] == 0 // -> true 
[''] == '' // -> true 
[0] == 0 // -> true 
[0] == '' // -> false 
[''] == 0 // -> true 

[null] == '' // true 
[null] == 0 // true 
[undefined] == '' // true 
[undefined] == 0 // true 

[[]] == 0 // true 
[[]] == '' // true 

[[[[[[]]]]]] == '' // true 
[[[[[[]]]]]] == 0 // true 

[[[[[[ null ]]]]]] == 0 // true
[[[[[[ null ]]]]]] == '' // true 

[[[[[[ undefined ]]]]]] == 0 // true 
[[[[[[ undefined ]]]]]] == '' // true

💡Explanation

This behavior is described in above mentioned Abstract Equality Comparison.

`undefined` and `Number`

If we don't pass any arguments into the Numberconstructor, we'll get 0. The value undefined is assigned to formal arguments when there are no actual arguments, so you might expect that Number without arguments takes undefined as a value of its parameter. However, when we pass undefined, we will get NaN.

Number() // -> 0 
Number(undefined) // -> NaN

💡Explanation

According to the specification:

If no arguments were passed to this function's invocation, let n be +0.
Else, let n be ? ToNumber(value).
In case of undefined, ToNumber(undefined) should return NaN.

Here's the corresponding section:

The Number constructor

`parseInt` is a bad guy

parseInt is famous by its quirks:

parseInt('f***'); // -> NaN 
parseInt('f***', 16); // -> 15

This happens because parseInt will continue parsing character-by-character until it hits a character it doesn't know. The f in 'f***' is the hexadecimal digit 15. Parsing Infinity to integer is something…

// parseInt('Infinity', 10) // -> NaN 
// ... 
parseInt('Infinity', 18) // -> NaN... 
parseInt('Infinity', 19) // -> 18 
// ... 
parseInt('Infinity', 23) // -> 18... 
parseInt('Infinity', 24) // -> 151176378 
// ... 
parseInt('Infinity', 29) // -> 385849803 
parseInt('Infinity', 30) // -> 13693557269 
// ... 
parseInt('Infinity', 34) // -> 28872273981 
parseInt('Infinity', 35) // -> 1201203301724 
parseInt('Infinity', 36) // -> 1461559270678... 
parseInt('Infinity', 37) // -> NaN

Be careful with parsing null too:

parseInt(null, 24) // -> 23

💡Explanation

It's converting null to the string "null"and trying to convert it. For radixes 0 through 23, there are no numerals it can convert, so it returns NaN. At 24, "n", the 14th letter, is added to the numeral system. At 31, "u", the 21st letter, is added and the entire string can be decoded. At 37 on there is no longer any valid numeral set that can be generated and NaN is returned.
StackOverflow

Don't forget about octals:

parseInt('06'); // 6 
parseInt('08'); // 8 if support ECMAScript 5 
parseInt('08'); // 0 if not support ECMAScript 5

💡Explanation

If the input string begins with "0", radix is eight (octal) or 10 (decimal). Exactly which radix is chosen is implementation-dependent. ECMAScript 5 specifies that 10 (decimal) is used, but not all browsers support this yet. For this reason always specify a radix when using parseInt. parseInt always convert input to string:

parseInt({ toString: () => 2, valueOf: () => 1 }) // -> 2 
Number({ toString: () => 2, valueOf: () => 1 }) // -> 1

Math with `true` and `false`

Let's do some math:

true + true // -> 2 
(true + true) * (true + true) - true // -> 3

💡Explanation

We can coerce values to numbers with the Number constructor. It's quite obvious that true will be coerced to 1:

Number(true) // -> 1

The unary plus operator attempts to convert its value into a number. It can convert string representations of integers and floats, as well as the non-string values true, false, and null. If it cannot parse a particular value, it will evaluate to NaN. That means we can coerce true to 1 easier:

+true // -> 1

When you're performing addition or multiplication, the ToNumber method is invoked. According to the specification, this method returns:

If argument is true, return 1. If argument is false, return +0.

That's why we can add boolean values as regular numbers and get correct results.

Corresponding sections:

Unary + Operator

The Addition Operator (+)

ToNumber(argument)

HTML comments are valid in JavaScript

You will be impressed, but <!-- (which is known as HTML comment) is a valid comment in JavaScript.

// valid comment
<!-- valid comment too

💡Explanation

Impressed? HTML-like comments were intended to allow browsers that didn't understand the <script> tag to degrade gracefully. These browsers, e.g. Netscape 1.x are no longer popular. So there is really no point in putting HTML comments in your script tags anymore.

Since Node.js is based on the V8 engine, HTML-like comments are supported by the Node.js runtime too. Moreover, they're a part of the specification:

HTML-like comments

NaN is not a number

Type of NaN is a 'number':

typeof NaN // -> 'number'

💡Explanation

Explanations of how typeof and instanceof operators work:

The typeof Operator

Runtime Semantics: InstanceofOperator(O,C)

`[]` and `null` are objects

typeof [] // -> 'object' 
typeof null // -> 'object' 

// however 
null instanceof Object // false

💡Explanation

The behavior of typeof operator is defined in this section of the specification:

The typeof Operator

According to the specification, the typeofoperator returns a string according to Table 35: typeof Operator Results. For null, ordinary, standard exotic and non-standard exotic objects, which do not implement [[Call]], it returns the string "object".

However, you can check the type of an object by using the toString method.

Object.prototype.toString.call([]) // -> '[object Array]' 
Object.prototype.toString.call(new Date) // -> '[object Date]' 
Object.prototype.toString.call(null) // -> '[object Null]'

Cool facts about javascript