What Happens When You Read a Property in JavaScript

Every obj.x in JavaScript runs the same small algorithm: check the object’s own properties, then walk up the prototype chain until something answers or the chain ends. Once you can run that algorithm in your head, inheritance, getters, Object.create and most “why is this undefined?” bugs stop being mysterious. This post walks through the lookup step by step, then covers the part people get wrong: assignment does not walk the chain the same way.

Why It Matters

You use this algorithm every time you call a method. [1, 2].map is not stored on your array, it lives on Array.prototype, and JSON.stringify(user) only sees own enumerable properties. Framework internals (Vue’s reactivity, MobX, Immer), proxies, ORMs and test mocks all hook into exactly these steps. When one of them behaves strangely, the explanation is almost always in the lookup rules below.

Every Property Has a Descriptor

A property is more than a name and a value. Each one has a descriptor that says what kind of property it is and what you may do with it:

Object.getOwnPropertyDescriptor({ x: 1 }, 'x');
// { value: 1, writable: true, enumerable: true, configurable: true }

There are two kinds:

Both kinds also carry enumerable (does it show up in Object.keys, for…in and JSON.stringify?) and configurable (can it be deleted or redefined?). Properties created with plain assignment are writable, enumerable and configurable. Properties created with Object.defineProperty default to false for all three, which is a common source of “why can’t I change this?”.

An accessor runs code on every read:

let reads = 0;
const clock = {
  get now() {
    reads++;
    return Date.now();
  },
};
clock.now;
clock.now;
reads; // 2

The Lookup Algorithm

Reading obj.x (the spec calls it [[Get]]) does this:

Two details in that diagram matter in practice:

1. The search stops at the first match. A property on the object hides (shadows) any property with the same name further up.
2. Getters receive the original object as this, not the prototype that holds the getter. That is why one getter on a prototype can serve every instance.

Prototypes Are Just Objects

The prototype is an ordinary object that another object delegates to. Object.create makes the link explicit:

const animal = {
  eats: true,
  describe() {
    return `${this.name} eats: ${this.eats}`;
  },
};
 
const rabbit = Object.create(animal);
rabbit.name = 'Rabbit';
 
rabbit.describe(); // 'Rabbit eats: true'
Object.keys(rabbit); // ['name']
'eats' in rabbit; // true  (searches the chain)
Object.hasOwn(rabbit, 'eats'); // false (own properties only)

describe lives on animal, but this is rabbit, so this.name finds the own property. That is the whole trick behind methods: one function on the prototype, many objects using it. (How this gets its value is a topic of its own: see JavaScript’s this keyword, four rules and one exception.)

Classes Use the Same Machinery

class Account {
  deposit() {}
}
const account = new Account();
 
Object.getPrototypeOf(account) === Account.prototype; // true
Object.keys(Account.prototype).length; // 0: class methods are non-enumerable

new Account() creates an object whose prototype is Account.prototype, and deposit is found there. extends adds one more link: Child.prototype’s prototype is Parent.prototype.

Objects With No Prototype

Object.create(null) makes an object with no chain at all, so nothing is inherited, not even toString:

const dictionary = Object.create(null);
'toString' in dictionary; // false
'toString' in {}; // true

That makes it a safe dictionary for arbitrary keys like "__proto__" or "constructor". For most key-value data, a Map is the better tool.

Writing Is Not the Mirror of Reading

Assignment ([[Set]]) also consults the chain, but only to decide whether to create an own property:

The last two rows surprise people:

const base = Object.defineProperty({}, 'id', { value: 1, writable: false });
const item = Object.create(base);
item.id = 2; // TypeError in strict mode: the inherited id is read-only
 
Object.defineProperty(item, 'id', { value: 2 }); // defining (not assigning) works
item.id; // 2
base.id; // 1
 
const proto = {
  set name(value) {
    this._name = value.toUpperCase();
  },
};
const person = Object.create(proto);
person.name = 'ada';
Object.keys(person); // ['_name']: the setter ran, no own "name" was created

Where the Lookup Leaks Into Real Code

