A Drip of JavaScript

The Problems with for...in and JavaScript Arrays

2015-03-26T00:00:00+00:00

We've talked in the past about different ways of iterating over arrays. But in this drip we'll take a look at one way not to do it.

JavaScript's for...in loop iterates over the enumerable properties of an object like so:

var tMinus = {
    two: "Two",
    one: "One",
    zero: "Blast off!"
};

var countdown = "";

for (var step in tMinus) {
    countdown += tMinus[step] + "\n";
}

console.log(countdown);
// => "Two
//    One
//    Blast Off!
//    "

Because for...in operates on any JavaScript object, it is also possible to use it with arrays. For example:

var tMinus = [
    "Two",
    "One",
    "Blast off!"
];

var countdown = "";

for (var step in tMinus) {
    countdown += tMinus[step] + "\n";
}

console.log(countdown);
// => "Two
//    One
//    Blast Off!
//    "

However, there are three problems with using this approach on arrays. First, the for...in also iterates over an object's prototype properties if those properties are enumerable. For example:

Array.prototype.voice = "James Earl Jones";

var tMinus = [
    "Two",
    "One",
    "Blast off!"
];

var countdown = "";

for (var step in tMinus) {
    countdown += tMinus[step] + "\n";
}

console.log(countdown);
// => "Two
//    One
//    Blast Off!
//    James Earl Jones
//    "

That can be solved by using hasOwnProperty to exclude prototype properties.

Array.prototype.voice = "James Earl Jones";

Array.prototype.voice = "James Earl Jones";

var tMinus = [
    "Two",
    "One",
    "Blast off!"
];

var countdown = "";

for (var step in tMinus) {
    if (tMinus.hasOwnProperty(step)) {
        countdown += tMinus[step] + "\n";
    }
}

console.log(countdown);
// => "Two
//    One
//    Blast Off!
//    "

Second, according to the specification for...in loops may iterate over an object's values in an arbitrary order.

That's not really a problem for an ordinary object whose values are inherently unordered anyway. But you probably don't want your JavaScript engine handing back array values in a random order, because you could get unexpected results like this:

console.log(countdown);
// => "Blast Off!
//    One
//    Two
//    "

The third problem is that for...in iterates over all enumerable properties, not just the array's elements. As we've discussed before, it is possible to store additional properties on an array. This can also lead to unexpected results.

var tMinus = [
    "Two",
    "One",
    "Blast off!"
];

tMinus.announcer = "Morgan Freeman";

var countdown = "";

for (var step in tMinus) {
    if (tMinus.hasOwnProperty(step)) {
        countdown += tMinus[step] + "\n";
    }
}

console.log(countdown);
// => "Two
//    One
//    Blast Off!
//    Morgan Freeman
//    "

Because of these problems you will almost never want iterate over arrays with for...in loops. Instead, use an ordinary for loop, or one of the built-in array iteration methods like forEach or map.

Now you know one more quirk to avoid as you write safe and clean JavaScript.

Thanks for reading!

Josh Clanton

Measuring JavaScript Performance with console.time

2015-03-10T00:00:00+00:00

At one point or another almost every JavaScript developer has to deal with optimizing performance-critical code. But how exactly do you go about it? This drip will show you how to use console.time as a low-cost performance testing tool.

First, let's suppose that we have a scientific application that makes frequent use of the factorial function.

If you're not familiar with the factorial in mathematics, it basically works like this: Any input to the factorial function must be a non-negative integer. The factorial of X is the product of every positive integer less than or equal to X. In other words, the factorial of 3 is 1 * 2 * 3, the factorial of 4 is 1 * 2 * 3 * 4, and so on.

Here we have a simple implementation of factorial.

function factorial (num) {
    if (num < 0) {
        throw new Error("Number cannot be negative.");
    }

    if (num % 1 !== 0) {
        throw new Error("Number must be an integer.");
    }

    // The base case
    if (num === 0 || num === 1) {
        return 1;
    }

    // The general case
    return num * factorial(num - 1);
}

console.log(factorial(4));
// => 24

In order to optimize factorial, we need to measure its current performance so that we have something to compare against.

console.time("factorial test");

for (var i = 1; i < 100000; i++) {
    factorial(20);
}

console.timeEnd("factorial test");
// => 512.46ms

