Object.create & null-prototype objects

Choose the prototype link up front

In the last few lessons, you saw that an object can have a prototype. A prototype is a second object that JavaScript checks when the first object doesn't have a property. This lesson shows how to pick that prototype yourself.

Object.create(proto) makes a new, empty object whose prototype is proto. It doesn't call a constructor function. It doesn't copy any properties from proto into the new object. It only adds a link.

JavaScript looks up a property in the same order. First it checks the object itself. Then it checks the prototype, then the prototype's prototype, and so on, until the chain of links ends.

Sometimes you want the opposite: an object with no prototype at all. This is called a null-prototype object. It holds only the keys you put in it. It has no inherited extras such as toString, constructor, or hasOwnProperty. That makes it a safe dictionary: an object used as a lookup table from keys to values. This ties in with Map & Set, Choosing a data structure, and JSON.

Object.create needs one argument: the object to use as the prototype, or null for none. It returns a new object. The new object keeps a hidden link to that prototype. The specification calls this link [[Prototype]]. The double square brackets mean your code can't read it as a normal property.

const animal = { eats: true };
const rabbit = Object.create(animal);
console.log(rabbit.eats);
console.log(Object.hasOwn(rabbit, "eats"));

Line by line:

• Line 1 makes animal, which owns eats.
• Line 2 makes rabbit and links it to animal. Nothing is copied.
• Line 3 prints true. rabbit has no eats of its own, so JavaScript follows the link and finds it on animal.
• Line 4 prints false. Object.hasOwn(obj, key) asks, "Does obj itself hold this key?" It ignores the prototype, and rabbit holds nothing.

Object.create also takes an optional second argument: the properties to add to the new object. Each property is described by a property descriptor. A descriptor is a small object that says what the property holds and what you may do with it. Object.defineProperties uses the same format. A descriptor can have these parts:

• value: the value the property holds.
• writable: can you change the value later?
• enumerable: does the property show up in lists, such as the one Object.keys gives?
• configurable: can you delete the property or change its parts later?

The last three are yes-or-no flags. Any flag you leave out is false. This surprises many people.

The step-through below uses a bigger example. Its first line, "use strict", turns on strict mode: a set of stricter rules. In strict mode, some mistakes that would fail quietly throw an error instead. Line 9 sets enumerable: true, so name shows up in Object.keys. It leaves writable out, so at first name can't be changed.

1"use strict";2const base = {Run3  greet() {4    return "hi from base";5  },6};7 8const child = Object.create(base, {9  name: { value: "Kid", enumerable: true },10});11 12console.log(child.greet());13console.log(Object.getPrototypeOf(child) === base);14console.log(base.isPrototypeOf(child));15try {16  child.name = "Ada";17} catch (error) {18  console.log(error.name);19}20console.log(child.name);

What each part of the run shows:

• Line 8 makes child, already linked to base. Line 9 gives it its own name property.
• Line 12 calls child.greet(). child doesn't own greet, so JavaScript follows the link and runs the method from base. It prints hi from base. So the method was not copied.
• Line 13 checks the link from the child's side. Object.getPrototypeOf(child) returns the prototype of child. That is base, so it prints true.
• Line 14 checks the link from the other side. base.isPrototypeOf(child) asks, "Is base anywhere in the chain of prototypes behind child?" It prints true.
• Line 16 tries to change name. writable was left out, so it is false. In strict mode, the change throws a TypeError, and line 18 prints the error's name. Line 20 prints Kid: the value never changed.

Pick the writable descriptor and step again. Now line 16 changes name, and line 20 prints Ada.

const base = { label: "shared" };
const child = Object.create(base, {
  name: { value: "Asha", enumerable: true },
});
const descriptor = Object.getOwnPropertyDescriptor(child, "name");
console.log(descriptor.value);
console.log(descriptor.writable);
console.log(descriptor.enumerable);
console.log(descriptor.configurable);

Object.getOwnPropertyDescriptor(obj, key) gives back the descriptor of one property that obj owns. Use it to see the flags instead of guessing:

• Line 5 reads the descriptor of name.
• Line 6 prints the value, Asha.
• Line 7 prints false. writable was left out, so it is false.
• Line 8 prints true. Line 3 set enumerable: true.
• Line 9 prints false. configurable was left out too.

If you want to change or delete a property later, set all three flags yourself.

const animal = { eats: true };
const rabbit = Object.create(animal);
rabbit.eats = false;
console.log(rabbit.eats);
console.log(animal.eats);
console.log(Object.hasOwn(rabbit, "eats"));

Line 3 writes to rabbit.eats. Writing a property doesn't change the prototype. Instead, JavaScript adds a new eats property to rabbit itself. This own eats now hides the one on animal. Hiding an inherited property like this is called shadowing. The output:

