Type

Objects are the general building block upon which much of JS is built. They are one of the 6 primary types (called “language types” in the specification) in JS:

• string
• number
• boolean
• null
• undefined
• object

Note that the simple primitives (string, number, boolean, null, and undefined) are not themselves objects. null is sometimes referred to as an object type, but this misconception stems from a bug in the language which causes typeof null to return the string "object" incorrectly (and confusingly). In fact, null is its own primitive type.

It’s a common mis-statement that “everything in JavaScript is an object”. This is clearly not true.

By contrast, there are a few special object sub-types, which we can refer to as complex primitives.

function is a sub-type of object (technically, a “callable object”). Functions in JS are said to be “first class” in that they are basically just normal objects (with callable behavior semantics bolted on), and so they can be handled like any other plain object.

Arrays are also a form of objects, with extra behavior. The organization of contents in arrays is slightly more structured than for general objects.

Built-in Objects

There are several other object sub-types, usually referred to as built-in objects. For some of them, their names seem to imply they are directly related to their simple primitives counter-parts, but in fact, their relationship is more complicated, which we’ll explore shortly.

• String
• Number
• Boolean
• Object
• Function
• Array
• Date
• RegExp
• Error

These built-ins have the appearance of being actual types, even classes, if you rely on the similarity to other languages such as Java’s String class.

But in JS, these are actually just built-in functions. Each of these built-in functions can be used as a constructor (that is, a function call with the new operator — see Chapter 2), with the result being a newly constructed object of the sub-type in question. For instance:

var strPrimitive = "I am a string";
typeof strPrimitive;                            // "string"
strPrimitive instanceof String;                    // false
var strObject = new String( "I am a string" );
typeof strObject;                                 // "object"
strObject instanceof String;                    // true
// inspect the object sub-type
Object.prototype.toString.call( strObject );    // [object String]

We’ll see in detail in a later chapter exactly how the Object.prototype.toString... bit works, but briefly, we can inspect the internal sub-type by borrowing the base default toString() method, and you can see it reveals that strObject is an object that was in fact created by the String constructor.

The primitive value "I am a string" is not an object, it’s a primitive literal and immutable value. To perform operations on it, such as checking its length, accessing its individual character contents, etc, a String object is required.

Luckily, the language automatically coerces a "string" primitive to a String object when necessary, which means you almost never need to explicitly create the Object form. It is strongly preferred by the majority of the JS community to use the literal form for a value, where possible, rather than the constructed object form.

Consider:

var strPrimitive = "I am a string";
console.log( strPrimitive.length );            // 13
console.log( strPrimitive.charAt( 3 ) );    // "m"

In both cases, we call a property or method on a string primitive, and the engine automatically coerces it to a String object, so that the property/method access works.

The same sort of coercion happens between the number literal primitive 42 and the new Number(42) object wrapper, when using methods like 42.359.toFixed(2). Likewise for Boolean objects from "boolean" primitives.

null and undefined have no object wrapper form, only their primitive values. By contrast, Date values can only be created with their constructed object form, as they have no literal form counter-part.

Objects, Arrays, Functions, and RegExps (regular expressions) are all objects regardless of whether the literal or constructed form is used. The constructed form does offer, in some cases, more options in creation than the literal form counterpart. Since objects are created either way, the simpler literal form is almost universally preferred. Only use the constructed form if you need the extra options.

Error objects are rarely created explicitly in code, but usually created automatically when exceptions are thrown. They can be created with the constructed form new Error(..), but it’s often unnecessary.