In JavaScript, what does the engine do when you read `obj.x` and `x` is not an own property of `obj`, and what does the assignment `obj.x = 1` do instead?

## The mental model Every JavaScript object holds an internal link to another object or to `null` — its **[[Prototype]]**, readable with `Object.getPrototypeOf(obj)`. That link is a live reference, not a copy: nothing is duplicated into the object when it is created. Property access is therefore resolved dynamically, on every access, by walking that chain of links. The single most useful fact about the chain is that **reads walk it and writes normally do not**. ## The read path `obj.x` performs the internal [[Get]] operation. The engine asks whether `obj` has an own property named `x`. If yes, it uses it and stops. If not, it moves to `Object.getPrototypeOf(obj)` and repeats. The walk ends either at the first object that owns the name — the first match wins, deeper links are never consulted — or when the chain reaches `null`. If the walk ends without a match, the result is `undefined`. This is a common trip-up: an absent property is not an error, so a typo in a property name is silent. (An undeclared *variable* is different — that throws a `ReferenceError` — but a missing property never does.) ```js const proto = { greet() { return 'hi'; } }; const obj = Object.create(proto); obj.greet(); // 'hi' — found one link up obj.nothing; // undefined — walk hit null ``` One subtlety: if the property found on a prototype is an accessor, its getter runs with `this` bound to the object the access *started* from, not the prototype that owns the getter. That is what makes shared methods work at all — a method living on `Ctor.prototype` sees the instance as `this`. ## The write path `obj.x = 1` performs [[Set]] with `obj` as the **receiver**. In the ordinary case, the engine creates an own data property on the receiver, with `writable`, `enumerable` and `configurable` all true. The prototype is never modified. If `obj` already has its own `x`, only that own value is updated. ```js const proto = { count: 0 }; const a = Object.create(proto); const b = Object.create(proto); a.count = 5; a.count; // 5 — own property b.count; // 0 — still reads the prototype proto.count; // 0 — untouched Object.hasOwn(a, 'count'); // true Object.hasOwn(b, 'count'); // false ``` This is **shadowing**: `a` now owns a `count` that hides the inherited one. Since the own property is created fresh, it does not inherit the prototype property's attributes. ## Where the write path does consult the chain The write is not entirely blind to the prototype. Before creating the own property, [[Set]] walks the chain looking for an existing property of that name, and three cases divert it: - The chain has an **accessor with a setter** — the setter is called with `this` set to the receiver, and no own property is created. - The chain has an **accessor with only a getter** — the assignment fails: silently in sloppy mode, with a `TypeError` in strict mode (which includes all module and class code). - The chain has a **non-writable data property** — same outcome: ignored in sloppy mode, `TypeError` in strict mode. `Object.defineProperty(obj, 'x', { value: 1 })` bypasses all of that; it always defines directly on the target and never triggers an inherited setter. ## Un-shadowing with delete Because the own property and the inherited one are separate, removing the own property reveals the prototype's again: ```js delete a.count; // removes only a's own property a.count; // 0 — the inherited value is visible again ``` `delete` never removes an inherited property; to change that you must delete it from the object that actually owns it. ## Why it matters day to day The read/write asymmetry explains the classic bug where mutable state placed on a prototype looks shared for some operations and private for others: mutating through the inherited reference touches the one shared object, while assigning to the name creates a private copy on the instance. It also explains why checking membership needs the right tool — `'x' in obj` is true for inherited names, while `Object.hasOwn(obj, 'x')` is true only for own ones — and why data objects coming from outside the program should be checked with own-property tests rather than plain truthiness. Per-instance state therefore belongs on the instance: assigned in the constructor, or declared as a class field, which is defined on each instance rather than on the prototype. Shared *behaviour* — methods — belongs on the prototype, where sharing is exactly what you want.