What practical use is a Boolean object in Javascript?

Question

Given that in JavaScript

console.log("var F=new Boolean(false)")
console.log("( F != (F==false))",(( F != (F==false)) ? "TRUE" : "false"));
console.log("(!F != (F==false))",((!F != (F==false)) ? "TRUE" : "false"));

prints:

( F != (F==false)) TRUE
(!F != (F==false)) TRUE

which means that Boolean objects are not dop-in substitutes for a boolean primitive in typical conditions like:

if(someBoolean) ... // always true
if(!someBoolean) ... // always false

And that JavaScript's Set and Map collections permit any type, including primitives.

What use are Boolean objects, in particular; and the objects representing other primitive types in general, since they have all sort of weird in consistencies associated with them?

Note: I am specifically asking what are the use-cases (if any), not how they are different from their primitive counterparts.

• Wondercricket: this post may provide some insight. I'm not flagging it as a dup as it is 7 years old, and may be out of date
• Javid Asgarov: stackoverflow.com/questions/856324/… — Does this help ?
• Jordan Running: Also: stackoverflow.com/questions/6132949/… FWIW, WeakMap keys must be objects, i.e. (new WeakMap).set(true, "foo") raises an error whereas (new WeakMap).set(Boolean(true), "foo") does not.
• Cornelius Dol: @askerovlab: Not really. The answers there discuss the differences and some of the traps, but not the pragmatic use-cases for the object(s).
• Mike Cluck: I don't really think there are any practical uses. Try finding anything that isn't just testing compatibility either with a framework or an engine. Oriol points out what you can do with it but I wouldn't exactly call such things practical.

Answer 1

Boolean objects are just objects, and thus are truthy.

console.log(!!new Boolean(true)); // true
console.log(!!new Boolean(false)); // true

Boolean objects exist because this way you can add methods to Boolean.prototype and use them on primitive booleans (which will be wrapped into booolean objects under the hood).

Boolean.prototype.foo = function() {
 console.log("I'm the boolean " + this + "!!");
};
true.foo();
false.foo();

They are also useful when you want to store properties in a boolean.

var wrappedBool = new Boolean(false);
wrappedBool.foo = "bar";
console.log("Property foo: ", wrappedBool.foo); // "bar"
console.log("Unwrapped bool: ", wrappedBool.valueOf()); // false

But that's not recommended.

• ThisClark: Please explain "truthy" or provide reference. Why does the first example make any kind of sense?
• Baruch: Truthy just means that isn't null, false, undefined, 0, or empty. true === {} true, but true === "" is false
• Oriol: @ThisClark Truthy means that, when coerced to a boolean, it becomes true. The double not !! or the Boolean function are the standard ways to coerce a value to a boolean. All values are truthy except the primitives undefined, null, false, -0, +0, NaN, "".
• Bekim Bacaj: That's not why Boolean objects can have properties. All objects can have properties, that's not deliberate. That's inherent. All except for null. The null is: not-an-object object. Analogous to the number NaN, therefore it cannot accept properties. So no, Boolean objects don't exist so you can add methods to them.
• Oriol: @BekimBacaj I mean that if boolean objects didn't exist, primitive booleans wouldn't be object-coercible. In that case you wouldn't be able to add methods to Boolean.prototype and call them on primitive booleans.

Answer 2

Say we have...

var F = new Boolean(); 
var f = false;

Where F is an object and f is a primitive.

Objects are passed by reference. Primitives are passed by value.

Whatever the type of an object is, it always retains its individuality; identity. It behaves like a real (material) object, taking its own unique space in the Universe.

Therefore...

var Fn = new Boolean(); 

is not 'equal' to F, even when comparing with dynamic type operator '==' even-though they are of the same type and carry the same value:

Fn == F; 
>> false

That's because ( as already underlined ), they are two separate & different objects who carry items of the same value, ie., false. Which is nonetheless - not the same false.

And, because there's no type conversion ( since they are of the same type already ) they will be compared by reference - which are obviously pointing to two separate objects, meaning: they are not the same object!

We should imagine our JavaScript objects of a given type as packets specifically designed to carry a certain type of valuables. This way of thinking will make it far easier to understand even the most unexpected results of our work. And this is why null is beautiful.

The use case of a practical value (would have been), that a certain Boolean object can carry both values but remain the same (identifiable) object. Alas the Boolean object has been left at its initial, introduction state in JavaScript development. And is now practically useless and can only be used to determine that this false:true value comes from a different process and return than the one you are comparing it too.

Regards.