Why is there no logical xor in JavaScript?

Why is there no logical xor in JavaScript? - javascript

Why is there no logical xor in JavaScript?

JavaScript traces its ancestry back to C, and C does not have a logical XOR operator. Mainly because it's not useful. Bitwise XOR is extremely useful, but in all my years of programming I have never needed a logical XOR.
If you have two boolean variables you can mimic XOR with:
if (a != b)
With two arbitrary variables you could use ! to coerce them to boolean values and then use the same trick:
if (!a != !b)
That's pretty obscure though and would certainly deserve a comment. Indeed, you could even use the bitwise XOR operator at this point, though this would be far too clever for my taste:
if (!a ^ !b)

Javascript has a bitwise XOR operator : ^
var nb = 5^9 // = 12
You can use it with booleans and it will give the result as a 0 or 1 (which you can convert back to boolean, e.g. result = !!(op1 ^ op2)). But as John said, it's equivalent to result = (op1 != op2), which is clearer.

There are no real logical boolean operators in Javascript (although ! comes quite close). A logical operator would only take true or false as operands and would only return true or false.
In Javascript && and || take all kinds of operands and return all kinds of funny results (whatever you feed into them).
Also a logical operator should always take the values of both operands into account.
In Javascript && and || take a lazy shortcut and do not evaluate the second operand in certain cases and thereby neglect its side effects. This behavior is impossible to recreate with a logical xor.
a() && b() evaluates a() and returns the result if it's falsy.
Otherwise it evaluates b() and returns the result. Therefore the returned result is truthy if both results are truthy, and falsy otherwise.
a() || b() evaluates a() and returns the result if it's truthy.
Otherwise it evaluates b() and returns the result. Therefore the returned result is falsy if both results are falsy, and truthy otherwise.
So the general idea is to evaluate the left operand first. The right operand only gets evaluated if necessary. And the last value is the result. This result can be anything. Objects, numbers, strings .. whatever!
This makes it possible to write things like
image = image || new Image(); // default to a new Image
or
src = image && image.src; // only read out src if we have an image
But the truth value of this result can also be used to decide if a "real" logical operator would have returned true or false.
This makes it possible to write things like
if (typeof image.hasAttribute === 'function' && image.hasAttribute('src')) {
or
if (image.hasAttribute('alt') || image.hasAttribute('title')) {
But a "logical" xor operator (^^) would always have to evaluate both operands. This makes it different to the other "logical" operators which evaluate the second operand only if necessary. I think this is why there is no "logical" xor in Javascript, to avoid confusion.
So what should happen if both operands are falsy? Both could be returned. But only one can be returned. Which one? The first one? Or the second one? My intuition tells me to return the first but usually "logical" operators evaluate from left to right and return the last evaluated value. Or maybe an array containing both values?
And if one operand is truthy and the other operand is falsy, an xor should return the truthy one. Or maybe an array containing the truthy one, to make it compatible with the previous case?
And finally, what should happen if both operands are truthy? You would expect something falsy. But there are no falsy results. So the operation shouldn't return anything. So maybe undefined or .. an empty array? But an empty array is still truthy.
Taking the array approach you would end up with conditions like if ((a ^^ b).length !== 1) {. Very confusing.

The XOR of two booleans is simply whether they are different, therefore:
Boolean(a) !== Boolean(b)

Convert values into Boolean form and then take bitwise XOR:
Boolean(a) ^ Boolean(b) // === 0 | 1
Note that the result of this expression is a number and not a Boolean.
Bitwise XOR also works with non-Boolean values, but remember that this is a bitwise operator, and not a logical one. Using non-bools may not go as you first expect:
(5 ^ 3) === 6 // true

Covert to boolean and then perform xor like -
!!a ^ !!b

there is... sort of:
if( foo ? !bar : bar ) {
...
}
or easier to read:
if( ( foo && !bar ) || ( !foo && bar ) ) {
...
}
why? dunno.
because javascript developers thought it would be unnecessary as it can be expressed by other, already implemented, logical operators.
you could as well just have gon with nand and thats it, you can impress every other possible logical operation from that.
i personally think it has historical reasons that drive from c-based syntax languages, where to my knowledge xor is not present or at least exremely uncommon.

Yes, Just do the following.
Assuming that you are dealing with booleans A and B, then A XOR B value can be calculated in JavaScript using the following
var xor1 = !(a === b);
The previous line is also equivalent to the following
var xor2 = (!a !== !b);
Personally, I prefer xor1 since I have to type less characters. I believe that xor1 is also faster too. It's just performing two calculations. xor2 is performing three calculations.
Visual Explanation ... Read the table bellow (where 0 stands for false and 1 stands for true) and compare the 3rd and 5th columns.
!(A === B):
| A | B | A XOR B | A === B | !(A === B) |
------------------------------------------
| 0 | 0 | 0 | 1 | 0 |
| 0 | 1 | 1 | 0 | 1 |
| 1 | 0 | 1 | 0 | 1 |
| 1 | 1 | 0 | 1 | 0 |
------------------------------------------
Enjoy.

Check out:
Logical XOR in JavaScript
You can mimic it something like this:
if( ( foo && !bar ) || ( !foo && bar ) ) {
...
}

How about transforming the result int to a bool with double negation? Not so pretty, but really compact.
var state1 = false,
state2 = true;
var A = state1 ^ state2; // will become 1
var B = !!(state1 ^ state2); // will become true
console.log(A);
console.log(B);

For posterity's sake, and because I found this to be a good exercise, you can leverage truthiness with the XOR operator quite easily to coerce. Like the chosen answer, it's probably a bit too clever.
const xor = (a, b) => !!(!!a ^ !!b)
console.log(undefined ^ {}) // Returns 0, bitwise can't be done here.
console.log(xor(undefined, {})) // Returns true, because {} is truthy and undefined is falsy
console.log(0 ^ 1) // Works naturally, returns 1
console.log(xor(0, 1)) // Also works, returns true
console.log(true ^ false) // Again, returns true
console.log(xor(true, false)) // And again, returns true...
And for fun, this should work in TypeScript, by forcing explicit any:
const xor = (a: any, b: any) => !!((!!a as any) ^ (!!b as any))

One liner for Boolean:
if (x ? !y : y) { do something cool }

In above xor function it will result SIMILAR result as logical xor does not exactly logical xor, means it will result "false for equal values" and "true for different values" with data type matching in consideration.
This xor function will work as actual xor or logical operator, means it will result true or false according to the passing values are truthy or falsy. Use according to your needs
function xor(x,y){return true==(!!x!==!!y);}
function xnor(x,y){return !xor(x,y);}

The reason there is no logical XOR (^^) is because unlike && and || it does not give any lazy-logic advantage. That is the state of both expressions on the right and left have to be evaluated.

In Typescript (The + changes to numeric value):
value : number = (+false ^ +true)
So:
value : boolean = (+false ^ +true) == 1

cond1 xor cond2 is equivalent to cond1 + cond 2 == 1:
Here's the proof :
let ops = [[false, false],[false, true], [true, false], [true, true]];
function xor(cond1, cond2){
return cond1 + cond2 == 1;
}
for(op of ops){
console.log(`${op[0]} xor ${op[1]} is ${xor(op[0], op[1])}`)
}

Most of the proposed methods here are hard to read and understand. Instead of writing some cryptic and magical comparisons or trying to comment them, just define a reusable function that is self-explanatory:
function either(a: boolean, b: boolean): boolean {
return (a !== b);
}
Or a more universal one:
function either(a: any, b: any): boolean {
return Boolean(a) !== Boolean(b);
}
Then you can use it like this:
assert(either(one, another), 'Either one or another, not both');

Here's an alternate solution that works with 2+ variables and provides count as bonus.
Here's a more general solution to simulate logical XOR for any truthy/falsey values, just as if you'd have the operator in standard IF statements:
const v1 = true;
const v2 = -1; // truthy (warning, as always)
const v3 = ""; // falsy
const v4 = 783; // truthy
const v5 = false;
if( ( !!v1 + !!v2 + !!v3 + !!v4 + !!v5 ) === 1 )
document.write( `[ ${v1} XOR ${v2} XOR "${v3}" XOR ${v4} XOR ${v5} ] is TRUE!` );
else
document.write( `[ ${v1} XOR ${v2} XOR "${v3}" XOR ${v4} XOR ${v5} ] is FALSE!` );
The reason I like this, is because it also answers "How many of these variables are truthy?", so I usually pre-store that result.
And for those who want strict boolean-TRUE xor check behaviour, just do:
if( ( ( v1===true ) + ( v2===true ) + ( v3===true ) + ( v4===true ) + ( v5===true ) ) === 1 )
// etc.
If you don't care about the count, or if you care about optimal performance: then just use the bitwise xor on values coerced to boolean, for the truthy/falsy solution:
if( !!v1 ^ !!v2 ^ !!v3 ^ !!v4 ^ !!v5 )
// etc.

Hey I found this solution, to make and XOR on JavaScript and TypeScript.
if( +!!a ^ +!!b )
{
//This happens only when a is true and b is false or a is false and b is true.
}
else
{
//This happens only when a is true and b is true or a is false and b is false
}

Try this short and easy to understand one
function xor(x,y){return true==(x!==y);}
function xnor(x,y){return !xor(x,y);}
This will work for any data type

Related

Execute query in portions and return values jQuery php [duplicate]

This question's answers are a community effort. Edit existing answers to improve this post. It is not currently accepting new answers or interactions.
I'm using JSLint to go through JavaScript, and it's returning many suggestions to replace == (two equals signs) with === (three equals signs) when doing things like comparing idSele_UNVEHtype.value.length == 0 inside of an if statement.
Is there a performance benefit to replacing == with ===?
Any performance improvement would be welcomed as many comparison operators exist.
If no type conversion takes place, would there be a performance gain over ==?

The strict equality operator (===) behaves identically to the abstract equality operator (==) except no type conversion is done, and the types must be the same to be considered equal.
Reference: Javascript Tutorial: Comparison Operators
The == operator will compare for equality after doing any necessary type conversions. The === operator will not do the conversion, so if two values are not the same type === will simply return false. Both are equally quick.
To quote Douglas Crockford's excellent JavaScript: The Good Parts,
JavaScript has two sets of equality operators: === and !==, and their evil twins == and !=. The good ones work the way you would expect. If the two operands are of the same type and have the same value, then === produces true and !== produces false. The evil twins do the right thing when the operands are of the same type, but if they are of different types, they attempt to coerce the values. the rules by which they do that are complicated and unmemorable. These are some of the interesting cases:
'' == '0' // false
0 == '' // true
0 == '0' // true
false == 'false' // false
false == '0' // true
false == undefined // false
false == null // false
null == undefined // true
' \t\r\n ' == 0 // true
The lack of transitivity is alarming. My advice is to never use the evil twins. Instead, always use === and !==. All of the comparisons just shown produce false with the === operator.
Update:
A good point was brought up by #Casebash in the comments and in #Phillipe Laybaert's answer concerning objects. For objects, == and === act consistently with one another (except in a special case).
var a = [1,2,3];
var b = [1,2,3];
var c = { x: 1, y: 2 };
var d = { x: 1, y: 2 };
var e = "text";
var f = "te" + "xt";
a == b // false
a === b // false
c == d // false
c === d // false
e == f // true
e === f // true
The special case is when you compare a primitive with an object that evaluates to the same primitive, due to its toString or valueOf method. For example, consider the comparison of a string primitive with a string object created using the String constructor.
"abc" == new String("abc") // true
"abc" === new String("abc") // false
Here the == operator is checking the values of the two objects and returning true, but the === is seeing that they're not the same type and returning false. Which one is correct? That really depends on what you're trying to compare. My advice is to bypass the question entirely and just don't use the String constructor to create string objects from string literals.
Reference
http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3

Using the == operator (Equality)
true == 1; //true, because 'true' is converted to 1 and then compared
"2" == 2; //true, because "2" is converted to 2 and then compared
Using the === operator (Identity)
true === 1; //false
"2" === 2; //false
This is because the equality operator == does type coercion, meaning that the interpreter implicitly tries to convert the values before comparing.
On the other hand, the identity operator === does not do type coercion, and thus does not convert the values when comparing.

Here's an interesting visualisation of the equality comparison between == and ===.
Source: https://github.com/dorey/JavaScript-Equality-Table (demo, unified demo)
var1 === var2
When using === for JavaScript equality testing, everything is as is.
Nothing gets converted before being evaluated.
var1 == var2
When using == for JavaScript equality testing, some funky conversions take place.
Summary of equality in Javascript
Conclusion:
Always use ===, unless you fully understand the funky conversions that take place with ==.

In the answers here, I didn't read anything about what equal means. Some will say that === means equal and of the same type, but that's not really true. It actually means that both operands reference the same object, or in case of value types, have the same value.
So, let's take the following code:
var a = [1,2,3];
var b = [1,2,3];
var c = a;
var ab_eq = (a === b); // false (even though a and b are the same type)
var ac_eq = (a === c); // true
The same here:
var a = { x: 1, y: 2 };
var b = { x: 1, y: 2 };
var c = a;
var ab_eq = (a === b); // false (even though a and b are the same type)
var ac_eq = (a === c); // true
Or even:
var a = { };
var b = { };
var c = a;
var ab_eq = (a === b); // false (even though a and b are the same type)
var ac_eq = (a === c); // true
This behavior is not always obvious. There's more to the story than being equal and being of the same type.
The rule is:
For value types (numbers):
a === b returns true if a and b have the same value and are of the same type
For reference types:
a === b returns true if a and b reference the exact same object
For strings:
a === b returns true if a and b are both strings and contain the exact same characters
Strings: the special case...
Strings are not value types, but in Javascript they behave like value types, so they will be "equal" when the characters in the string are the same and when they are of the same length (as explained in the third rule)
Now it becomes interesting:
var a = "12" + "3";
var b = "123";
alert(a === b); // returns true, because strings behave like value types
But how about this?:
var a = new String("123");
var b = "123";
alert(a === b); // returns false !! (but they are equal and of the same type)
I thought strings behave like value types? Well, it depends who you ask... In this case a and b are not the same type. a is of type Object, while b is of type string. Just remember that creating a string object using the String constructor creates something of type Object that behaves as a string most of the time.

Let me add this counsel:
If in doubt, read the specification!
ECMA-262 is the specification for a scripting language of which JavaScript is a dialect. Of course in practice it matters more how the most important browsers behave than an esoteric definition of how something is supposed to be handled. But it is helpful to understand why new String("a") !== "a".
Please let me explain how to read the specification to clarify this question. I see that in this very old topic nobody had an answer for the very strange effect. So, if you can read a specification, this will help you in your profession tremendously. It is an acquired skill. So, let's continue.
Searching the PDF file for === brings me to page 56 of the specification: 11.9.4. The Strict Equals Operator ( === ), and after wading through the specificationalese I find:
11.9.6 The Strict Equality Comparison Algorithm
The comparison x === y, where x and y are values, produces true or false. Such a comparison is performed as follows:
  1. If Type(x) is different from Type(y), return false.
  2. If Type(x) is Undefined, return true.
  3. If Type(x) is Null, return true.
  4. If Type(x) is not Number, go to step 11.
  5. If x is NaN, return false.
  6. If y is NaN, return false.
  7. If x is the same number value as y, return true.
  8. If x is +0 and y is −0, return true.
  9. If x is −0 and y is +0, return true.
  10. Return false.
  11. If Type(x) is String, then return true if x and y are exactly the same sequence of characters (same length and same characters in corresponding positions); otherwise, return false.
  12. If Type(x) is Boolean, return true if x and y are both true or both false; otherwise, return false.
  13. Return true if x and y refer to the same object or if they refer to objects joined to each other (see 13.1.2). Otherwise, return false.
Interesting is step 11. Yes, strings are treated as value types. But this does not explain why new String("a") !== "a". Do we have a browser not conforming to ECMA-262?
Not so fast!
Let's check the types of the operands. Try it out for yourself by wrapping them in typeof(). I find that new String("a") is an object, and step 1 is used: return false if the types are different.
If you wonder why new String("a") does not return a string, how about some exercise reading a specification? Have fun!
Aidiakapi wrote this in a comment below:
From the specification
11.2.2 The new Operator:
If Type(constructor) is not Object, throw a TypeError exception.
With other words, if String wouldn't be of type Object it couldn't be used with the new operator.
new always returns an Object, even for String constructors, too. And alas! The value semantics for strings (see step 11) is lost.
And this finally means: new String("a") !== "a".

I tested this in Firefox with Firebug using code like this:
console.time("testEquality");
var n = 0;
while (true) {
n++;
if (n == 100000)
break;
}
console.timeEnd("testEquality");
and
console.time("testTypeEquality");
var n = 0;
while (true) {
n++;
if (n === 100000)
break;
}
console.timeEnd("testTypeEquality");
My results (tested five times each and averaged):
==: 115.2
===: 114.4
So I'd say that the miniscule difference (this is over 100000 iterations, remember) is negligible. Performance isn't a reason to do ===. Type safety (well, as safe as you're going to get in JavaScript), and code quality is.

In PHP and JavaScript, it is a strict equality operator. Which means, it will compare both type and values.

In JavaScript it means of the same value and type.
For example,
4 == "4" // will return true
but
4 === "4" // will return false

Why == is so unpredictable?
What do you get when you compare an empty string "" with the number zero 0?
true
Yep, that's right according to == an empty string and the number zero are the same time.
And it doesn't end there, here's another one:
'0' == false // true
Things get really weird with arrays.
[1] == true // true
[] == false // true
[[]] == false // true
[0] == false // true
Then weirder with strings
[1,2,3] == '1,2,3' // true - REALLY?!
'\r\n\t' == 0 // true - Come on!
It get's worse:
When is equal not equal?
let A = '' // empty string
let B = 0 // zero
let C = '0' // zero string
A == B // true - ok...
B == C // true - so far so good...
A == C // **FALSE** - Plot twist!
Let me say that again:
(A == B) && (B == C) // true
(A == C) // **FALSE**
And this is just the crazy stuff you get with primitives.
It's a whole new level of crazy when you use == with objects.
At this point your probably wondering...
Why does this happen?
Well it's because unlike "triple equals" (===) which just checks if two values are the same.
== does a whole bunch of other stuff.
It has special handling for functions, special handling for nulls, undefined, strings, you name it.
It get's pretty wacky.
In fact, if you tried to write a function that does what == does it would look something like this:
function isEqual(x, y) { // if `==` were a function
if(typeof y === typeof x) return y === x;
// treat null and undefined the same
var xIsNothing = (y === undefined) || (y === null);
var yIsNothing = (x === undefined) || (x === null);
if(xIsNothing || yIsNothing) return (xIsNothing && yIsNothing);
if(typeof y === "function" || typeof x === "function") {
// if either value is a string
// convert the function into a string and compare
if(typeof x === "string") {
return x === y.toString();
} else if(typeof y === "string") {
return x.toString() === y;
}
return false;
}
if(typeof x === "object") x = toPrimitive(x);
if(typeof y === "object") y = toPrimitive(y);
if(typeof y === typeof x) return y === x;
// convert x and y into numbers if they are not already use the "+" trick
if(typeof x !== "number") x = +x;
if(typeof y !== "number") y = +y;
// actually the real `==` is even more complicated than this, especially in ES6
return x === y;
}
function toPrimitive(obj) {
var value = obj.valueOf();
if(obj !== value) return value;
return obj.toString();
}
So what does this mean?
It means == is complicated.
Because it's complicated it's hard to know what's going to happen when you use it.
Which means you could end up with bugs.
So the moral of the story is...
Make your life less complicated.
Use === instead of ==.
The End.

The === operator is called a strict comparison operator, it does differ from the == operator.
Lets take 2 vars a and b.
For "a == b" to evaluate to true a and b need to be the same value.
In the case of "a === b" a and b must be the same value and also the same type for it to evaluate to true.
Take the following example
var a = 1;
var b = "1";
if (a == b) //evaluates to true as a and b are both 1
{
alert("a == b");
}
if (a === b) //evaluates to false as a is not the same type as b
{
alert("a === b");
}
In summary; using the == operator might evaluate to true in situations where you do not want it to so using the === operator would be safer.
In the 90% usage scenario it won't matter which one you use, but it is handy to know the difference when you get some unexpected behaviour one day.

=== checks same sides are equal in type as well as value.
Example:
'1' === 1 // will return "false" because `string` is not a `number`
Common example:
0 == '' // will be "true", but it's very common to want this check to be "false"
Another common example:
null == undefined // returns "true", but in most cases a distinction is necessary
Many times an untyped check would be handy because you do not care if the value is either undefined, null, 0 or ""

Javascript execution flow diagram for strict equality / Comparison '==='
Javascript execution flow diagram for non strict equality / comparison '=='

JavaScript === vs == .
0==false // true
0===false // false, because they are of a different type
1=="1" // true, auto type coercion
1==="1" // false, because they are of a different type

It means equality without type coercion
type coercion means JavaScript do not automatically convert any other data types to string data types
0==false // true,although they are different types
0===false // false,as they are different types
2=='2' //true,different types,one is string and another is integer but
javaScript convert 2 to string by using == operator
2==='2' //false because by using === operator ,javaScript do not convert
integer to string
2===2 //true because both have same value and same types

In a typical script there will be no performance difference. More important may be the fact that thousand "===" is 1 KB heavier than thousand "==" :) JavaScript profilers can tell you if there is a performance difference in your case.
But personally I would do what JSLint suggests. This recommendation is there not because of performance issues, but because type coercion means ('\t\r\n' == 0) is true.

The equal comparison operator == is confusing and should be avoided.
If you HAVE TO live with it, then remember the following 3 things:
It is not transitive: (a == b) and (b == c) does not lead to (a == c)
It's mutually exclusive to its negation: (a == b) and (a != b) always hold opposite Boolean values, with all a and b.
In case of doubt, learn by heart the following truth table:
EQUAL OPERATOR TRUTH TABLE IN JAVASCRIPT
Each row in the table is a set of 3 mutually "equal" values, meaning that any 2 values among them are equal using the equal == sign*
** STRANGE: note that any two values on the first column are not equal in that sense.**
'' == 0 == false // Any two values among these 3 ones are equal with the == operator
'0' == 0 == false // Also a set of 3 equal values, note that only 0 and false are repeated
'\t' == 0 == false // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
'\r' == 0 == false // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
'\n' == 0 == false // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
'\t\r\n' == 0 == false // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
null == undefined // These two "default" values are not-equal to any of the listed values above
NaN // NaN is not equal to any thing, even to itself.

There is unlikely to be any performance difference between the two operations in your usage. There is no type-conversion to be done because both parameters are already the same type. Both operations will have a type comparison followed by a value comparison.

Simply
== means comparison between operands with type coercion
and
=== means comparison between operands without type coercion.
Type coercion in JavaScript means automatically converting data types to other data types.
For example:
123 == "123" // Returns true, because JS coerces string "123" to number 123
// and then goes on to compare `123 == 123`.
123 === "123" // Returns false, because JS does not coerce values of different types here.

Yes! It does matter.
=== operator in javascript checks value as well as type where as == operator just checks the value (does type conversion if required).
You can easily test it. Paste following code in an HTML file and open it in browser
<script>
function onPageLoad()
{
var x = "5";
var y = 5;
alert(x === 5);
};
</script>
</head>
<body onload='onPageLoad();'>
You will get 'false' in alert. Now modify the onPageLoad() method to alert(x == 5); you will get true.

As a rule of thumb, I would generally use === instead of == (and !== instead of !=).
Reasons are explained in in the answers above and also Douglas Crockford is pretty clear about it (JavaScript: The Good Parts).
However there is one single exception:
== null is an efficient way to check for 'is null or undefined':
if( value == null ){
// value is either null or undefined
}
For example jQuery 1.9.1 uses this pattern 43 times, and the JSHint syntax checker even provides the eqnull relaxing option for this reason.
From the jQuery style guide:
Strict equality checks (===) should be used in favor of ==. The only
exception is when checking for undefined and null by way of null.
// Check for both undefined and null values, for some important reason.
undefOrNull == null;
EDIT 2021-03:
Nowadays most browsers
support the Nullish coalescing operator (??)
and the Logical nullish assignment (??=), which allows a more concise way to
assign a default value if a variable is null or undefined, for example:
if (a.speed == null) {
// Set default if null or undefined
a.speed = 42;
}
can be written as any of these forms
a.speed ??= 42;
a.speed ?? a.speed = 42;
a.speed = a.speed ?? 42;

It's a strict check test.
It's a good thing especially if you're checking between 0 and false and null.
For example, if you have:
$a = 0;
Then:
$a==0;
$a==NULL;
$a==false;
All returns true and you may not want this. Let's suppose you have a function that can return the 0th index of an array or false on failure. If you check with "==" false, you can get a confusing result.
So with the same thing as above, but a strict test:
$a = 0;
$a===0; // returns true
$a===NULL; // returns false
$a===false; // returns false

=== operator checks the values as well as the types of the variables for equality.
== operator just checks the value of the variables for equality.

JSLint sometimes gives you unrealistic reasons to modify stuff. === has exactly the same performance as == if the types are already the same.
It is faster only when the types are not the same, in which case it does not try to convert types but directly returns a false.
So, IMHO, JSLint maybe used to write new code, but useless over-optimizing should be avoided at all costs.
Meaning, there is no reason to change == to === in a check like if (a == 'test') when you know it for a fact that a can only be a String.
Modifying a lot of code that way wastes developers' and reviewers' time and achieves nothing.

A simple example is
2 == '2' -> true, values are SAME because of type conversion.
2 === '2' -> false, values are NOT SAME because of no type conversion.

The top 2 answers both mentioned == means equality and === means identity. Unfortunately, this statement is incorrect.
If both operands of == are objects, then they are compared to see if they are the same object. If both operands point to the same object, then the equal operator returns true. Otherwise,
the two are not equal.
var a = [1, 2, 3];
var b = [1, 2, 3];
console.log(a == b) // false
console.log(a === b) // false
In the code above, both == and === get false because a and b are not the same objects.
That's to say: if both operands of == are objects, == behaves same as ===, which also means identity. The essential difference of this two operators is about type conversion. == has conversion before it checks equality, but === does not.

The problem is that you might easily get into trouble since JavaScript have a lot of implicit conversions meaning...
var x = 0;
var isTrue = x == null;
var isFalse = x === null;
Which pretty soon becomes a problem. The best sample of why implicit conversion is "evil" can be taken from this code in MFC / C++ which actually will compile due to an implicit conversion from CString to HANDLE which is a pointer typedef type...
CString x;
delete x;
Which obviously during runtime does very undefined things...
Google for implicit conversions in C++ and STL to get some of the arguments against it...

From the core javascript reference
=== Returns true if the operands are strictly equal (see above)
with no type conversion.

Equality comparison:
Operator ==
Returns true, when both operands are equal. The operands are converted to the same type before being compared.
>>> 1 == 1
true
>>> 1 == 2
false
>>> 1 == '1'
true
Equality and type comparison:
Operator ===
Returns true if both operands are equal and of the same type. It's generally
better and safer if you compare this way, because there's no behind-the-scenes type conversions.
>>> 1 === '1'
false
>>> 1 === 1
true

Here is a handy comparison table that shows the conversions that happen and the differences between == and ===.
As the conclusion states:
"Use three equals unless you fully understand the conversions that take
place for two-equals."
http://dorey.github.io/JavaScript-Equality-Table/

null and undefined are nothingness, that is,
var a;
var b = null;
Here a and b do not have values. Whereas, 0, false and '' are all values. One thing common beween all these are that they are all falsy values, which means they all satisfy falsy conditions.
So, the 0, false and '' together form a sub-group. And on other hand, null & undefined form the second sub-group. Check the comparisons in the below image. null and undefined would equal. The other three would equal to each other. But, they all are treated as falsy conditions in JavaScript.
This is same as any object (like {}, arrays, etc.), non-empty string & Boolean true are all truthy conditions. But, they are all not equal.

Javascript == and === comparison [duplicate]

This question's answers are a community effort. Edit existing answers to improve this post. It is not currently accepting new answers or interactions.
I'm using JSLint to go through JavaScript, and it's returning many suggestions to replace == (two equals signs) with === (three equals signs) when doing things like comparing idSele_UNVEHtype.value.length == 0 inside of an if statement.
Is there a performance benefit to replacing == with ===?
Any performance improvement would be welcomed as many comparison operators exist.
If no type conversion takes place, would there be a performance gain over ==?

The strict equality operator (===) behaves identically to the abstract equality operator (==) except no type conversion is done, and the types must be the same to be considered equal.
Reference: JavaScript Tutorial: Comparison Operators
The == operator will compare for equality after doing any necessary type conversions. The === operator will not do the conversion, so if two values are not the same type === will simply return false. Both are equally quick.
To quote Douglas Crockford's excellent JavaScript: The Good Parts,
JavaScript has two sets of equality operators: === and !==, and their evil twins == and !=. The good ones work the way you would expect. If the two operands are of the same type and have the same value, then === produces true and !== produces false. The evil twins do the right thing when the operands are of the same type, but if they are of different types, they attempt to coerce the values. The rules by which they do that are complicated and unmemorable. These are some of the interesting cases:
'' == '0' // false
0 == '' // true
0 == '0' // true
false == 'false' // false
false == '0' // true
false == undefined // false
false == null // false
null == undefined // true
' \t\r\n ' == 0 // true
The lack of transitivity is alarming. My advice is to never use the evil twins. Instead, always use === and !==. All of the comparisons just shown produce false with the === operator.
Update
A good point was brought up by #Casebash in the comments and in #Phillipe Laybaert's answer concerning objects. For objects, == and === act consistently with one another (except in a special case).
var a = [1,2,3];
var b = [1,2,3];
var c = { x: 1, y: 2 };
var d = { x: 1, y: 2 };
var e = "text";
var f = "te" + "xt";
a == b // false
a === b // false
c == d // false
c === d // false
e == f // true
e === f // true
The special case is when you compare a primitive with an object that evaluates to the same primitive, due to its toString or valueOf method. For example, consider the comparison of a string primitive with a string object created using the String constructor.
"abc" == new String("abc") // true
"abc" === new String("abc") // false
Here the == operator is checking the values of the two objects and returning true, but the === is seeing that they're not the same type and returning false. Which one is correct? That really depends on what you're trying to compare. My advice is to bypass the question entirely and just don't use the String constructor to create string objects from string literals.
Reference
https://262.ecma-international.org/5.1/#sec-11.9.3

Using the == operator (Equality)
true == 1; //true, because 'true' is converted to 1 and then compared
"2" == 2; //true, because "2" is converted to 2 and then compared
Using the === operator (Identity)
true === 1; //false
"2" === 2; //false
This is because the equality operator == does type coercion, meaning that the interpreter implicitly tries to convert the values before comparing.
On the other hand, the identity operator === does not do type coercion, and thus does not convert the values when comparing.

Here's an interesting visualisation of the equality comparison between == and ===.
Source: https://github.com/dorey/JavaScript-Equality-Table (demo, unified demo)
var1 === var2
When using === for JavaScript equality testing, everything is as is.
Nothing gets converted before being evaluated.
var1 == var2
When using == for JavaScript equality testing, some funky conversions take place.
Summary of equality in Javascript
Conclusion:
Always use ===, unless you fully understand the funky conversions that take place with ==.

In the answers here, I didn't read anything about what equal means. Some will say that === means equal and of the same type, but that's not really true. It actually means that both operands reference the same object, or in case of value types, have the same value.
So, let's take the following code:
var a = [1,2,3];
var b = [1,2,3];
var c = a;
var ab_eq = (a === b); // false (even though a and b are the same type)
var ac_eq = (a === c); // true
The same here:
var a = { x: 1, y: 2 };
var b = { x: 1, y: 2 };
var c = a;
var ab_eq = (a === b); // false (even though a and b are the same type)
var ac_eq = (a === c); // true
Or even:
var a = { };
var b = { };
var c = a;
var ab_eq = (a === b); // false (even though a and b are the same type)
var ac_eq = (a === c); // true
This behavior is not always obvious. There's more to the story than being equal and being of the same type.
The rule is:
For value types (numbers):
a === b returns true if a and b have the same value and are of the same type
For reference types:
a === b returns true if a and b reference the exact same object
For strings:
a === b returns true if a and b are both strings and contain the exact same characters
Strings: the special case...
Strings are not value types, but in Javascript they behave like value types, so they will be "equal" when the characters in the string are the same and when they are of the same length (as explained in the third rule)
Now it becomes interesting:
var a = "12" + "3";
var b = "123";
alert(a === b); // returns true, because strings behave like value types
But how about this?:
var a = new String("123");
var b = "123";
alert(a === b); // returns false !! (but they are equal and of the same type)
I thought strings behave like value types? Well, it depends who you ask... In this case a and b are not the same type. a is of type Object, while b is of type string. Just remember that creating a string object using the String constructor creates something of type Object that behaves as a string most of the time.

Let me add this counsel:
If in doubt, read the specification!
ECMA-262 is the specification for a scripting language of which JavaScript is a dialect. Of course in practice it matters more how the most important browsers behave than an esoteric definition of how something is supposed to be handled. But it is helpful to understand why new String("a") !== "a".
Please let me explain how to read the specification to clarify this question. I see that in this very old topic nobody had an answer for the very strange effect. So, if you can read a specification, this will help you in your profession tremendously. It is an acquired skill. So, let's continue.
Searching the PDF file for === brings me to page 56 of the specification: 11.9.4. The Strict Equals Operator ( === ), and after wading through the specificationalese I find:
11.9.6 The Strict Equality Comparison Algorithm
The comparison x === y, where x and y are values, produces true or false. Such a comparison is performed as follows:
  1. If Type(x) is different from Type(y), return false.
  2. If Type(x) is Undefined, return true.
  3. If Type(x) is Null, return true.
  4. If Type(x) is not Number, go to step 11.
  5. If x is NaN, return false.
  6. If y is NaN, return false.
  7. If x is the same number value as y, return true.
  8. If x is +0 and y is −0, return true.
  9. If x is −0 and y is +0, return true.
  10. Return false.
  11. If Type(x) is String, then return true if x and y are exactly the same sequence of characters (same length and same characters in corresponding positions); otherwise, return false.
  12. If Type(x) is Boolean, return true if x and y are both true or both false; otherwise, return false.
  13. Return true if x and y refer to the same object or if they refer to objects joined to each other (see 13.1.2). Otherwise, return false.
Interesting is step 11. Yes, strings are treated as value types. But this does not explain why new String("a") !== "a". Do we have a browser not conforming to ECMA-262?
Not so fast!
Let's check the types of the operands. Try it out for yourself by wrapping them in typeof(). I find that new String("a") is an object, and step 1 is used: return false if the types are different.
If you wonder why new String("a") does not return a string, how about some exercise reading a specification? Have fun!
Aidiakapi wrote this in a comment below:
From the specification
11.2.2 The new Operator:
If Type(constructor) is not Object, throw a TypeError exception.
With other words, if String wouldn't be of type Object it couldn't be used with the new operator.
new always returns an Object, even for String constructors, too. And alas! The value semantics for strings (see step 11) is lost.
And this finally means: new String("a") !== "a".

I tested this in Firefox with Firebug using code like this:
console.time("testEquality");
var n = 0;
while (true) {
n++;
if (n == 100000)
break;
}
console.timeEnd("testEquality");
and
console.time("testTypeEquality");
var n = 0;
while (true) {
n++;
if (n === 100000)
break;
}
console.timeEnd("testTypeEquality");
My results (tested five times each and averaged):
==: 115.2
===: 114.4
So I'd say that the miniscule difference (this is over 100000 iterations, remember) is negligible. Performance isn't a reason to do ===. Type safety (well, as safe as you're going to get in JavaScript), and code quality is.

In PHP and JavaScript, it is a strict equality operator. Which means, it will compare both type and values.

In JavaScript it means of the same value and type.
For example,
4 == "4" // will return true
but
4 === "4" // will return false

Why == is so unpredictable?
What do you get when you compare an empty string "" with the number zero 0?
true
Yep, that's right according to == an empty string and the number zero are the same time.
And it doesn't end there, here's another one:
'0' == false // true
Things get really weird with arrays.
[1] == true // true
[] == false // true
[[]] == false // true
[0] == false // true
Then weirder with strings
[1,2,3] == '1,2,3' // true - REALLY?!
'\r\n\t' == 0 // true - Come on!
It get's worse:
When is equal not equal?
let A = '' // empty string
let B = 0 // zero
let C = '0' // zero string
A == B // true - ok...
B == C // true - so far so good...
A == C // **FALSE** - Plot twist!
Let me say that again:
(A == B) && (B == C) // true
(A == C) // **FALSE**
And this is just the crazy stuff you get with primitives.
It's a whole new level of crazy when you use == with objects.
At this point your probably wondering...
Why does this happen?
Well it's because unlike "triple equals" (===) which just checks if two values are the same.
== does a whole bunch of other stuff.
It has special handling for functions, special handling for nulls, undefined, strings, you name it.
It get's pretty wacky.
In fact, if you tried to write a function that does what == does it would look something like this:
function isEqual(x, y) { // if `==` were a function
if(typeof y === typeof x) return y === x;
// treat null and undefined the same
var xIsNothing = (y === undefined) || (y === null);
var yIsNothing = (x === undefined) || (x === null);
if(xIsNothing || yIsNothing) return (xIsNothing && yIsNothing);
if(typeof y === "function" || typeof x === "function") {
// if either value is a string
// convert the function into a string and compare
if(typeof x === "string") {
return x === y.toString();
} else if(typeof y === "string") {
return x.toString() === y;
}
return false;
}
if(typeof x === "object") x = toPrimitive(x);
if(typeof y === "object") y = toPrimitive(y);
if(typeof y === typeof x) return y === x;
// convert x and y into numbers if they are not already use the "+" trick
if(typeof x !== "number") x = +x;
if(typeof y !== "number") y = +y;
// actually the real `==` is even more complicated than this, especially in ES6
return x === y;
}
function toPrimitive(obj) {
var value = obj.valueOf();
if(obj !== value) return value;
return obj.toString();
}
So what does this mean?
It means == is complicated.
Because it's complicated it's hard to know what's going to happen when you use it.
Which means you could end up with bugs.
So the moral of the story is...
Make your life less complicated.
Use === instead of ==.
The End.

The === operator is called a strict comparison operator, it does differ from the == operator.
Lets take 2 vars a and b.
For "a == b" to evaluate to true a and b need to be the same value.
In the case of "a === b" a and b must be the same value and also the same type for it to evaluate to true.
Take the following example
var a = 1;
var b = "1";
if (a == b) //evaluates to true as a and b are both 1
{
alert("a == b");
}
if (a === b) //evaluates to false as a is not the same type as b
{
alert("a === b");
}
In summary; using the == operator might evaluate to true in situations where you do not want it to so using the === operator would be safer.
In the 90% usage scenario it won't matter which one you use, but it is handy to know the difference when you get some unexpected behaviour one day.

=== checks same sides are equal in type as well as value.
Example:
'1' === 1 // will return "false" because `string` is not a `number`
Common example:
0 == '' // will be "true", but it's very common to want this check to be "false"
Another common example:
null == undefined // returns "true", but in most cases a distinction is necessary
Many times an untyped check would be handy because you do not care if the value is either undefined, null, 0 or ""

Javascript execution flow diagram for strict equality / Comparison '==='
Javascript execution flow diagram for non strict equality / comparison '=='

JavaScript === vs == .
0==false // true
0===false // false, because they are of a different type
1=="1" // true, auto type coercion
1==="1" // false, because they are of a different type

It means equality without type coercion
type coercion means JavaScript do not automatically convert any other data types to string data types
0==false // true,although they are different types
0===false // false,as they are different types
2=='2' //true,different types,one is string and another is integer but
javaScript convert 2 to string by using == operator
2==='2' //false because by using === operator ,javaScript do not convert
integer to string
2===2 //true because both have same value and same types

In a typical script there will be no performance difference. More important may be the fact that thousand "===" is 1 KB heavier than thousand "==" :) JavaScript profilers can tell you if there is a performance difference in your case.
But personally I would do what JSLint suggests. This recommendation is there not because of performance issues, but because type coercion means ('\t\r\n' == 0) is true.

The equal comparison operator == is confusing and should be avoided.
If you HAVE TO live with it, then remember the following 3 things:
It is not transitive: (a == b) and (b == c) does not lead to (a == c)
It's mutually exclusive to its negation: (a == b) and (a != b) always hold opposite Boolean values, with all a and b.
In case of doubt, learn by heart the following truth table:
EQUAL OPERATOR TRUTH TABLE IN JAVASCRIPT
Each row in the table is a set of 3 mutually "equal" values, meaning that any 2 values among them are equal using the equal == sign*
** STRANGE: note that any two values on the first column are not equal in that sense.**
'' == 0 == false // Any two values among these 3 ones are equal with the == operator
'0' == 0 == false // Also a set of 3 equal values, note that only 0 and false are repeated
'\t' == 0 == false // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
'\r' == 0 == false // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
'\n' == 0 == false // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
'\t\r\n' == 0 == false // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
null == undefined // These two "default" values are not-equal to any of the listed values above
NaN // NaN is not equal to any thing, even to itself.

There is unlikely to be any performance difference between the two operations in your usage. There is no type-conversion to be done because both parameters are already the same type. Both operations will have a type comparison followed by a value comparison.

Simply
== means comparison between operands with type coercion
and
=== means comparison between operands without type coercion.
Type coercion in JavaScript means automatically converting data types to other data types.
For example:
123 == "123" // Returns true, because JS coerces string "123" to number 123
// and then goes on to compare `123 == 123`.
123 === "123" // Returns false, because JS does not coerce values of different types here.

Yes! It does matter.
=== operator in javascript checks value as well as type where as == operator just checks the value (does type conversion if required).
You can easily test it. Paste following code in an HTML file and open it in browser
<script>
function onPageLoad()
{
var x = "5";
var y = 5;
alert(x === 5);
};
</script>
</head>
<body onload='onPageLoad();'>
You will get 'false' in alert. Now modify the onPageLoad() method to alert(x == 5); you will get true.

As a rule of thumb, I would generally use === instead of == (and !== instead of !=).
Reasons are explained in in the answers above and also Douglas Crockford is pretty clear about it (JavaScript: The Good Parts).
However there is one single exception:
== null is an efficient way to check for 'is null or undefined':
if( value == null ){
// value is either null or undefined
}
For example jQuery 1.9.1 uses this pattern 43 times, and the JSHint syntax checker even provides the eqnull relaxing option for this reason.
From the jQuery style guide:
Strict equality checks (===) should be used in favor of ==. The only
exception is when checking for undefined and null by way of null.
// Check for both undefined and null values, for some important reason.
undefOrNull == null;
EDIT 2021-03:
Nowadays most browsers
support the Nullish coalescing operator (??)
and the Logical nullish assignment (??=), which allows a more concise way to
assign a default value if a variable is null or undefined, for example:
if (a.speed == null) {
// Set default if null or undefined
a.speed = 42;
}
can be written as any of these forms
a.speed ??= 42;
a.speed ?? a.speed = 42;
a.speed = a.speed ?? 42;

It's a strict check test.
It's a good thing especially if you're checking between 0 and false and null.
For example, if you have:
$a = 0;
Then:
$a==0;
$a==NULL;
$a==false;
All returns true and you may not want this. Let's suppose you have a function that can return the 0th index of an array or false on failure. If you check with "==" false, you can get a confusing result.
So with the same thing as above, but a strict test:
$a = 0;
$a===0; // returns true
$a===NULL; // returns false
$a===false; // returns false

=== operator checks the values as well as the types of the variables for equality.
== operator just checks the value of the variables for equality.

JSLint sometimes gives you unrealistic reasons to modify stuff. === has exactly the same performance as == if the types are already the same.
It is faster only when the types are not the same, in which case it does not try to convert types but directly returns a false.
So, IMHO, JSLint maybe used to write new code, but useless over-optimizing should be avoided at all costs.
Meaning, there is no reason to change == to === in a check like if (a == 'test') when you know it for a fact that a can only be a String.
Modifying a lot of code that way wastes developers' and reviewers' time and achieves nothing.

A simple example is
2 == '2' -> true, values are SAME because of type conversion.
2 === '2' -> false, values are NOT SAME because of no type conversion.

The top 2 answers both mentioned == means equality and === means identity. Unfortunately, this statement is incorrect.
If both operands of == are objects, then they are compared to see if they are the same object. If both operands point to the same object, then the equal operator returns true. Otherwise,
the two are not equal.
var a = [1, 2, 3];
var b = [1, 2, 3];
console.log(a == b) // false
console.log(a === b) // false
In the code above, both == and === get false because a and b are not the same objects.
That's to say: if both operands of == are objects, == behaves same as ===, which also means identity. The essential difference of this two operators is about type conversion. == has conversion before it checks equality, but === does not.

The problem is that you might easily get into trouble since JavaScript have a lot of implicit conversions meaning...
var x = 0;
var isTrue = x == null;
var isFalse = x === null;
Which pretty soon becomes a problem. The best sample of why implicit conversion is "evil" can be taken from this code in MFC / C++ which actually will compile due to an implicit conversion from CString to HANDLE which is a pointer typedef type...
CString x;
delete x;
Which obviously during runtime does very undefined things...
Google for implicit conversions in C++ and STL to get some of the arguments against it...

From the core javascript reference
=== Returns true if the operands are strictly equal (see above)
with no type conversion.

Equality comparison:
Operator ==
Returns true, when both operands are equal. The operands are converted to the same type before being compared.
>>> 1 == 1
true
>>> 1 == 2
false
>>> 1 == '1'
true
Equality and type comparison:
Operator ===
Returns true if both operands are equal and of the same type. It's generally
better and safer if you compare this way, because there's no behind-the-scenes type conversions.
>>> 1 === '1'
false
>>> 1 === 1
true

Here is a handy comparison table that shows the conversions that happen and the differences between == and ===.
As the conclusion states:
"Use three equals unless you fully understand the conversions that take
place for two-equals."
http://dorey.github.io/JavaScript-Equality-Table/

null and undefined are nothingness, that is,
var a;
var b = null;
Here a and b do not have values. Whereas, 0, false and '' are all values. One thing common beween all these are that they are all falsy values, which means they all satisfy falsy conditions.
So, the 0, false and '' together form a sub-group. And on other hand, null & undefined form the second sub-group. Check the comparisons in the below image. null and undefined would equal. The other three would equal to each other. But, they all are treated as falsy conditions in JavaScript.
This is same as any object (like {}, arrays, etc.), non-empty string & Boolean true are all truthy conditions. But, they are all not equal.

When to use equality ("==") instead of identity ("===")? [duplicate]

This question's answers are a community effort. Edit existing answers to improve this post. It is not currently accepting new answers or interactions.
I'm using JSLint to go through JavaScript, and it's returning many suggestions to replace == (two equals signs) with === (three equals signs) when doing things like comparing idSele_UNVEHtype.value.length == 0 inside of an if statement.
Is there a performance benefit to replacing == with ===?
Any performance improvement would be welcomed as many comparison operators exist.
If no type conversion takes place, would there be a performance gain over ==?

The strict equality operator (===) behaves identically to the abstract equality operator (==) except no type conversion is done, and the types must be the same to be considered equal.
Reference: JavaScript Tutorial: Comparison Operators
The == operator will compare for equality after doing any necessary type conversions. The === operator will not do the conversion, so if two values are not the same type === will simply return false. Both are equally quick.
To quote Douglas Crockford's excellent JavaScript: The Good Parts,
JavaScript has two sets of equality operators: === and !==, and their evil twins == and !=. The good ones work the way you would expect. If the two operands are of the same type and have the same value, then === produces true and !== produces false. The evil twins do the right thing when the operands are of the same type, but if they are of different types, they attempt to coerce the values. The rules by which they do that are complicated and unmemorable. These are some of the interesting cases:
'' == '0' // false
0 == '' // true
0 == '0' // true
false == 'false' // false
false == '0' // true
false == undefined // false
false == null // false
null == undefined // true
' \t\r\n ' == 0 // true
The lack of transitivity is alarming. My advice is to never use the evil twins. Instead, always use === and !==. All of the comparisons just shown produce false with the === operator.
Update
A good point was brought up by #Casebash in the comments and in #Phillipe Laybaert's answer concerning objects. For objects, == and === act consistently with one another (except in a special case).
var a = [1,2,3];
var b = [1,2,3];
var c = { x: 1, y: 2 };
var d = { x: 1, y: 2 };
var e = "text";
var f = "te" + "xt";
a == b // false
a === b // false
c == d // false
c === d // false
e == f // true
e === f // true
The special case is when you compare a primitive with an object that evaluates to the same primitive, due to its toString or valueOf method. For example, consider the comparison of a string primitive with a string object created using the String constructor.
"abc" == new String("abc") // true
"abc" === new String("abc") // false
Here the == operator is checking the values of the two objects and returning true, but the === is seeing that they're not the same type and returning false. Which one is correct? That really depends on what you're trying to compare. My advice is to bypass the question entirely and just don't use the String constructor to create string objects from string literals.
Reference
https://262.ecma-international.org/5.1/#sec-11.9.3

Using the == operator (Equality)
true == 1; //true, because 'true' is converted to 1 and then compared
"2" == 2; //true, because "2" is converted to 2 and then compared
Using the === operator (Identity)
true === 1; //false
"2" === 2; //false
This is because the equality operator == does type coercion, meaning that the interpreter implicitly tries to convert the values before comparing.
On the other hand, the identity operator === does not do type coercion, and thus does not convert the values when comparing.

Here's an interesting visualisation of the equality comparison between == and ===.
Source: https://github.com/dorey/JavaScript-Equality-Table (demo, unified demo)
var1 === var2
When using === for JavaScript equality testing, everything is as is.
Nothing gets converted before being evaluated.
var1 == var2
When using == for JavaScript equality testing, some funky conversions take place.
Summary of equality in Javascript
Conclusion:
Always use ===, unless you fully understand the funky conversions that take place with ==.

In the answers here, I didn't read anything about what equal means. Some will say that === means equal and of the same type, but that's not really true. It actually means that both operands reference the same object, or in case of value types, have the same value.
So, let's take the following code:
var a = [1,2,3];
var b = [1,2,3];
var c = a;
var ab_eq = (a === b); // false (even though a and b are the same type)
var ac_eq = (a === c); // true
The same here:
var a = { x: 1, y: 2 };
var b = { x: 1, y: 2 };
var c = a;
var ab_eq = (a === b); // false (even though a and b are the same type)
var ac_eq = (a === c); // true
Or even:
var a = { };
var b = { };
var c = a;
var ab_eq = (a === b); // false (even though a and b are the same type)
var ac_eq = (a === c); // true
This behavior is not always obvious. There's more to the story than being equal and being of the same type.
The rule is:
For value types (numbers):
a === b returns true if a and b have the same value and are of the same type
For reference types:
a === b returns true if a and b reference the exact same object
For strings:
a === b returns true if a and b are both strings and contain the exact same characters
Strings: the special case...
Strings are not value types, but in Javascript they behave like value types, so they will be "equal" when the characters in the string are the same and when they are of the same length (as explained in the third rule)
Now it becomes interesting:
var a = "12" + "3";
var b = "123";
alert(a === b); // returns true, because strings behave like value types
But how about this?:
var a = new String("123");
var b = "123";
alert(a === b); // returns false !! (but they are equal and of the same type)
I thought strings behave like value types? Well, it depends who you ask... In this case a and b are not the same type. a is of type Object, while b is of type string. Just remember that creating a string object using the String constructor creates something of type Object that behaves as a string most of the time.

Let me add this counsel:
If in doubt, read the specification!
ECMA-262 is the specification for a scripting language of which JavaScript is a dialect. Of course in practice it matters more how the most important browsers behave than an esoteric definition of how something is supposed to be handled. But it is helpful to understand why new String("a") !== "a".
Please let me explain how to read the specification to clarify this question. I see that in this very old topic nobody had an answer for the very strange effect. So, if you can read a specification, this will help you in your profession tremendously. It is an acquired skill. So, let's continue.
Searching the PDF file for === brings me to page 56 of the specification: 11.9.4. The Strict Equals Operator ( === ), and after wading through the specificationalese I find:
11.9.6 The Strict Equality Comparison Algorithm
The comparison x === y, where x and y are values, produces true or false. Such a comparison is performed as follows:
  1. If Type(x) is different from Type(y), return false.
  2. If Type(x) is Undefined, return true.
  3. If Type(x) is Null, return true.
  4. If Type(x) is not Number, go to step 11.
  5. If x is NaN, return false.
  6. If y is NaN, return false.
  7. If x is the same number value as y, return true.
  8. If x is +0 and y is −0, return true.
  9. If x is −0 and y is +0, return true.
  10. Return false.
  11. If Type(x) is String, then return true if x and y are exactly the same sequence of characters (same length and same characters in corresponding positions); otherwise, return false.
  12. If Type(x) is Boolean, return true if x and y are both true or both false; otherwise, return false.
  13. Return true if x and y refer to the same object or if they refer to objects joined to each other (see 13.1.2). Otherwise, return false.
Interesting is step 11. Yes, strings are treated as value types. But this does not explain why new String("a") !== "a". Do we have a browser not conforming to ECMA-262?
Not so fast!
Let's check the types of the operands. Try it out for yourself by wrapping them in typeof(). I find that new String("a") is an object, and step 1 is used: return false if the types are different.
If you wonder why new String("a") does not return a string, how about some exercise reading a specification? Have fun!
Aidiakapi wrote this in a comment below:
From the specification
11.2.2 The new Operator:
If Type(constructor) is not Object, throw a TypeError exception.
With other words, if String wouldn't be of type Object it couldn't be used with the new operator.
new always returns an Object, even for String constructors, too. And alas! The value semantics for strings (see step 11) is lost.
And this finally means: new String("a") !== "a".

I tested this in Firefox with Firebug using code like this:
console.time("testEquality");
var n = 0;
while (true) {
n++;
if (n == 100000)
break;
}
console.timeEnd("testEquality");
and
console.time("testTypeEquality");
var n = 0;
while (true) {
n++;
if (n === 100000)
break;
}
console.timeEnd("testTypeEquality");
My results (tested five times each and averaged):
==: 115.2
===: 114.4
So I'd say that the miniscule difference (this is over 100000 iterations, remember) is negligible. Performance isn't a reason to do ===. Type safety (well, as safe as you're going to get in JavaScript), and code quality is.

In PHP and JavaScript, it is a strict equality operator. Which means, it will compare both type and values.

In JavaScript it means of the same value and type.
For example,
4 == "4" // will return true
but
4 === "4" // will return false

Why == is so unpredictable?
What do you get when you compare an empty string "" with the number zero 0?
true
Yep, that's right according to == an empty string and the number zero are the same time.
And it doesn't end there, here's another one:
'0' == false // true
Things get really weird with arrays.
[1] == true // true
[] == false // true
[[]] == false // true
[0] == false // true
Then weirder with strings
[1,2,3] == '1,2,3' // true - REALLY?!
'\r\n\t' == 0 // true - Come on!
It get's worse:
When is equal not equal?
let A = '' // empty string
let B = 0 // zero
let C = '0' // zero string
A == B // true - ok...
B == C // true - so far so good...
A == C // **FALSE** - Plot twist!
Let me say that again:
(A == B) && (B == C) // true
(A == C) // **FALSE**
And this is just the crazy stuff you get with primitives.
It's a whole new level of crazy when you use == with objects.
At this point your probably wondering...
Why does this happen?
Well it's because unlike "triple equals" (===) which just checks if two values are the same.
== does a whole bunch of other stuff.
It has special handling for functions, special handling for nulls, undefined, strings, you name it.
It get's pretty wacky.
In fact, if you tried to write a function that does what == does it would look something like this:
function isEqual(x, y) { // if `==` were a function
if(typeof y === typeof x) return y === x;
// treat null and undefined the same
var xIsNothing = (y === undefined) || (y === null);
var yIsNothing = (x === undefined) || (x === null);
if(xIsNothing || yIsNothing) return (xIsNothing && yIsNothing);
if(typeof y === "function" || typeof x === "function") {
// if either value is a string
// convert the function into a string and compare
if(typeof x === "string") {
return x === y.toString();
} else if(typeof y === "string") {
return x.toString() === y;
}
return false;
}
if(typeof x === "object") x = toPrimitive(x);
if(typeof y === "object") y = toPrimitive(y);
if(typeof y === typeof x) return y === x;
// convert x and y into numbers if they are not already use the "+" trick
if(typeof x !== "number") x = +x;
if(typeof y !== "number") y = +y;
// actually the real `==` is even more complicated than this, especially in ES6
return x === y;
}
function toPrimitive(obj) {
var value = obj.valueOf();
if(obj !== value) return value;
return obj.toString();
}
So what does this mean?
It means == is complicated.
Because it's complicated it's hard to know what's going to happen when you use it.
Which means you could end up with bugs.
So the moral of the story is...
Make your life less complicated.
Use === instead of ==.
The End.

The === operator is called a strict comparison operator, it does differ from the == operator.
Lets take 2 vars a and b.
For "a == b" to evaluate to true a and b need to be the same value.
In the case of "a === b" a and b must be the same value and also the same type for it to evaluate to true.
Take the following example
var a = 1;
var b = "1";
if (a == b) //evaluates to true as a and b are both 1
{
alert("a == b");
}
if (a === b) //evaluates to false as a is not the same type as b
{
alert("a === b");
}
In summary; using the == operator might evaluate to true in situations where you do not want it to so using the === operator would be safer.
In the 90% usage scenario it won't matter which one you use, but it is handy to know the difference when you get some unexpected behaviour one day.

=== checks same sides are equal in type as well as value.
Example:
'1' === 1 // will return "false" because `string` is not a `number`
Common example:
0 == '' // will be "true", but it's very common to want this check to be "false"
Another common example:
null == undefined // returns "true", but in most cases a distinction is necessary
Many times an untyped check would be handy because you do not care if the value is either undefined, null, 0 or ""

Javascript execution flow diagram for strict equality / Comparison '==='
Javascript execution flow diagram for non strict equality / comparison '=='

JavaScript === vs == .
0==false // true
0===false // false, because they are of a different type
1=="1" // true, auto type coercion
1==="1" // false, because they are of a different type

It means equality without type coercion
type coercion means JavaScript do not automatically convert any other data types to string data types
0==false // true,although they are different types
0===false // false,as they are different types
2=='2' //true,different types,one is string and another is integer but
javaScript convert 2 to string by using == operator
2==='2' //false because by using === operator ,javaScript do not convert
integer to string
2===2 //true because both have same value and same types

In a typical script there will be no performance difference. More important may be the fact that thousand "===" is 1 KB heavier than thousand "==" :) JavaScript profilers can tell you if there is a performance difference in your case.
But personally I would do what JSLint suggests. This recommendation is there not because of performance issues, but because type coercion means ('\t\r\n' == 0) is true.

The equal comparison operator == is confusing and should be avoided.
If you HAVE TO live with it, then remember the following 3 things:
It is not transitive: (a == b) and (b == c) does not lead to (a == c)
It's mutually exclusive to its negation: (a == b) and (a != b) always hold opposite Boolean values, with all a and b.
In case of doubt, learn by heart the following truth table:
EQUAL OPERATOR TRUTH TABLE IN JAVASCRIPT
Each row in the table is a set of 3 mutually "equal" values, meaning that any 2 values among them are equal using the equal == sign*
** STRANGE: note that any two values on the first column are not equal in that sense.**
'' == 0 == false // Any two values among these 3 ones are equal with the == operator
'0' == 0 == false // Also a set of 3 equal values, note that only 0 and false are repeated
'\t' == 0 == false // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
'\r' == 0 == false // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
'\n' == 0 == false // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
'\t\r\n' == 0 == false // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
null == undefined // These two "default" values are not-equal to any of the listed values above
NaN // NaN is not equal to any thing, even to itself.

There is unlikely to be any performance difference between the two operations in your usage. There is no type-conversion to be done because both parameters are already the same type. Both operations will have a type comparison followed by a value comparison.

Simply
== means comparison between operands with type coercion
and
=== means comparison between operands without type coercion.
Type coercion in JavaScript means automatically converting data types to other data types.
For example:
123 == "123" // Returns true, because JS coerces string "123" to number 123
// and then goes on to compare `123 == 123`.
123 === "123" // Returns false, because JS does not coerce values of different types here.

Yes! It does matter.
=== operator in javascript checks value as well as type where as == operator just checks the value (does type conversion if required).
You can easily test it. Paste following code in an HTML file and open it in browser
<script>
function onPageLoad()
{
var x = "5";
var y = 5;
alert(x === 5);
};
</script>
</head>
<body onload='onPageLoad();'>
You will get 'false' in alert. Now modify the onPageLoad() method to alert(x == 5); you will get true.

As a rule of thumb, I would generally use === instead of == (and !== instead of !=).
Reasons are explained in in the answers above and also Douglas Crockford is pretty clear about it (JavaScript: The Good Parts).
However there is one single exception:
== null is an efficient way to check for 'is null or undefined':
if( value == null ){
// value is either null or undefined
}
For example jQuery 1.9.1 uses this pattern 43 times, and the JSHint syntax checker even provides the eqnull relaxing option for this reason.
From the jQuery style guide:
Strict equality checks (===) should be used in favor of ==. The only
exception is when checking for undefined and null by way of null.
// Check for both undefined and null values, for some important reason.
undefOrNull == null;
EDIT 2021-03:
Nowadays most browsers
support the Nullish coalescing operator (??)
and the Logical nullish assignment (??=), which allows a more concise way to
assign a default value if a variable is null or undefined, for example:
if (a.speed == null) {
// Set default if null or undefined
a.speed = 42;
}
can be written as any of these forms
a.speed ??= 42;
a.speed ?? a.speed = 42;
a.speed = a.speed ?? 42;

It's a strict check test.
It's a good thing especially if you're checking between 0 and false and null.
For example, if you have:
$a = 0;
Then:
$a==0;
$a==NULL;
$a==false;
All returns true and you may not want this. Let's suppose you have a function that can return the 0th index of an array or false on failure. If you check with "==" false, you can get a confusing result.
So with the same thing as above, but a strict test:
$a = 0;
$a===0; // returns true
$a===NULL; // returns false
$a===false; // returns false

=== operator checks the values as well as the types of the variables for equality.
== operator just checks the value of the variables for equality.

JSLint sometimes gives you unrealistic reasons to modify stuff. === has exactly the same performance as == if the types are already the same.
It is faster only when the types are not the same, in which case it does not try to convert types but directly returns a false.
So, IMHO, JSLint maybe used to write new code, but useless over-optimizing should be avoided at all costs.
Meaning, there is no reason to change == to === in a check like if (a == 'test') when you know it for a fact that a can only be a String.
Modifying a lot of code that way wastes developers' and reviewers' time and achieves nothing.

A simple example is
2 == '2' -> true, values are SAME because of type conversion.
2 === '2' -> false, values are NOT SAME because of no type conversion.

The top 2 answers both mentioned == means equality and === means identity. Unfortunately, this statement is incorrect.
If both operands of == are objects, then they are compared to see if they are the same object. If both operands point to the same object, then the equal operator returns true. Otherwise,
the two are not equal.
var a = [1, 2, 3];
var b = [1, 2, 3];
console.log(a == b) // false
console.log(a === b) // false
In the code above, both == and === get false because a and b are not the same objects.
That's to say: if both operands of == are objects, == behaves same as ===, which also means identity. The essential difference of this two operators is about type conversion. == has conversion before it checks equality, but === does not.

The problem is that you might easily get into trouble since JavaScript have a lot of implicit conversions meaning...
var x = 0;
var isTrue = x == null;
var isFalse = x === null;
Which pretty soon becomes a problem. The best sample of why implicit conversion is "evil" can be taken from this code in MFC / C++ which actually will compile due to an implicit conversion from CString to HANDLE which is a pointer typedef type...
CString x;
delete x;
Which obviously during runtime does very undefined things...
Google for implicit conversions in C++ and STL to get some of the arguments against it...

From the core javascript reference
=== Returns true if the operands are strictly equal (see above)
with no type conversion.

Equality comparison:
Operator ==
Returns true, when both operands are equal. The operands are converted to the same type before being compared.
>>> 1 == 1
true
>>> 1 == 2
false
>>> 1 == '1'
true
Equality and type comparison:
Operator ===
Returns true if both operands are equal and of the same type. It's generally
better and safer if you compare this way, because there's no behind-the-scenes type conversions.
>>> 1 === '1'
false
>>> 1 === 1
true

Here is a handy comparison table that shows the conversions that happen and the differences between == and ===.
As the conclusion states:
"Use three equals unless you fully understand the conversions that take
place for two-equals."
http://dorey.github.io/JavaScript-Equality-Table/

null and undefined are nothingness, that is,
var a;
var b = null;
Here a and b do not have values. Whereas, 0, false and '' are all values. One thing common beween all these are that they are all falsy values, which means they all satisfy falsy conditions.
So, the 0, false and '' together form a sub-group. And on other hand, null & undefined form the second sub-group. Check the comparisons in the below image. null and undefined would equal. The other three would equal to each other. But, they all are treated as falsy conditions in JavaScript.
This is same as any object (like {}, arrays, etc.), non-empty string & Boolean true are all truthy conditions. But, they are all not equal.

What is this assignment construct called? And can you do it in Php?

I have often used the following construct in Javascript:
var foo = other_var || "default_value";
In Javascript, if the left side is falsy, then the value on the right side is assigned.
It is very handy, and saves writing longer and unnecessarily explicit ternary expressions.
Is there a name for this sort of construct ?
Bonus: Is there a trick to do this in Php without using a ternary operator?
PS: another variant is to throw an error if you don't get a truthy value, instead of giving a default value:
var foo = something || alert("foo is not set!");

The logical-or (usually ||) operator is drastically different in many languages.
In some (like C, C++) it works like: "Evaluate the left-hand side; if it's true, return true, otherwise evaluate the right hand-side and return true if it's true or false otherwise." The result is always boolean here.
In others (like Javascript, Python, I believe that PHP also) it's more like: "Evaluate the left-hand side; if it's true, return it, otherwise evaluate the right-hand side and return the result." Then the result can be of any type and you can do constructs like:
a = (b || c); // equivalent to a = b ? b : c;
or quite fancy:
function compare(A, B) { // -1 if A<B, 0 if A==B, 1 if A>B
return B.x - A.x || B.y - A.y;
}

I believe it's just called an OR construct. There are a lot of good examples on using assignments here:
http://php.net/manual/en/language.operators.assignment.php

It is just a logical OR operator. Follow the link for more information in javascript.
From the examples in the docs:
o1=true || true // t || t returns true
o2=false || true // f || t returns true
o3=true || false // t || f returns true
o4=false || (3 == 4) // f || f returns false
o5="Cat" || "Dog" // t || t returns Cat
o6=false || "Cat" // f || t returns Cat
o7="Cat" || false // t || f returns Cat
EDIT: Regarding the BONUS, it appears as though you can do something similar with the ternary in recent versions of PHP by doing:
expr1 ?: expr3
From the PHP docs:
Since PHP 5.3, it is possible to leave out the middle part of the ternary operator. Expression expr1 ?: expr3 returns expr1 if expr1 evaluates to TRUE, and expr3 otherwise.
I'm not familiar with PHP, so I'd be interested to know the result.

This works:
$mytruevalue = true;
$foo = $mytruevalue or $foo = "20";
echo $foo;
The above prints "1" because that is the string representation of true ($mytruevalue is true).
$myfalsevalue = false;
$foo = $myfalsevalue or $foo = "20";
echo $foo;
This, however, prints "20" because $myfalsevalue is false.
If both values are equal to false, it prints nothing.
Hope this helps.

Is there a name for this sort of
construct ?
It is the logical OR operator.
Bonus: Is there a trick to do this in
Php without using a ternary operator?
No, with PHP, you can do so only with the help of ternay operator.

Is there anyway to implement XOR in javascript

I'm trying to implement XOR in javascript in the following way:
// XOR validation
if ((isEmptyString(firstStr) && !isEmptyString(secondStr)) ||
(!isEmptyString(firstStr) && isEmptyString(secondStr))
{
alert(SOME_VALIDATION_MSG);
return;
}
Is there a better way to do this in javascript?
Thanks.

As others have pointed out, logical XOR is the same as not-equal for booleans, so you can do this:
// XOR validation
if( isEmptyString(firstStr) != isEmptyString(secondStr) )
{
alert(SOME_VALIDATION_MSG);
return;
}

I pretend that you are looking for a logical XOR, as javascript already has a bitwise one (^) :)
I usually use a simple ternary operator (one of the rare times I use one):
if ((isEmptyString(firstStr) ? !isEmptyString(secondStr)
: isEmptyString(secondStr))) {
alert(SOME_VALIDATION_MSG);
return;
}
Edit:
working on the #Jeff Meatball Yang solution
if ((!isEmptyString(firstStr) ^ !isEmptyString(secondStr))) {
alert(SOME_VALIDATION_MSG);
return;
}
you negate the values in order to transform them in booleans and then apply the bitwise xor operator. Maybe it is not so maintainable as the first solution (or maybe I'm too accustomed to the first one)

You are doing an XOR of boolean values which is easy to model into a bitwise XOR (which Javascript has):
var a = isEmptyString(firstStr) ? 1 : 0;
var b = isEmptyString(secondStr) ? 1 : 0;
if(a ^ b) { ... }
http://www.howtocreate.co.uk/xor.html

You could use the bitwise XOR operator (^) directly:
if (isEmptyString(firstStr) ^ isEmptyString(secondStr)) {
// ...
}
It will work for your example since the boolean true and false values are converted into 1 and 0 because the bitwise operators work with 32-bit integers.
That expression will return also either 0 or 1, and that value will be coerced back to Boolean by the if statement.
You should be aware of the type coercion that occurs with the above approach, if you are looking for good performance, I wouldn't recommend you to work with the bitwise operators, you could also make a simple function to do it using only Boolean logical operators:
function xor(x, y) {
return (x || y) && !(x && y);
}
if (xor(isEmptyString(firstStr), isEmptyString(secondStr))) {
// ...
}

Easier one method:
if ((x+y) % 2) {
//statement
}
assuming of course that both variables are true booleans, that is, 1 or 0.
If x === y you'll get an even number, so XOR will be 0.
And if x !== y then you'll get an odd number, so XOR will be 1 :)
A second option, if you notice that x != y evaluates as a XOR, then all you must do is
if (x != y) {
//statement
}
Which will just evaluate, again, as a XOR. (I like this much better)
Of course, a nice idea would be to implement this into a function, but it's your choice only.
Hope any of the two methods help someone! I mark this answer as community wiki, so it can be improved.

Checkout this explanation of different implementations of XOR in javascript.
Just to summarize a few of them right here:
if( ( isEmptyString(firstStr) || isEmptyString(secondStr)) && !( isEmptyString(firstStr) && isEmptyString(secondStr)) ) {
alert(SOME_VALIDATION_MSG);
return;
}
OR
if( isEmptyString(firstStr)? !isEmptyString(secondStr): isEmptyString(secondStr)) {
alert(SOME_VALIDATION_MSG);
return;
}
OR
if( (isEmptyString(firstStr) ? 1 : 0 ) ^ (isEmptyString(secondStr) ? 1 : 0 ) ) {
alert(SOME_VALIDATION_MSG);
return;
}
OR
if( !isEmptyString(firstStr)!= !isEmptyString(secondStr)) {
alert(SOME_VALIDATION_MSG);
return;
}

Quoting from this article:
Unfortunately, JavaScript does not have a logical XOR operator.
You can "emulate" the behaviour of the XOR operator with something like:
if( !foo != !bar ) {
...
}
The linked article discusses a couple of alternative approaches.

XOR just means "are these two boolean values different?". Therefore:
if (!!isEmptyString(firstStr) != !!isEmptyString(secondStr)) {
// ...
}
The !!s are just to guarantee that the != operator compares two genuine boolean values, since conceivably isEmptyString() returns something else (like null for false, or the string itself for true).

Assuming you are looking for the BOOLEAN XOR, here is a simple implementation.
function xor(expr1, expr2){
return ((expr1 || expr2) && !(expr1 && expr2));
}
The above derives from the definition of an "exclusive disjunction" {either one, but not both}.

Since the boolean values true and false are converted to 1 and 0 respectively when using bitwise operators on them, the bitwise-XOR ^ can do double-duty as a logical XOR as well as a bitwiseone, so long as your values are boolean values (Javascript's "truthy" values wont work). This is easy to acheive with the negation ! operator.
a XOR b is logially equivalent to the following (short) list of expressions:
!a ^ !b;
!a != !b;
There are plenty of other forms possible - such as !a ? !!b : !b - but these two patterns have the advantage of only evaluating a and b once each (and will not "short-circuit" too if a is false and thus not evaluate b), while forms using ternary ?:, OR ||, or AND && operators will either double-evaluate or short-circuit.
The negation ! operators in both statements is important to include for a couple reasons: it converts all "truthy" values into boolean values ( "" -> false, 12 -> true, etc.) so that the bitwise operator has values it can work with, so the inequality != operator only compares each expression's truth value (a != b would not work properly if a or b were non-equal, non-empty strings, etc.), and so that each evaluation returns a boolean value result instead of the first "truthy" value.
You can keep expanding on these forms by adding double negations (or the exception, !!a ^ !!b, which is still equivalent to XOR), but be careful when negating just part of the expression. These forms may seem at first glance to "work" if you're thinking in terms of distribution in arithmatic (where 2(a + b) == 2a + 2b, etc.), but in fact produce different truth tables from XOR (these produce similar results to logical NXOR):
!( a ^ b )
!( !!a ^ !!b )
!!a == !!b
The general form for XOR, then, could be the function (truth table fiddle):
function xor( a, b ) { return !a ^ !b; }
And your specific example would then be:
if ( xor( isEmptyString( firstStr ), isEmptyString( secondStr ) ) ) { ... }
Or if isEmptyString returns only boolean values and you don't want a general xor function, simply:
if ( isEmptyString( firstStr ) ^ isEmptyString( secondStr ) ) { ... }

Javascript does not have a logical XOR operator, so your construct seems plausible. Had it been numbers then you could have used ^ i.e. bitwise XOR operator.
cheers

here's an XOR that can accommodate from two to many arguments
function XOR() {
for (var i = 1; i < arguments.length; i++)
if ( arguments[0] != arguments[i] )
return false;
return true;
}
Example of use:
if ( XOR( isEmptyString(firstStr), isEmptyString(secondStr) ) ) {
alert(SOME_VALIDATION_MSG);
return;
}

I hope this will be the shortest and cleanest one
function xor(x,y){return true==(x!==y);}
This will work for any type

Here is an XOR function that takes a variable number of arguments (including two). The arguments only need to be truthy or falsy, not true or false.
function xor() {
for (var i=arguments.length-1, trueCount=0; i>=0; --i)
if (arguments[i])
++trueCount;
return trueCount & 1;
}
On Chrome on my 2007 MacBook, it runs in 14 ns for three arguments. Oddly, this slightly different version takes 2935 ns for three arguments:
function xorSlow() {
for (var i=arguments.length-1, result=false; i>=0; --i)
if (arguments[i])
result ^= true;
return result;
}

Try this:
function xor(x,y)
var result = x || y
if (x === y) {
result = false
}
return result
}

There's a few methods, but the ternary method (a ? !b : b) appears to perform best. Also, setting Boolean.prototype.xor appears to be an option if you need to xor things often.
http://jsperf.com/xor-implementations

You could do this:
Math.abs( isEmptyString(firstStr) - isEmptyString(secondStr) )
The result of that is the result of a XOR operation.

#george, I like your function for its capability to take in more than 2 operands. I have a slight improvement to make it return faster:
function xor() {
for (var i=arguments.length-1, trueCount=0; i>=0; --i)
if (arguments[i]) {
if (trueCount)
return false
++trueCount;
}
return trueCount & 1;
}

Develop Reference

JavaScript is the programming language of the Web.

Why is there no logical xor in JavaScript? - javascript

Why is there no logical xor in JavaScript?

Javascript has a bitwise XOR operator : ^ var nb = 5^9 // = 12 You can use it with booleans and it will give the result as a 0 or 1 (which you can convert back to boolean, e.g. result = !!(op1 ^ op2)). But as John said, it's equivalent to result = (op1 != op2), which is clearer.

The XOR of two booleans is simply whether they are different, therefore: Boolean(a) !== Boolean(b)

Covert to boolean and then perform xor like - !!a ^ !!b

Check out: Logical XOR in JavaScript You can mimic it something like this: if( ( foo && !bar ) || ( !foo && bar ) ) { ... }

How about transforming the result int to a bool with double negation? Not so pretty, but really compact. var state1 = false, state2 = true; var A = state1 ^ state2; // will become 1 var B = !!(state1 ^ state2); // will become true console.log(A); console.log(B);

One liner for Boolean: if (x ? !y : y) { do something cool }

The reason there is no logical XOR (^^) is because unlike && and || it does not give any lazy-logic advantage. That is the state of both expressions on the right and left have to be evaluated.

In Typescript (The + changes to numeric value): value : number = (+false ^ +true) So: value : boolean = (+false ^ +true) == 1

cond1 xor cond2 is equivalent to cond1 + cond 2 == 1: Here's the proof : let ops = [[false, false],[false, true], [true, false], [true, true]]; function xor(cond1, cond2){ return cond1 + cond2 == 1; } for(op of ops){ console.log(`${op[0]} xor ${op[1]} is ${xor(op[0], op[1])}`) }

Hey I found this solution, to make and XOR on JavaScript and TypeScript. if( +!!a ^ +!!b ) { //This happens only when a is true and b is false or a is false and b is true. } else { //This happens only when a is true and b is true or a is false and b is false }

Try this short and easy to understand one function xor(x,y){return true==(x!==y);} function xnor(x,y){return !xor(x,y);} This will work for any data type

Related

Execute query in portions and return values jQuery php [duplicate]

Javascript == and === comparison [duplicate]

When to use equality ("==") instead of identity ("===")? [duplicate]

What is this assignment construct called? And can you do it in Php?

Is there anyway to implement XOR in javascript

Categories

Resources