What's the difference between & and && in JavaScript?

What's the difference between & and && in JavaScript?

Example code:

var first  = 123;
var second = false;
var third  = 456;
var fourth = "abc";
var fifth  = true;
alert(first & second); // 0
alert(first & third);  // 72
alert(first & fourth); // 0
alert(first & fifth);  // 1

alert(first && second); // false
alert(first && third);  // 456
alert(first && fourth); // abc
alert(first && fifth);  // true

It seems like && is a logical and which gives me always the second value if both are true.

But what is &?

(By the way, && seems to be and in Python; & seems to be & in Python)

& is bitwise AND

This operator expects two numbers and retuns a number. In case they are not numbers, they are cast to numbers.

How does it work? Wikipedia has an answer: https://en.wikipedia.org/wiki/Bitwise_operation#AND

Note: In Javascript, the usage of this operator is discouraged, since there's no integer data type, just floating point. Thus floats are converted to integers prior to every operation, making it slow. Also, it has no real use in typical web applications and produces unreadable code.

General rule: Avoid. Don't use it. It rarely has place in a maintainable and readable JS code.

&& is logical AND

It expects two arguments and returns:

• First term that evaluates to false
• Last term otherwise (if all are true-y)

Here are some examples:

0 && false			0 (both are false-y, but 0 is the first)
true && false		false (second one is false-y)
true && true		true (both are true-y)
true && 20			20 (both are true-y)

If you only ever use it on Boolean, this is exactly the AND operator from mathematical logic.

&& operator chaining

The reason this operator is defined as above is operator chaining. You are able to chain this operator and still keep the above rules.

true && 20 && 0 && false		0 (it is the first false-y)
10 && 20 && true && 100			100 (last one, since all are true-y)

&& short-circuiting

As can be seen from the definition, as soon as you find that one term is false-y, you needn't to care about the following terms. Javascript even takes this a notch further, the terms are not even evaluated. This is called short circuiting.

true && false && alert("I am quiet!")

This statement doesn't alert anything and false is returned. Therefore, you could use the && operator as a shorter replacement for an if statement. These are equivalent:

if (user.isLoggedIn()) alert("Hello!")
user.isLoggedIn() && alert("Hello!")

Almost all JS compressors use this trick to save 2 bytes.

& is the bitwise "and". This means that if you have two numbers converted to binary, the result is a number that has the 1 digit at the positions where both numbers have 1.

  100011  //35
& 111001  //57
---------
  100001  //35 & 57 == 33

To determine whether two boolean values put together are true or false, if you want to check them both (like validation on the web page), you may use the & operator. & is bitwise AND.

With the && operator, once it finds the first value is false, it will end evaluation and not to check the second value.

With all the lofty, detailed insights throughout, they have mostly missed the truth that there is a conditional evaluation where ONLY the single & will work. The practical layman's answer that solved my head beating on an IF statement string of MULTIPLE chained && each !== to a condition was causing FAILURE and needed to legitimately use the single &. I thank Jake Wayne (and Russ) for their unfairly downvoted answer that got it right given that where there is more than one && that !== it has already ceased its evaluation and proceeds no further after the first evaluation is found ==!. With the && it thinks its job is done after the first evaluation shows !== [eg. false]. My failing code was

IF ((sessionStorage.myLable !== "LableStringA") && (sessionStorage.myLable !== "LableStringB") && (sessionStorage.myLableZ !== "LableStringA") && (sessionStorage.myLableZ !== "LableStringB")) { ...)

Here, properly substituting and using a single & for the && it was both practically in the real world and technically the correct answer. Thank you again Jake Wayne (and Russ) for the insight and understanding of code.