Join the Stack Overflow Community
Stack Overflow is a community of 6.5 million programmers, just like you, helping each other.
Join them; it only takes a minute:
Sign up

I am following tutorial of javascript on w3schools.com . While reading almost on each page they give note to user as "Avoid creating objects" instead use primitive data types. 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.
share|improve this question
26  
w3schools.com is notoriously poor. For decent information, look elsewhere, such as MDN. That said, creating the object versions of primitives is almost never necessary or appropriate. – T.J. Crowder 7 hours ago
1  
well, in the example you provide, using the constructor-function would be sort of hard to read. But as your code gets more complex, it becomes sort of impossible not to use objects. Also, I find w3schools' information to not be that great. I'd recommend looking at MDN (developer.mozilla.org/en-US) for more in-depth documentation. Although it might be understandable if you're just using w3schools as a starting point. – stinodes 7 hours ago
    
@Jone Dotosvky Have a read here w3fools.com – Flying Gambit 7 hours ago
1  
One of the reasons could be code optimization and readability – Flying Gambit 7 hours ago
    

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

share|improve this answer
    
Great answer! Another thing that's tangentially related is the behavior of this when primitives are passed to a function context in non-strict mode vs. strict mode. Something like this: function coerce() { return this; }; typeof coerce.call(5) === "object"; /* non-strict mode */ typeof coerce.call(5) === "number"; /* strict mode */ – Patrick Roberts 6 hours ago
    
@PatrickRoberts: If you use call or apply, yes. :-) – T.J. Crowder 6 hours ago
    
I just meant it was related because it's a way of keeping a reference to the temporary object created when doing so in non-strict mode. For example, you could assign the function to a prototype to do that: Number.prototype.coerce = coerce; 5..coerce(); – Patrick Roberts 5 hours ago
    
@PatrickRoberts: Quite. :-) – T.J. Crowder 3 hours ago

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.