The console.time method starts a timer with the name that you give it. In this case we called our timer "factorial test". Correspondingly, when the console.timeEnd method is called with the same name, it will halt the timer and log how many milliseconds have elapsed.

You'll note that in order to get roughly accurate performance measurements, I reran the factorial calculation 100,000 times and it still only took about half a second. Modern JavaScript engines running on modern hardware are fast.

Now let's try optimizing factorial.

function factorial (num) {
    if (num < 0) {
        throw new Error("Number cannot be negative.");
    }

    if (num % 1 !== 0) {
        throw new Error("Number must be an integer.");
    }

    function factorialEquation (num) {
        // The base case
        if (num === 0 || num === 1) {
            return 1;
        }

        // The general case
        return num * factorialEquation(num - 1);
    }

    return factorialEquation(num);
}

console.time("factorial test");

for (var i = 1; i < 100000; i++) {
    factorial(20);
}

console.timeEnd("factorial test");
// => 81.39ms

The optimization in this case is quite simple. Rather than checking factorial's inputs every time the equation is recursively called, we have separated out the equation logic from the input checking logic and ensured that the input checks are only run once. The performance improvements are pretty substantial. Our test case goes from half a second to less than one tenth of a second.

Keep in mind that the performance characteristics of a given piece of code vary by JavaScript engine, so for real performance tests you should check in each browser you support.

It is also important to note that the vast majority of JavaScript code doesn't need to be heavily optimized. In the general case, readability and maintainability should trump optimization. Generally you will only need to optimize JavaScript that is part of your program's critical path, and then only if it has been found to be too slow for your use case.

The console.time and console.timeEnd methods are available in all modern browsers, including IE 11.

Now you have one more tool in your belt to help you put together excellent JavaScript applications.

Thanks for reading!

Josh Clanton

The Perils of Non-Local Mutation

2015-03-09T00:00:00+00:00

One of the most important things to understand about JavaScript is how to deal with the mutable nature of objects. Unlike primitives (strings, numbers, booleans, etc.) objects are subject to modification.

Consider this simple example:

var solarSystem = {
    planets: 9,
    inhabited: "Earth"
};

var homeSystem = solarSystem;

// Scientists reclassify Pluto
homeSystem.planets = 8;

console.log(solarSystem);
// => { planets: 8, inhabited: "Earth" }

In this example, both solarSystem and homeSystem point to the same underlying object. And when the number of planets is modified, that is reflected in both variables.

Ordinarily there isn't much point to explicitly declaring two variables for the same object. However, it is incredibly common to do so implicitly when defining a function.

var solarSystem = {
    planets: 9,
    inhabited: "Earth"
};

function reclassifyPluto (system) {
    system.planets = 8;
}

reclassifyPluto(solarSystem);

console.log(solarSystem);
// => { planets: 8, inhabited: "Earth" }

Here system becomes a reference to solarSystem, which the reclassifyPluto function modifies directly. That may not seem like such a big deal. But it can have far-reaching consequences.

var solarSystem = {
    planets: 9,
    inhabited: "Earth"
};

function simulateMarsSettlement (system) {
    system.inhabited = "Earth & Mars";

    return system;
}

function reclassifyPluto (system) {
    system.planets = 8;
}

var simulatedSystem = simulateMarsSettlement(solarSystem);

console.log(simulatedSystem);
// => { planets: 9, inhabited: "Earth & Mars" }

reclassifyPluto(solarSystem);

console.log(solarSystem);
// => { planets: 8, inhabited: "Earth & Mars" }

Why does solarSystem think that both Earth and Mars are inhabited? Because simulateMarsSettlement directly modified it. Imagine how difficult it would be to debug if there were dozens of functions depending on the solarSystem object which suddenly changed.

We could code defensively by freezing solarSystem so that it can't be modified. But this would only solve part of our problem. The underlying issue is that the functions are modifying an object which doesn't "belong" to them.

In general it is better to avoid modifying objects which are passed in as function arguments, because you may not know what else is depending on them. If you need a modified version of argument, then creating a copy is probably your best solution.

var solarSystem = {
    planets: 9,
    inhabited: "Earth"
};

function simulateMarsSettlement (system) {
    var simulation = {
        planets: system.planets,
        inhabited: system.inhabited
    };

    simulation.inhabited = "Earth & Mars";

    return simulation;
}

