__proto__ vs .prototype

## Two names, two different things Every JavaScript object carries an internal slot the specification writes as `[[Prototype]]`. It holds either another object or `null`, and it is the link the engine follows when a property is not found on the object itself. You read it with `Object.getPrototypeOf(obj)`; `obj.__proto__` is an older accessor that reaches the same slot. `.prototype` is something else entirely: an ordinary, visible property that lives on **functions**, not on ordinary objects. It holds a plain object that the function hands out. When the function is called with `new`, the newly created object's `[[Prototype]]` is set to whatever `F.prototype` references at that moment. The one-line version: `.prototype` is what a function **gives** to the objects it creates; `[[Prototype]]`/`__proto__` is what an object **has**. ```js function Dog(name) { this.name = name; } Dog.prototype.speak = function () { return this.name + ' barks'; }; const d = new Dog('Rex'); Object.getPrototypeOf(d) === Dog.prototype; // true d.speak(); // 'Rex barks' d.prototype; // undefined — d is not a function ``` ## The function has both, and they are unrelated objects `Dog` is itself an object, so it has its own `[[Prototype]]` link — and because it is a function, that link points at `Function.prototype`. Separately, it owns a `.prototype` property pointing at the object `d` delegates to. These are two different objects that happen to hang off the same function: ```js Object.getPrototypeOf(Dog) === Function.prototype; // true — Dog's own link Dog.prototype === Function.prototype; // false — the instance prototype ``` Mixing these two up is the classic mistake. `Dog.__proto__` answers "what does the function `Dog` inherit from?" (methods like `call`, `apply`, `bind`). `Dog.prototype` answers "what will `new Dog()` inherit from?" (`speak`). ## What `.prototype` starts out as For a normal function declaration or expression, the engine creates the `.prototype` object for you: a fresh plain object whose own `constructor` property points back at the function, and whose own `[[Prototype]]` is `Object.prototype`. The property is writable but non-enumerable and non-configurable, which is why you can assign to it and why it never shows up in a `for...in` over the function. ```js function Dog() {} Dog.prototype.constructor === Dog; // true Object.getPrototypeOf(Dog.prototype) === Object.prototype; // true ``` Because instances share that one object, methods put on `.prototype` exist once in memory regardless of how many instances you create — the reason prototype methods are preferred over assigning a fresh function to `this.speak` in the constructor body. ## Reassigning `.prototype` later `.prototype` is read at creation time, and the resulting link is a snapshot. Replacing the function's `.prototype` afterwards does not retroactively change objects that already exist: ```js function Dog() {} const before = new Dog(); Dog.prototype = { speak: () => 'new proto' }; const after = new Dog(); Object.getPrototypeOf(before) === Dog.prototype; // false — kept the old object Object.getPrototypeOf(after) === Dog.prototype; // true ``` *Mutating* the existing `.prototype` object (`Dog.prototype.speak = ...`) is different — every instance already points at that object, so all of them see the change immediately. ## Where classes fit `class C {}` produces exactly the same arrangement: `C` is a function, `C.prototype` holds the instance methods, and `new C()` links the instance to `C.prototype`. The difference is that a class's `.prototype` property is non-writable, so you cannot reassign it wholesale. ## What to say and what to write In conversation, say `[[Prototype]]` or "the object's prototype link" for what an object has, and "the function's `.prototype` property" for what a function exposes. In code, prefer `Object.getPrototypeOf(obj)` over `obj.__proto__`: the former is a plain core-spec function that works on any object, while `__proto__` is a legacy accessor that only exists because the object inherits it from `Object.prototype`.