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 falseThe 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).