Why to avoid creating objects of primitives in JavaScript?

Question

I am following a JavaScript tutorial on W3Schools. While reading almost on each page they give note to user to "Avoid creating objects" and to use primitive data types instead. They give reason for this as "code becomes difficult to understand or execution speed will be decreased if object are used". Is it true that we should avoid creating objects in JavaScript?

For example:

var value = new Number(1);  // Avoid this
var value = 1;              // do something like this instead.

Answer 1

The statement "avoid creating objects" on its own is absurd in JavaScript, which has objects everywhere and is one of the most object-oriented languages in existence. But "avoid creating object versions of primitives," which is what the code you quote does, is valid. That is, avoid new String, new Number, and new Boolean.

JavaScript has both primitive and object versions of strings, numbers, and booleans. There's almost never any reason to create the object version of any of them explicitly, and doing so can indeed lead to confusion; see inline comments:

var s1, s2, n1, n2;

// These are false because with ===, an object is never equal to a non-object
s1 = new String("hi");
s2 = "hi";
console.log(s1 === s2); // false
n1 = new Number(42);
n2 = 42;
console.log(n1 === n2); // also false

// These are false because even with ==, two *different* objects are never equal
// (even if they're equivalent)
s1 = new String("what the...");
s2 = new String("what the...");
console.log(s1 == s2);  // also false
n1 = new Number(42);
n2 = new Number(42);
console.log(n1 == n2);  // also false

The object versions of strings, numbers, and booleans largely exist to enable methods on primitives to be provided using the same mechanism that provides methods to object types. When you do

console.log("foo".toUpperCase()); // "FOO"

a temporary object is created for the primitive string "foo", and then the toUpperCase property is read from that object. Since the object inherits from String.prototype, it has toUpperCase and all is well. Once the operation is done, the temporary object is thrown away (unless something keeps a reference to it, but nothing does and nothing can with toUpperCase, you'd have to add a method to String.prototype that returned the object in order for it to be kept around).

Answer 2

It changes the intuitive way the operators behave with numbers, strings and booleans:

• the strict comparison (===) breaks when any of the numbers is constructed, so 42 === 42 is true, while 42 === new Number(42) is not,
• the abstract comparison (==) breaks when both numbers are objects, so 42 == new Number(42) is true, while new Number(42) == new Number(42) is not,
• the typeof operator gives different result when a number is constructed, so typeof(42) is number, but typeof(new Number(42)) is object,
• when converted to a boolean, 0 is false, but new Number(0) is true, so the following two will have different behavior:

var a = 0;
if (a)
  console.log("not zero");
else
  console.log("zero!");     // "zero!"

var b = new Number(0);
if (b)
  console.log("not zero");     // "not zero"
else
  console.log("zero!");

So, avoid new Number, new String and new Boolean.

Apart from that, there is the issue of using / not using new with constructors. It stems from several facts:

• in JS, a constructor is a regular function, using this.foo syntax to add new properties and methods;
• when invoked without the new keyword, this becomes the global object, leading to side effects.

As a result, a tiny mistake can have catastrophic effects:

color = "blue";

var Fruit = function(color) {
  this.color = color;
  return this;
};

var apple = new Fruit("green");

console.log(apple.color);       // "green"  --  okay

console.log(color);             // "blue"  --  okay

var banana = Fruit("yellow");

console.log(banana.color);      // "yellow"  --  okay

console.log(color);             // "yellow"  --  wait, what?

console.log(banana.apple);      // "{ color: 'green' }"  --  what??

console.log(banana.document);   // "{ location: [Getter/Setter] }"  --  what???

(That's why some people resort to adding explicit checks in the constructor, or using closures instead. But that's for another story.)

Answer 3

Everybody only say "avoid using", "it can lead to confusion", "typeof x behaves weird", and for the most part they are right. But nobody is able to give you one single reason as to why you would want to use the constructor instead.

When you have many variables that has the same value, then you will allocate much more memory, if you instead construct a new class instances and use that one instead, then you would only allocate 1 single item. and the rest of your variables would just be pointers to the same object.

This could technically increase speed when you use structuredClone (but i don't know, haven't bench tested it)

Something that i have tested out at least is to see how much disc space you allocate when using IndexedDB.

// small simple kv indexeddb storage
let p,query=(e,...r)=>(p??=new Promise((e=>{const r=indexedDB.open("kv");r.onupgradeneeded=()=>r.result.createObjectStore("kv"),r.onsuccess=()=>{const t=r.result;query=(e,...r)=>{const n=t.transaction("kv","readwrite").objectStore("kv")[e](...r);return new Promise(((e,r)=>{n.onsuccess=()=>e(n.result),n.onerror=()=>r(n.error)}))},e()}}))).then((()=>query(e,...r)));
var kv=(...e)=>query(...e);

var arr = Array(1024).fill('a'.repeat(1024))

await kv('put', arr, 'stuff')
await kv('get', 'stuff')

var est = await navigator.storage.estimate()
est.usageDetails.indexedDB // chrome 105 allocated 1055761 bytes

now if we do the same thing but using slightly different thing by using string constructor instead:

// Now you are using the same instance instead.
var arr = Array(1024).fill(new String('a'.repeat(1024)))

await kv('put', arr, 'stuff')
await kv('get', 'stuff')

var est = await navigator.storage.estimate()
est.usageDetails.indexedDB // chrome 105 allocated 7353 bytes

now you saved about 1055761-7353 = 1048408 bytes...

If you want to test this out for yourself, always open up a new inkognito window and await both put/get operators, estimate can maybe give wrong value otherwise. and deleting it may not always clean up properly, that's why you should create a new inkognito window every time you want to compare stuff.

But in the end: yeaa... maybe don't use the constructor after all. it's almost never a good thing.

Just wanted you to know what the "real" differences is by using objects instead

...also if you use NodeJS v8.serialize(value) then the same example will yield a smaller Buffer when you use the same object instances (as the rest will just be pointers)

another reason for using objects instead could be if you wanted to do something with WeakRef, WeakMap where simple literals isn't acceptable.

Answer 4

Do not use new when invoking a Number(). Source: JSLint...

The "Do not use {a} as a constructor" error is thrown when JSLint, JSHint or ESLint encounters a call to String, Number, Boolean, Math or JSON preceded by the new operator. (Source: LintErrors.com: Do not use {a} as a constructor

console.log(Number("3") == Number("3"))

console.log(new Number("3") == new Number("3"))