• Line 4 prints false: the value on rabbit.
• Line 5 prints true: animal didn't change.
• Line 6 prints true: rabbit now owns eats.

const profile = Object.create(null, {
  name: { value: "Asha" },
});
console.log(Object.keys(profile));
profile.name = "Mina";
console.log(profile.name);

The descriptor on line 2 sets only a value, so all three flags are false. This code has no "use strict" line, so it runs with the older, looser rules, often called sloppy mode:

• Line 4 prints [], an empty list. Object.keys lists only enumerable properties, and name is not enumerable.
• Line 5 tries to change name. It is not writable, so nothing happens, and no error is shown.
• Line 6 prints Asha. The value didn't change.

In strict mode, line 5 would throw a TypeError instead, as the step-through above showed.

Three built-in functions read or change the link of an object that already exists:

• Object.getPrototypeOf(obj) returns the prototype of obj. This is the standard way to look at the link.
• Object.setPrototypeOf(obj, proto) makes proto the new prototype of obj, then returns obj. If the change isn't allowed, it throws an error.
• Reflect.setPrototypeOf(obj, proto) makes the same change. Instead of throwing, it returns true if the change worked and false if it didn't. Reflect is a built-in object that holds these lower-level versions of object operations.

Some links are not allowed:

• You can set the prototype to null. The chain then ends at that object.
• You can't make a loop. Object.setPrototypeOf(a, a) would make a its own prototype, so it throws a TypeError. In Node and Chrome the message is Cyclic __proto__ value. "Cyclic" means "going round in a circle".
• Some objects don't allow a new prototype. A frozen object, made with Object.freeze, is locked against changes. Reflect.setPrototypeOf returns false for it.

1const toolbox = { label: "toolbox", find() { return "from toolbox"; } };2const archive = { label: "archive", find() { return "from archive"; } };3const item = { name: "receipt" };4 5console.log(item.find?.());6Object.setPrototypeOf(item, toolbox);7console.log(item.find());8console.log(Object.getPrototypeOf(item).label);9console.log(Reflect.setPrototypeOf(Object.freeze({}), archive));10try {11  Object.setPrototypeOf(item, item);12} catch (error) {13  console.log(error.name + ": " + error.message);14}

Why use it rarely? The JavaScript engine is the program inside the browser (or Node) that runs your code. It learns where each object keeps its properties, so it can find them fast. Changing an object's prototype later throws away what it learned. Code that uses that object can then run slower.

A normal object, such as {}, has Object.prototype as its prototype. That is usually helpful. It gives every object methods such as toString and hasOwnProperty.

But sometimes you use an object as a dictionary, and the keys come from data you don't control, such as words a user types. Then the inherited names get in the way. Even before you add anything:

• "toString" in {} is already true. The in operator checks the object and its prototypes.
• Reading ({}).toString gives a function, not undefined.

Object.create(null) makes an object with no prototype. So it has none of these inherited names: no constructor, no toString, and no hasOwnProperty. A key such as "constructor" or "__proto__" is just a normal key there.

You can still turn it into JSON. JSON.stringify reads only the object's own enumerable properties, so it doesn't need Object.prototype.

const dict = Object.create(null);
dict.apple = 2;
dict.constructor = 1;
console.log(typeof dict.toString);
console.log(typeof dict.hasOwnProperty);
console.log(Object.hasOwn(dict, "constructor"));
console.log(Object.entries(dict));

Line by line:

• Line 1 makes the dictionary, with no prototype.
• Lines 2 and 3 add two keys, apple and constructor.
• Lines 4 and 5 print undefined. typeof gives the type of a value as text. Neither method exists here, because nothing is inherited.
• Line 6 prints true. Object.hasOwn is a function on Object itself, not a method of the dictionary, so it still works.
• Line 7 prints the two key-value pairs. Object.entries is also a function on Object.

So, to look inside a null-prototype dictionary, use functions on Object, such as Object.hasOwn, Object.keys, and Object.entries.

1const keys = ["toString", "__proto__", "constructor", "hasOwnProperty", "apple"];2 3const plain = {};4const dict = Object.create(null);5const map = new Map();6 7for (const key of keys) {8  const value = key === "__proto__" ? { polluted: true } : "value:" + key;9  plain[key] = value;10  dict[key] = value;11  map.set(key, value);12}13 14console.log(typeof ({}).toString);15console.log(plain.polluted);16console.log(Object.hasOwn(plain, "__proto__"));17console.log(dict["__proto__"]);18console.log(typeof Object.create(null).hasOwnProperty);19console.log(JSON.stringify(dict));

The table compares three ways to store keys and values. Each row is one choice: when it fits best, and what to watch out for.

In the Choosing a data structure lesson, Object.groupBy returned a null-prototype object. That was on purpose. The group names come from data, and data might contain the word "constructor". A later lesson, Prototype pollution, covers the security side. For now, keep one habit: don't let keys from data turn into inherited behavior.