function reclassifyPluto (system) {
    var reclassified = {
        planets: system.planets,
        inhabited: system.inhabited
    };

    reclassified.planets = 8;

    return reclassified;
}

var simulatedSystem = simulateMarsSettlement(solarSystem);

console.log(simulatedSystem);
// => { planets: 9, inhabited: "Earth & Mars" }

// Replace solarSystem with updated version
var solarSystem = reclassifyPluto(solarSystem);

console.log(solarSystem);
// => { planets: 8, inhabited: "Earth" }

Note that in this solution we do end up modifying the solarSystem variable. But we do it "locally," not hidden away inside a function. This keeps our code simple and easy to reason about.

Thanks for reading!

Josh Clanton

Checking Date Equality in JavaScript

2015-02-17T00:00:00+00:00

When working with dates, one of a programmer's most common needs is to check whether one date matches another. And if you're like most programmers, the first way that you thought of doing it is something like this:

function isChristmas (dateToTest) {
    var christmas = new Date("12/25/2014");
    return (dateToTest === christmas);
}

Unfortunately, this function will never return true.

console.log(isChristmas(new Date("12/25/2014")));
// => false

The reason it will never return true is because of the way object equality works in JavaScript. Object equality isn't tested by the internal value of the object, but by identity. In other words, if it isn't the exact same copy of the Date object, it isn't considered equal.

To make our isChristmas function work, we need to check equality in a different way.

function isChristmas (dateToTest) {
    var christmas = new Date("12/25/2014");
    return (dateToTest.getTime() === christmas.getTime());
}

Here we compare the return values of getTime. The getTime method returns an integer representing the number of milliseconds since midnight of January 1, 1970 (the beginning of the Unix epoch).

And we can see that we now get the correct result.

console.log(isChristmas(new Date("12/25/2014")));
// => true

But if we happen to compare against a Date object that is the same day, but a different hour, we'll have trouble again.

console.log(isChristmas(new Date("12/25/2014 12:00")));
// => false

In order to take different times on the same day into account we might try checking only the year, month, and date of the month.

function isChristmas (dateToTest) {
    return (dateToTest.getFullYear() === 2014) &&
           // getMonth is 0-indexed
           (dateToTest.getMonth() === 11) &&
           (dateToTest.getDate() == 25);
}

console.log(isChristmas(new Date("12/25/2014 12:00")));
// => true

Despite the "gotcha" of getMonth returning a 0-indexed number for months, this function now works. However, it doesn't take into account the complexities of timezones and working with local time versus UTC/GMT time.

Because of these complexities, it is generally better to lean on a robust and well-tested library like Moment.js to do things like date comparisons.

But most importantly, now you know not to count on JavaScript's equality operators when comparing dates.

Thanks for reading!

Josh Clanton

Detecting Arrays (and other subtypes) vs. Objects in JavaScript

2015-02-07T00:00:00+00:00

When writing JavaScript, it is often necessary to detect whether a certain variable is an array or an ordinary object so that you can perform a different set of actions. For instance, consider a function that can be called with an object representing a marathon, or an array of objects representing multiple marathons:

function getListOfMarathonNames (marathons) {
    if (marathons instanceof Object) {
        // Return an array containing the name of the only
        // marathon given.
        return [marathons.name];
    } else if (marathons instanceof Array) {
        // Return an array containing all marathon names.
        return marathons.map(function(race) {
            return race.name;
        });
    }
}

At a glance, this seems like perfectly reasonable code. Unfortunately, it is hiding a major bug. Let's test it out to see how it behaves.

var londonMarathon = {
    name: "London Marathon",
    date: "April 13, 2014"
};

console.log(getListOfMarathonNames(londonMarathon));
// -> ["London Marathon"]

So far so good.

var moreMarathons = [
    {
        name: "New York City Marathon",
        date: "November 2, 2014"
    },
    {
        name: "Chicago Marathon",
        date: "October 12, 2014"
    }
];

console.log(getListOfMarathonNames(moreMarathons));
// -> [undefined]

What's going on here? The problem is that our function's array detection logic is reversed. Because in JavaScript arrays are just a special type of object, it is impossible for our else if to ever be triggered. And since the array we passed in doesn't have a name property, we end up returning an array containing only an undefined element.

In order to correct this logic we need to work in the other direction, first checking whether the input is of the Array subtype before proceeding to check whether it is part of the broader Object type.

