Why is `__proto__` considered legacy in JavaScript, and which standard APIs replace reading and writing it?

## Where `__proto__` came from `__proto__` was never designed as part of the core language. Browsers shipped it as a convenient way to expose the internal `[[Prototype]]` slot, code came to depend on it, and when the committee could no longer remove it they documented it in the annex of web-compatibility features — the part of the specification marked *normative optional*, meaning a conforming engine outside a web browser is allowed not to have it. Every major engine does implement it, but its status is "we are stuck with this", not "this is the way". The core-language replacements are ordinary functions: ```js Object.getPrototypeOf(obj); // ES5 — read the link Object.setPrototypeOf(obj, someProto); // ES2015 — write the link (returns obj) ``` ## It is an inherited accessor, not a slot This is the mechanical detail that matters. `__proto__` is a single accessor property — a getter/setter pair — defined on `Object.prototype`. When you write `obj.__proto__`, ordinary property lookup walks up to `Object.prototype`, finds the getter, and calls it with `obj` as the receiver; the getter returns that object's internal prototype link. Assignment calls the setter. Everything follows from that. If an object does **not** inherit from `Object.prototype`, the accessor is simply not in its chain, so: ```js const bag = Object.create(null); bag.__proto__; // undefined — no getter anywhere in the chain bag.__proto__ = { x: 1 }; // creates an ordinary own data property! Object.getPrototypeOf(bag); // still null — the prototype did not change ``` On such an object `__proto__` is just a string key like any other. `Object.getPrototypeOf` has no such hole: it reads the internal slot directly, whatever the object's chain looks like. ## The name is magic, and that is a hazard Because `__proto__` is a property *name* rather than syntax, any code that takes keys from data and assigns them can trip the setter by accident: ```js function merge(target, source) { for (const key of Object.keys(source)) target[key] = source[key]; return target; } merge({}, JSON.parse('{"__proto__": {"admin": true}}')); ``` The parse itself is safe: `JSON.parse` defines own properties directly rather than going through setters, so the result is a plain object with an own key literally named `__proto__`. The danger is the copy loop — `target[key] = value` is a normal assignment, which finds the inherited setter and changes `target`'s prototype instead of storing data. If the target is shared, or if the same pattern is applied to an object whose prototype is `Object.prototype` itself, effects can reach far beyond the one call. Guarding the key explicitly (skipping `__proto__`, or using `Object.defineProperty`, `Object.hasOwn`, or a `Map`) is the fix; using `Object.setPrototypeOf` where you *do* mean to change a prototype makes the intent visible. ## Reading versus writing The two directions differ in cost as well as in style. `Object.getPrototypeOf` is a cheap read. Writing — whether through `Object.setPrototypeOf` or the `__proto__` setter — mutates an object's shape after creation and is expensive in every major engine, so it is something to avoid in hot code regardless of which spelling you use. Writes also have real failure modes worth knowing: ```js const fixed = Object.preventExtensions({}); Object.setPrototypeOf(fixed, { a: 1 }); // TypeError — not extensible Object.setPrototypeOf({}, null); // fine — null is a valid prototype ``` ## What to write in review Use `Object.getPrototypeOf` and `Object.setPrototypeOf` in code you own. Treat a bare `obj.__proto__` in a diff as either legacy or a bug, and treat `'__proto__'` appearing as a *data* key as a signal to check every place that key can flow into an assignment. The one place `__proto__` still reads naturally is a quick console inspection, where its brevity is the whole point and nothing is being shipped.