Prototype performance: keep links stable

This lesson doesn't give speed numbers. A small speed test, called a benchmark, often measures how the engine warms up, not how your real page behaves. But the advice is clear:

• MDN and the teams who build engines say that changing a prototype after an object is made is slow. That covers both Object.setPrototypeOf and assigning to __proto__.
• Long prototype chains also cost time. Each missing property can mean one more link to check.

Where you’ll use this

Most everyday code uses object literals, classes, and Map. You reach for Object.create when the link itself is what you want. For example:

• an object that hands some of its work to another object,
• a stand-in object for tests that gets its default behavior from a real one,
• small parts inside libraries and frameworks,
• dictionaries with no inherited keys.

class User {
  greet() { return "hello " + this.name; }
}
function UserRecord(name) {
  this.name = name;
}
UserRecord.prototype.greet = function () {
  return "hello " + this.name;
};
function makeUser(name) {
  return Object.create(UserRecord.prototype, {
    name: { value: name, writable: true, enumerable: true, configurable: true },
  });
}
const classUser = new User();
classUser.name = "Asha";
const constructorUser = new UserRecord("Asha");
const linkedUser = makeUser("Asha");
console.log(classUser.greet());
console.log(constructorUser.greet());
console.log(linkedUser.greet());
console.log(Object.getPrototypeOf(linkedUser) === UserRecord.prototype);

Three objects, one result:

• Lines 1 to 3: the class User puts greet on User.prototype. Line 15 makes classUser with new User(), so it is linked to User.prototype.
• Lines 4 to 9: the constructor function UserRecord works the same way. Line 7 puts greet on UserRecord.prototype by hand. Line 17 makes constructorUser with new.
• Lines 10 to 14: makeUser calls Object.create with UserRecord.prototype as the prototype. Line 18 makes linkedUser this way, without new.
• Lines 19 to 21 each print hello Asha. Line 22 prints true: linkedUser has the same prototype that new UserRecord() gives.

Use a class or a constructor when you make many objects of the same kind. Use Object.create when you want to link one object straight to another, or set the property flags yourself.

const animal = { eats: true };
const rabbit = Object.create(animal, {
  name: { value: "Bun", writable: true, enumerable: true },
});
const clone = Object.create(
  Object.getPrototypeOf(rabbit),
  Object.getOwnPropertyDescriptors(rabbit),
);
const spread = { ...rabbit };
console.log(clone.name);
console.log(Object.getPrototypeOf(clone) === animal);
console.log(Object.getOwnPropertyDescriptor(clone, "name").writable);
console.log(Object.getPrototypeOf(spread) === animal);

The code makes two copies of rabbit:

• Lines 5 to 8 make clone. Object.getPrototypeOf(rabbit) gives the same prototype, animal. Object.getOwnPropertyDescriptors(rabbit) gives the descriptors of all the properties rabbit owns, flags included.
• Line 9 makes spread with { ...rabbit }. The spread syntax ... copies the own enumerable values into a new plain object.

The output:

• Lines 10 to 12 print Bun, true, and true. clone has the same name, the same prototype, and the same writable flag.
• Line 13 prints false. spread got the usual Object.prototype, not animal.

Both are shallow copies. If a property held another object, both copies would point to that same inner object.

1function countWords(words) {2  const counts = Object.create(null);3  for (const word of words) {4    counts[word] = (counts[word] || 0) + 1;5  }6  return counts;7}8console.log(countWords(["constructor", "constructor"]).constructor);

The word "constructor" is a well-known trap. Suppose line 2 made a plain {}. Then counts.constructor would already hold an inherited function before any word is counted. So (counts[word] || 0) + 1 on line 4 wouldn't start from 0. It would turn the function into text and stick 1 on the end, so the count becomes strange text instead of a number.

Line 2 uses Object.create(null) instead. The dictionary starts truly empty, with only the keys you add, so line 7 prints 2.

The next lesson, Delegation vs classical inheritance, builds on this. It shows a style called OLOO, short for "objects linked to other objects". OLOO uses Object.create to link objects straight to each other, instead of copying behavior down a family tree of classes.

Common misconceptions

Answer each question, then read why each choice is right or wrong.

Key takeaways

• Object.create(proto) makes a new object linked to proto. It doesn't copy anything.
• Its second argument takes property descriptors. Any flag you leave out (writable, enumerable, configurable) is false.
• Object.getPrototypeOf reads the link. Object.setPrototypeOf changes it, but that is slow, so use it rarely.
• Object.create(null) makes a dictionary with no prototype: no inherited toString, constructor, or hasOwnProperty.
• When keys come from data, use Object.hasOwn, Object.entries, or a Map.

Up next: Delegation vs classical inheritance.