function getListOfMarathonNames (marathons) {
    if (marathons instanceof Array) {
        // Return an array containing all marathon names.
        return marathons.map(function(race) {
            return race.name;
        });
    } else if (marathons instanceof Object) {
        // Return an array containing the name of the only
        // marathon given.
        return [marathons.name];
    }
}

console.log(getListOfMarathonNames(londonMarathon));
// -> ["London Marathon"]

console.log(getListOfMarathonNames(moreMarathons));
// -> ["New York City Marathon", "Chicago Marathon"]

And now we have everything working as it should.

Of course, this type of error can also occur when trying to detect other types of objects as well, like Date, RegExp, etc. The general rule is to check for the subtype first, only handling Object afterwards.

It's also worth noting that this isn't a comprehensive test for whether something is an array. While it will work in most cases, if you are working with iframes or objects from another "domain," instanceof isn't all that useful, and you'll probably want to use a utility library to handle the checking for you.

Thanks for reading!

Josh Clanton

Finding an Object's Size in JavaScript

2015-01-28T00:00:00+00:00

When working in JavaScript, we inevitably end up using objects as if they were hash/map data structures. While there are new data structures coming, for now we need to just work our way around the hash/map features that JavaScript objects don't have.

One of those little features is a convenient way to tell just how big an object is. Suppose we are doing some analysis of library data and have a set of books and authors that looks like this:

var bookAuthors = {
    "Farmer Giles of Ham": "J.R.R. Tolkien",
    "Out of the Silent Planet": "C.S. Lewis",
    "The Place of the Lion": "Charles Williams",
    "Poetic Diction": "Owen Barfield"
};

As part of our analysis, we send the book authors data to an API. Unfortunately, the API will only accept an object with up to a hundred books at a time. So we need a good way to tell how many books are in an object before trying to send them.

Our first inclination might be to try something like this:

function countProperties (obj) {
    var count = 0;

    for (var property in obj) {
        if (Object.prototype.hasOwnProperty.call(obj, property)) {
            count++;
        }
    }

    return count;
}

var bookCount = countProperties(bookAuthors);

// Outputs: 4
console.log(bookCount);

While this certainly works, it would be nice to avoid using a hand-rolled method just to count properties. Surely JavaScript has something better available? Fortunately, it does.

While it's not quite as simple as finding the length of an array, it is awfully close. In modern browsers, we can do this:

var bookCount = Object.keys(bookAuthors).length;

// Outputs: 4
console.log(bookCount);

The Object.keys method returns an array of all the object's own enumerable property keys. And since we are interested in knowing just how many properties there are, we can just check the array's length.

It's a little indirect, but now we can go about our business and make sure that we only call the API when our book count is below the acceptable threshold.

As I mentioned above, the keys method is only available in modern browsers, and is not available in IE8 and below. If you want to use it in those older browsers you can use es5-shim to make it available.

Thanks for reading!

Josh Clanton

Negating Predicate Functions in JavaScript

2015-01-22T00:00:00+00:00

While you may not have heard the term, chances are you've used predicate functions before. A predicate is essentially a function that determines whether something is true or false based on its arguments. It is common (though not necessary) for predicates to be named "isX", such as isEven or isNumber.

Suppose that we have a program which deals with cataloging comic book heroes and villains represented as simple objects:

var superman = {
    name: "Superman",
    strength: "Super",
    heroism: true
};

And as part of that program we have a number of predicates that might look something like this:

function isSuperStrong (character) {
    return character.strength === "Super";
}

function isNotSuperStrong (character) {
    return character.strength !== "Super";
}

function isHeroic (character) {
    return character.heroism === true;
}

function isNotHeroic (character) {
    return character.heroism !== true;
}

// Outputs: false
console.log(isNotSuperStrong(superman));

// Outputs: false
console.log(isNotHeroic(superman));

As you can see, this is a bit repetitive. But the problem isn't that the code is longer. Rather, the problem is that for each pair of predicates (the "is" and "isNot") we are defining our core logic twice. Having that logic repeated means we are more likely to make mistakes like updating only one of the predicates when our logic changes.

What can we do to fix that problem? Our first thought might be to do something like this:

function isSuperStrong (character) {
    return character.strength === "Super";
}

function isNotSuperStrong (character) {
    return !isSuperStrong(character);
}

function isHeroic (character) {
    return character.heroism === true;
}

