Since the `Array` constructor is ambiguous in how it deals with its parameters,

it is highly recommended to always use the array literals - `[]` notation -

when creating new arrays.

[1, 2, 3]; // Result: [1, 2, 3]

new Array(1, 2, 3); // Result: [1, 2, 3]

[3]; // Result: [3]

new Array(3); // Result: []

new Array('3') // Result: ['3']

In cases when there is only one argument passed to the `Array` constructor,

and that argument is a `Number`, the constructor will return a new *sparse*

array with the `length` property set to the value of the argument. It should be

noted that **only** the `length` property of the new array will be set this way,

the actual indexes of the array will not be initialized.

1 in arr; // false, the index was not set

The behavior of being able to set the length of the array upfront only comes in

handy in a few cases, like repeating a string, in which it avoids the use of a

`for loop` code.

Although arrays in JavaScript are objects, there are no good reasons to use

the [`for in loop`](#object.forinloop) in for iteration on them. In fact there

are a number of good reasons **against** the use of `for in` on arrays.

Since the `for in` loop enumerates all the properties that are on the prototype

chain and the only way to exclude those properties is to use

[`hasOwnProperty`](#object.hasownproperty), it is already up to **twenty times**

slower than a normal `for` loop.

In order to achieve the best performance when iterating over arrays, it is best

to use the classic `for` loop.

There is one extra catch in the above example, that is the caching of the

length of the array via `l = list.length`.

Although the `length` property is defined on the array itself, there is still an

overhead for doing the lookup on each iteration of the loop. And while recent

JavaScript engines **may** apply optimization in this case, there is no way of

telling whether the code will run on one of these newer engines or not.

In fact, leaving out the caching may result in the loop being only **half as

fast** as with the cached length.

While the *getter* of the `length` property simply returns the number of

Assigning a smaller length does truncate the array, but increasing the length

does not have any effect on the array.

For the best performance it is recommended to always use the plain `for` loop

and cache the `length` property. The use of `for in` on an array is a sign of

badly written code that is prone to bugs and bad performance.

Constructors in JavaScript are yet again different from many other languages. Any

function call that is preceded by the `new` keyword acts as a constructor.

Inside the constructor - the called function - the value of `this` refers to a

newly created `Object`. The [`prototype`](#object.prototype) of this **new**

object is set to the `prototype` of the function object that was invoked as the

constructor.

If the function that was called has no explicit `return` statement, then it

implicitly returns the value of `this` - the new object.

The above calls `Foo` as constructor and sets the `prototype` of the newly

created object to `Foo.prototype`.

In case of an explicit `return` statement the function returns the value

specified that statement, **but only** if the return value is an `Object`.

new Bar(); // a new object

new Test(); // the returned object

When the `new` keyword is omitted, the function will **not** return a new object.

this.bla = 1; // gets set on the global object

While the above example might still appear to work in some cases, due to the

workings of [`this`](#function.this) in JavaScript, it will use the

*global object* as the value of `this`.

In order to be able to omit the `new` keyword, the constructor function has to

explicitly return a value.

Both calls to `Bar` return the exact same thing, a newly create object which

It is also to note that the call `new Bar()` does **not** affect the prototype

of the returned object. While the prototype will be set on the newly created

object, `Bar` never returns that new object.

In the above example, there is no functional difference between using and

not using the `new` keyword.

An often made recommendation is to **not** use `new` since forgetting its use

may lead to bugs.

In order to create new object, one should rather use a factory and construct a

new object inside of that factory.

While the above is robust against a missing `new` keyword and certainly makes

1. It uses more memory since the created objects do **not** share the methods

on a prototype.

2. In order to inherit the factory needs to copy all the methods from another

object or put that object on the prototype of the new object.

3. Dropping the prototype chain just because of a left out `new` keyword

somehow goes against the spirit of the language.

While omitting the `new` keyword might lead to bugs, it is certainly **not** a

reason to drop the use of prototypes altogether. In the end it comes down to

which solution is better suited for the needs of the application, it is

especially important to choose a specific style of object creation **and stick**

with it.