Use of the functionality provided by the new keyword has several advantages over building each object from scratch:
- Performance. This is a side-effect of #1: if we want to add 10 methods to every object we create, we could just write a creation function that manually assigns each method to each new object... Or, we could assign them to the creation function's prototype and use new to stamp out new objects. Not only is this faster (no code needed for each and every method on the prototype), it avoids ballooning each object with separate properties for each method. On slower machines (or especially, slower JS interpreters) when many objects are being created this can mean a significant savings in time and memory.
And yes, new has one crucial disadvantage, ably described by other answers: if we forget to use it, our code will break without warning. Fortunately, that disadvantage is easily mitigated - simply add a bit of code to the function itself:
Now we can have the advantages of new without having to worry about problems caused by accidentally misuse. We could even add an assertion to the check if the thought of broken code silently working bothers you. Or, as some commented, use the check to introduce a runtime exception:
(Note that this snippet is able to avoid hard-coding the constructor function name, as unlike the previous example it has no need to actually instantiate the object - therefore, it can be copied into each target function without modification.)
On top of this good naming habits help. After all functions do things and therefore there should be a verb in its name whereas classes represent objects and are nouns and adjectives with no verb.
Its interesting how SO's syntax colouring has interpretted the code above.
We have come from the C# world where using the keyword "new" is so natural that it is the factory design pattern that looks weird to me.
Then, we found the "new" keyword which to me, it "separate" things. With the new keyword, it creates things. Without the new keyword, We know we won't confuse it with creating things unless the function we invoking gives me strong clues of that.
For instance, with
var bar=foo(); We have no clues as what bar could possibly be.... Is it a return value or is it a newly created object? But with
var bar = new foo(); We know for sure bar is an object.
Another case for new is what we call Pooh Coding. Winnie the Pooh follows his tummy. We say go withthe language we are using, not against it. Chances are that the maintainers of the language will optimize the language for the idioms they try to encourage. If they put a new keyword into the language they probably think it makes sense to be clear when creating a new instance.
Code written following the language's intentions will increase in efficiency with each release. And code avoiding the key constructs of the language will suffer with time.
EDIT: And this goes well beyond performance. We can't count the times I've heard (or said) "why the hell did they do that?" when finding strange looking code. It often turns out that at the time when the code was written there was some "good" reason for it. Following the Tao of the language is our best insurance for not having our code ridiculed some years from now.
The rationale behind not using the new keyword, is simple: By not using it at all, we avoid the pitfall that comes with accidentally omitting it. The construction pattern that YUWE uses, is an example of how we can avoid the new keyword altogether"
Alternatively we could so this:
But by doing so we run risk of someone forgetting to use the new keyword, and the this operator being all fubar. AFAIK there is no advantage to doing this (other than we are used to it). At The End Of The Day: It's about being defensive. Can we use the new statement? Yes. Does it make our code more dangerous? Yes. If we have ever written C++, it's akin to setting pointers to NULL after we delete them.