function isNotHeroic (character) {
    return !isHeroic(character);
}

// Outputs: false
console.log(isNotSuperStrong(superman));

// Outputs: false
console.log(isNotHeroic(superman));

While this is certainly an improvement, we still have repetition of a different kind. Both of our "isNot" predicates share a piece of core logic. They both reverse the sense of the predicates that they are based upon.

Wouldn't it be nice if we could abstract that away into something clearer and more maintainable? Fortunately, we can.

function negate (predicateFunc) {
    return function () {
        return !predicateFunc.apply(this, arguments);
    };
}

This is another example of treating functions as first-class values in JavaScript. The negate function accepts a predicate as an argument, and returns a function whose sense is the opposite of the original predicate.

(If the usage of apply is confusing, you might want to read the previous drip on call and apply.)

Let's use negate on our original problem.

function isSuperStrong (character) {
    return character.strength === "Super";
}

var isNotSuperStrong = negate(isSuperStrong);

function isHeroic (character) {
    return character.heroism === true;
}

var isNotHeroic = negate(isHeroic);

// Outputs: false
console.log(isNotSuperStrong(superman));

// Outputs: false
console.log(isNotHeroic(superman));

Everything continues to work as expected. But now we've pulled the shared logic of the "isNot" predicates into one location. And it is much easier to tell at a glance that the definitions of the "isNot" predicates are derived from the "is" predicates.

Applied to only a couple of functions, this refactoring may not look like much. But applied to dozens of functions scattered throughout a complex system, negate can help to make things much more maintainable.

Both Underscore and Lo-Dash will include negate in future versions. It is also available right now as part of Underscore-contrib under the name complement.

Thanks for reading!

Josh Clanton

Using ECMAScript 6 Maps

2015-01-20T00:00:00+00:00

In last week's drip I discussed using Object.create(null) in order to simplify creating key-value maps in JavaScript. But even with that approach, objects aren't a substitute for a full-fledged map data type. For example:

var heroesNemesis = Object.create(null);

var greenLantern = { name: "Green Lantern" };
var sinestro = { name: "Sinestro" };

heroesNemesis[greenLantern] = sinestro;

// Outputs: { name: "Sinestro" }
console.log(heroesNemesis[greenLantern]);

var wonderWoman = { name: "Wonder Woman" };

// Outputs: { name: "Sinestro" }
console.log(heroesNemesis[wonderWoman]);

Why is our object reporting Wonder Woman's nemesis as Sinestro? In JavaScript, an object's keys can only be strings. If you try to supply something else, the JavaScript engine will try to coerce it into a string with toString.

And the default toString implementation for an object returns "[object Object]" regardless of what properties the object possesses. So unless we decide to start monkeying around with Object.prototype (generally a bad idea) our "map" object can't distinguish between different objects as keys.

Fortunately, ECMAScript 6 (the next version of JavaScript) includes a new Map data type which allows us to use any valid JavaScript value as a key.

var heroesNemesis = new Map();

var greenLantern = { name: "Green Lantern" };
var sinestro = { name: "Sinestro" };

heroesNemesis.set(greenLantern, sinestro);

// Outputs: { name: "Sinestro" }
console.log(heroesNemesis.get(greenLantern));

var wonderWoman = { name: "Wonder Woman" };

// Outputs: undefined
console.log(heroesNemesis.get(wonderWoman));

As you can see, Map gives us the result we'd expect. To use Map our main interfaces are set which accepts a key and associated value to store, and get which accepts a key and returns the associated value.

When checking to see whether a given key matches, Map uses the "same value" algorithm. So even if two objects look identical, only the original can be used to retrieve it's associated value. For example:

var clonedLantern = { name: "Green Lantern" };

// Outputs: undefined
console.log(heroesNemesis.get(clonedLantern));

And you can determine how many elements have been stored in a Map by checking its size property.

// Outputs: 1
console.log(heroesNemesis.size);

This basic set of functionality for Map is supported in the latest versions of Chrome and FireFox, as well as IE11. In future drips we'll look into more advanced features of Map.

Thanks for reading!

Joshua Clanton

Creating Objects Without Prototypes

2014-12-30T00:00:00+00:00

Last drip we talked about inheritance using prototypes and Object.create. But one point that sometimes surprises new JavaScript developers is that even ordinary "empty" objects are already part of an inheritance chain. Consider the following:

var empty = {};

// Outputs: Function Object()
console.log(empty.constructor);

Every time you create a new object via an object literal (the {}), behind the scenes JavaScript invokes the Object constructor to create the object, just as if you'd used new Object(). This is what allows your new object to inherit properties from Object.prototype.

But sometimes it would be convenient to create an object that doesn't inherit from a prototype at all. For instance, if you'd like to use an object as a hash/map of arbitrary keys to values.

var dictionary = {
    destructor: "A destructive element"
};

function getDefinition(word) {
    return dictionary[word];
}

// Outputs: "A destructive element"
console.log(getDefinition("destructor"));

// Outputs: function Object()
console.log(getDefinition("constructor"));

As you can see, our getDefinition function works perfectly for words that we have explicitly defined. However, it also returns inherited properties like constructor.

One way of solving this would be to introduce a hasOwnProperty check to make sure that the properties aren't inherited. But another way is just to ensure that our dictionary never inherits any properties to begin with.

Fortunately, Object.create makes that rather easy.

var dictionary = Object.create(null, {
    destructor: { value: "A destructive element" }
});

function getDefinition(word) {
    return dictionary[word];
}

// Outputs: "A destructive element"
console.log(getDefinition("destructor"));

// Outputs: undefined
console.log(getDefinition("constructor"));

As you can see, in this case getDefinition returned our intended result.

The trick here is in our first argument to Object.create. Normally this is where we would pass in the object that we want to serve as the prototype. But if we pass in null instead, our new object doesn't inherit from a prototype at all.

Of course, Object.create isn't available in IE8 and older, so you should only use this technique in modern browsers.

I hope you found this week's drip informative!

Joshua Clanton

Basic Inheritance with Object.create

2014-12-09T00:00:00+00:00

A few issues back we looked at how to implement basic inheritance with constructors. In this issue, we'll look at how to do the same with the newer Object.create.

When using constructors for inheritance, we attach properties to the constructor's prototype property like so:

Here's a little refresher:

function SuperHuman (name, superPower) {
    this.name = name;
    this.superPower = superPower;
}

SuperHuman.prototype.usePower = function () {
    console.log(this.superPower + "!");
};

var banshee = new SuperHuman("Silver Banshee", "sonic wail");

// Outputs: "sonic wail!"
banshee.usePower();

The SuperHuman constructor contains our initialization logic, while SuperHuman.prototype contains the methods that are shared across all SuperHuman instances.

If we were to implement the same basic logic using Object.create, it would look a bit different:

var superHuman = {
    usePower: function () {
        console.log(this.superPower + "!");
    }
};

var banshee = Object.create(superHuman, {
    name: { value: "Silver Banshee" },
    superPower: { value: "sonic wail" }
});

// Outputs: "sonic wail!"
banshee.usePower();

In this case we first define the prototype object superHuman, and then we use Object.create to make a new object which inherits from superHuman. That second argument might look a little strange to you, but it's just a simple property descriptor object, like we use with Object.defineProperty to fine-tune an object's properties.

Now, what if we want to create a new type which inherits from superHuman while adding its own functionality? What would that look like?

var superHero = Object.create(superHuman, {
    allegiance: { value: "Good" },
    saveTheDay: {
        value: function () {
            console.log(this.name + " saved the day!");
        }
    }
});

var marvel = Object.create(superHero, {
    name: { value: "Captain Marvel" },
    superPower: { value: "magic" }
});

// Outputs: "Captain Marvel saved the day!"
marvel.saveTheDay();

So far so good. But does Captain Marvel have access to the superHuman prototype methods?

// Outputs: "magic!"
marvel.usePower();

Yes, she does!

Using Object.create makes setting up inheritance chains simple because any object can be used as a prototype. However, inheritance managed by Object.create can't be detected by instanceof. Instead you'll need to use the isPrototypeOf method, like so:

// Outputs: true
console.log(superHero.isPrototypeOf(marvel));

// Outputs: true
console.log(superHuman.isPrototypeOf(marvel));

Because both superHero and superHuman are part of marvel's prototype chain, their isPrototypeOf calls each return true.

As with other JavaScript features we've reviewed, Object.create is a feature of ECMAScript 5 and is not available in older browsers like IE8.

That's our brief introduction to using Object.create. Thanks for reading!

Joshua Clanton