• for…in walks the chain; Object.keys, spread and JSON.stringify see only own enumerable properties. Prefer Object.keys or Object.entries unless you really want inherited keys.
• in vs Object.hasOwn. in answers “can I read it?”, Object.hasOwn answers “is it mine?”. Validation code usually wants the second.
• Prototype pollution. Merging untrusted JSON with a naive deep merge lets {"__proto__": {"isAdmin": true}} write to Object.prototype, and then every object “has” isAdmin.
  • Defense: reject the keys __proto__, constructor and prototype when merging, or merge into Object.create(null) or a Map.
  • Not theoretical: Lodash’s defaultsDeep had exactly this flaw (CVE-2019-10744), in a library installed millions of times a week; it was fixed in version 4.17.12.
• Performance. Engines such as V8 give objects with the same layout a shared hidden “shape” and cache lookups per shape. Create objects with the same properties in the same order, and avoid Object.setPrototypeOf on existing objects or delete in hot paths.

Going Deeper: How Engines Keep Lookups Fast

Walking a prototype chain for every property read sounds slow, yet property access in modern engines is usually a single memory load. Two ideas make that possible.

Shapes (hidden classes). An engine such as V8 doesn’t store each object as a dictionary. It gives every object a hidden shape that records which properties it has, in which order, and where each one lives in memory. Objects created the same way share a shape:

Inline caches. The first time a line like user.name runs, the engine does the full lookup and remembers the answer for that shape: “for objects of shape S2, name is at offset 1.” Next time an object of the same shape passes through, it skips the lookup entirely. A line that only ever sees one shape is monomorphic and very fast; one that sees many shapes becomes megamorphic and falls back to slower generic lookups.

What this means in practice, without micro-optimizing:

• Initialize all fields in the constructor, in the same order. Objects created through one constructor or factory then share a shape. Adding properties later, conditionally, creates many shapes.
• Avoid delete on hot objects. Deleting a property often switches the object to slow “dictionary mode”. Set the property to undefined, or use a Map for data that really changes keys.
• Don’t change prototypes after creation. Object.setPrototypeOf invalidates cached lookups for the affected objects; MDN warns that it is slow in every engine. Choose the prototype with Object.create or a class up front.
• Use Map for dictionaries. Objects are optimized for a fixed set of known keys. A Map is built for keys that come and go, such as caches and lookups by id.

These rules matter in hot paths such as rendering lists or parsing large inputs. Elsewhere, clear code wins; measure before you optimize.

Which Tool to Reach for

Test Yourself

Predict the output, then open the answer. Every answer was checked by running the code in an ES module (strict mode).

const base = { greet() { return 'hi from ' + this.name; } };
const user = Object.create(base);
user.name = 'Ada';
console.log(user.greet(), Object.keys(user), 'greet' in user);

const proto = { count: 0 };
const a = Object.create(proto);
a.count++;
console.log(a.count, proto.count, Object.hasOwn(a, 'count'));

const proto = Object.defineProperty({}, 'id', { value: 1, writable: false });
const obj = Object.create(proto);
try {
  obj.id = 2;
} catch (error) {
  console.log(error.constructor.name);
}
console.log(obj.id, Object.hasOwn(obj, 'id'));

const proto = {
  set name(value) {
    this._name = value.toUpperCase();
  },
};
const o = Object.create(proto);
o.name = 'ada';
console.log(o._name, Object.keys(o));

const parent = { inherited: 1 };
const child = Object.create(parent);
child.own = 2;
const seen = [];
for (const key in child) seen.push(key);
console.log(seen, Object.keys(child), JSON.stringify(child));

class Widget {
  render() {}
  onClick = () => {};
}
const a = new Widget();
const b = new Widget();
console.log(a.render === b.render, a.onClick === b.onClick, Object.keys(a));

Key Takeaways

Want to test yourself? The JavaScript round of “What does this print?” has several puzzles built on these rules. The next post in this series looks at the other half of the object model: the hidden cost of mutable state.

Sources

• Mathias Bynens and Benedikt Meurer: JavaScript engine fundamentals: Shapes and Inline Caches
• MDN: Object.setPrototypeOf()
• ECMAScript specification: OrdinaryGet and OrdinarySet
• MDN: Inheritance and the prototype chain
• MDN: Object.defineProperty()
• V8 blog: Fast properties in V8
• Snyk: Prototype pollution