Objects & Prototypes

A JavaScript object is two things: a set of own properties (key → value pairs stored on the object itself) and one hidden link, [[Prototype]], to another object it falls back to when a key is missing. Every way of creating an object is really answering two questions: what own properties does it start with, and what does its prototype link point to?

That's the mental model to carry through this whole chapter. An object literal links to Object.prototype. Object.create(x) links to whatever x you pass. new Fn() links to Fn.prototype. A class does the same as new Fn() with nicer syntax. A factory function just returns a literal. Once you see the six forms below as "different ways of setting that one link", they stop feeling like six unrelated features.

// 1. Object literal — the everyday way
const person = { firstName: "John", lastName: "Doe", age: 50 };

// 2. Object constructor — same result, more typing
const p2 = new Object();
p2.firstName = "John";

// 3. Object.create — choose the prototype explicitly
const personProto = {
  greet() {
    console.log(`Hello, my name is ${this.name} and I'm ${this.age}.`);
  },
};
const p3 = Object.create(personProto);
p3.name = "John";
p3.age = 30;
p3.greet(); // Hello, my name is John and I'm 30.

// 4. Constructor function + new
function Person(name) {
  this.name = name;
}
const p4 = new Person("Alice");

// 5. ES2015 class (sugar over 4)
class PersonClass {
  constructor(name) {
    this.name = name;
  }
}

// 6. Factory function — no `new`, no `this`
const createPerson = (name) => ({ name, greet: () => `Hi ${name}` });

A method is just a property whose value is a function. There's no separate "method" type: what makes it feel like a method is calling it with a dot, obj.greet(), which sets this to obj for that call. Both syntaxes below give you a property holding a function, and both get this from the call site. They differ in two small but interview-worthy ways.

const obj = {
  // 1. Method shorthand — has its own `this`, can use `super`
  greet() {
    return `Hi ${this.name}`;
  },
  // 2. Property holding a function
  greet2: function () {
    return `Hi ${this.name}`;
  },
  // (an arrow function here would NOT get `this` — see the `this` chapter)
  name: "Rohit",
};

const base = { hello() { return "base hello"; } };
const child = {
  __proto__: base, // in a literal, this sets the prototype
  hello() {
    return `child → ${super.hello()}`;
  },
};
child.hello(); // "child → base hello"

new obj.greet2(); // greet2 {} — an ordinary function can be a constructor
new obj.greet();  // TypeError: obj.greet is not a constructor

Square brackets in an object literal make the key an expression that's evaluated to produce the property name.

Before ES2015 you had to build the object first and then add a dynamic key on a second line (obj[key] = value). Computed keys let you do it inside the literal, which matters most when you're returning a new object in one expression — reducers, state updates, building lookups. The expression in the brackets can be anything: a variable, a template literal, a function call. Its result is then turned into a property key: symbols stay symbols, and every other value is converted to a string.

const field = "email";
const id = 3;

const form = {
  [field]: "a@b.com",          // email: "a@b.com"
  [`item_${id}`]: true,        // item_3: true
  [Symbol.iterator]: function* () {}, // symbol keys must use brackets
};

// Handy for updating state by input name
const update = (state, e) => ({ ...state, [e.target.name]: e.target.value });

const a = { id: 1 };
const b = { id: 2 };
const lookup = { [a]: "first", [b]: "second" };

Object.keys(lookup); // ["[object Object]"] — both keys became the same string
lookup[a];           // "second"

Every object has a hidden link, [[Prototype]], to another object (or null). When you read a property that the object doesn't have, JavaScript walks up this chain until it finds it or hits null. That's prototypal inheritance: objects inherit directly from other objects.

Think of it as asking a series of people: "Do you have greet?" The object asks itself first; if it doesn't have the key, it asks its prototype, then that object's prototype, and so on. The first object that has the key answers. If nobody has it and the chain ends at null, the answer is undefined. Nothing is copied — instances keep a reference to the prototype, so a method added to the prototype later is immediately visible to every existing instance.

This lookup only applies to reading. Writing a property (obj.x = 1) normally creates or updates an own property on obj itself and never touches the prototype — see Shadowing prototype properties.

function Person(name) {
  this.name = name; // own property — one per instance
}
Person.prototype.greet = function () { // shared — one copy for all instances
  console.log("Hello, " + this.name);
};

const alice = new Person("Alice");
alice.greet();                  // found on Person.prototype
alice.toString();               // found on Object.prototype
alice.fly;                      // undefined — reached null

Object.getPrototypeOf(alice) === Person.prototype;      // true
Object.getPrototypeOf(Person.prototype) === Object.prototype; // true
Object.getPrototypeOf(Object.prototype);                // null

If you define a method inside the constructor, every instance gets its own copy. Put it on the prototype and all instances share one.

The constructor body runs once per new, so anything it creates — including a function expression — is created again for every instance. The prototype object is created once, when the constructor function is defined, so anything you put there exists exactly once.

function Bad(name) {
  this.name = name;
  this.greet = function () {}; // new function per instance ❌
}
function Good(name) {
  this.name = name;
}
Good.prototype.greet = function () {}; // shared ✅

new Bad("a").greet === new Bad("b").greet;   // false
new Good("a").greet === new Good("b").greet; // true

They're easy to mix up:

The way to keep them apart: prototype is a normal property that only functions have, and it's a blueprint for future instances. It says nothing about the function's own parent. __proto__ reads the actual link of whatever object you call it on. So Dog.prototype is "what Dog's instances will inherit from", while Dog.__proto__ is "what Dog itself inherits from" — and since Dog is a function, that's Function.prototype.

function Dog() {}
const rex = new Dog();

rex.__proto__ === Dog.prototype;        // true
Dog.prototype.constructor === Dog;      // true
Dog.__proto__ === Function.prototype;   // true — Dog is itself a function object
rex.prototype;                          // undefined — instances don't have one

function F() {}
const a = new F();
F.prototype = { x: 1 };
const b = new F();

console.log(a.x, b.x);
console.log(a instanceof F, b instanceof F);

new is not magic — it's four steps you could write yourself, and interviewers like to ask you to. Writing it out is the clearest way to see how a constructor, its prototype property and the resulting instance are connected:

• Create a new empty object.
• Link its [[Prototype]] to Constructor.prototype.
• Run the constructor with this set to the new object, so this.x = … adds own properties.
• Return the new object — unless the constructor explicitly returned a different object.

function myNew(Constructor, ...args) {
  // 1. Create an empty object linked to Constructor.prototype
  const obj = Object.create(Constructor.prototype);
  // 2. Run the constructor with `this` = the new object
  const result = Constructor.apply(obj, args);
  // 3. If the constructor returned an object, use that; otherwise use obj
  return result !== null && (typeof result === "object" || typeof result === "function") ? result : obj;
}

const a = myNew(Person, "Alice");
a instanceof Person; // true

function myInstanceOf(obj, Constructor) {
  if (obj === null || (typeof obj !== "object" && typeof obj !== "function")) return false;
  let proto = Object.getPrototypeOf(obj);
  while (proto !== null) {
    if (proto === Constructor.prototype) return true;
    proto = Object.getPrototypeOf(proto);
  }
  return false;
}

myInstanceOf(a, Person); // true
myInstanceOf(a, Object); // true
myInstanceOf(a, Array);  // false
myInstanceOf(5, Number); // false — same as 5 instanceof Number

function R1() {
  this.a = 1;
  return { b: 2 };
}
function R2() {
  this.a = 1;
  return 42;
}

console.log(new R1());
console.log(new R2());

Before class, inheritance took two steps: call the parent constructor for the own properties, and link the prototypes for the shared methods.

These are two separate problems, which is why there are two steps. Own properties (name, breed) are created by running constructor code against the new object, so the child must run the parent's constructor on its this. Shared methods (eat, bark) live on prototype objects, so the child's prototype must link to the parent's prototype to make the chain instance → Dog.prototype → Animal.prototype → Object.prototype. class … extends does both for you, but it's the same structure underneath.

function Animal(name) {
  this.name = name;
}
Animal.prototype.eat = function () {
  return `${this.name} is eating`;
};

function Dog(name, breed) {
  Animal.call(this, name); // 1. inherit own properties ("super(name)")
  this.breed = breed;
}

// 2. inherit methods
Dog.prototype = Object.create(Animal.prototype);
Dog.prototype.constructor = Dog; // repair the constructor pointer

Dog.prototype.bark = function () {
  return "Woof!";
};

const d = new Dog("Rex", "Lab");
d.eat();               // "Rex is eating"
d instanceof Animal;   // true

class Animal {
  constructor(name) { this.name = name; }
  eat() { return `${this.name} is eating`; }
}
class Dog extends Animal {          // links Dog.prototype → Animal.prototype
  constructor(name, breed) {
    super(name);                    // runs Animal's constructor on this object
    this.breed = breed;
  }
  bark() { return "Woof!"; }
}

A "static" method lives on the constructor itself, not on instances.

A function is an object, so you can hang properties on it like any other object. That's all a static method is: a property of the constructor function. Instances can't see it because their chain goes through User.prototype, not through User. Statics are for things that belong to the type rather than to one object: factory methods (fromJSON, Array.from), validators (Number.isInteger), and constants.

function User(name) {
  this.name = name;
}
User.fromJSON = function (json) {   // static
  return new User(JSON.parse(json).name);
};
User.prototype.hello = function () { // instance
  return `Hi ${this.name}`;
};

const u = User.fromJSON('{"name":"Rohit"}');
u.hello();     // "Hi Rohit"
u.fromJSON;    // undefined — statics aren't inherited by instances

Assigning a property on an instance creates an own property that hides (shadows) the prototype's one. The prototype is untouched.

This is the read/write asymmetry of the prototype chain. Reading walks the chain; writing doesn't. obj.x = value doesn't go looking for an existing x up the chain to update — it puts x directly on obj. From then on, reads of obj.x stop at the own property and never reach the prototype's value. It's like writing your own phone number on a sticky note over the company directory: you see yours, everyone else still sees the directory.

function Car() {}
Car.prototype.wheels = 4;

const trike = new Car();
trike.wheels = 3;       // own property — shadows the prototype
const sedan = new Car();

trike.wheels;           // 3
sedan.wheels;           // 4
delete trike.wheels;
trike.wheels;           // 4 again — the prototype shows through

const proto = {};
Object.defineProperty(proto, "x", { value: 1, writable: false });
const child = Object.create(proto);
child.x = 2;   // silently ignored (TypeError in strict mode)
child.x;       // 1 — no own property was created

const proto2 = {
  set y(v) { console.log("setter ran with", v); },
};
const c2 = Object.create(proto2);
c2.y = 5;                 // logs "setter ran with 5"
Object.hasOwn(c2, "y");   // false

Because reads walk the prototype chain, "does this object have x?" has two meanings: does it have x itself (an own property), or can it reach x somewhere on its chain? Different checks answer different questions, and mixing them up is a common source of bugs — especially with user-supplied keys.

const obj = { a: 1 };
Object.prototype.c = 3; // inherited (never do this in real code!)

Object.hasOwn(obj, "a"); // true
Object.hasOwn(obj, "c"); // false
"c" in obj;              // true — `in` walks the chain
"toString" in obj;       // true

for...in loops over enumerable string keys, including inherited ones. Filter with Object.hasOwn if you only want the object's own keys.

for...in is one of the oldest features in the language and it reflects the prototype model directly: it walks the same chain a property read does and reports every enumerable string key it meets on the way — own keys first, then the prototype's, and so on up. Built-in methods like toString don't show up because they're defined as non-enumerable (see Property descriptors); anything added by plain assignment does.

const obj = { a: 1, b: 2, c: 3 };

for (const key in obj) {
  if (Object.hasOwn(obj, key)) {   // note: Object.hasOwn, not obj.hasOwn
    console.log(`${key}: ${obj[key]}`);
  }
}

const base = { inherited: true };
const child = Object.create(base);
child.own = 1;

for (const key in child) console.log(key); // "own", then "inherited"
Object.keys(child);                        // ["own"]

for (const [key, value] of Object.entries(obj)) {
  console.log(key, value);
}

Objects don't have map or filter — those live on Array.prototype. These four static methods are the bridge: keys, values and entries turn an object's own enumerable string-keyed properties into arrays, you use the array methods you already know, and fromEntries turns the result back into an object. Think of entries and fromEntries as a round trip: object → list of pairs → object.

const prices = { apple: 1, banana: 0.5, cherry: 3 };

Object.keys(prices);    // ["apple", "banana", "cherry"]
Object.values(prices);  // [1, 0.5, 3]
Object.entries(prices); // [["apple", 1], ["banana", 0.5], ["cherry", 3]]

// fromEntries is the reverse — great for transforming objects
const doubled = Object.fromEntries(
  Object.entries(prices).map(([k, v]) => [k, v * 2]),
);
// { apple: 2, banana: 1, cherry: 6 }

const cheap = Object.fromEntries(Object.entries(prices).filter(([, v]) => v < 2));

// Also turns a Map or URLSearchParams into a plain object
Object.fromEntries(new URLSearchParams("a=1&b=2")); // { a: "1", b: "2" }

Object.create(null) makes an object with no prototype at all — no toString, no hasOwnProperty, nothing inherited.

A normal {} isn't really empty: through its link to Object.prototype it can reach constructor, toString, valueOf, hasOwnProperty, __proto__ and more. That's harmless when you choose the keys, but when the keys come from outside — a word count over user text, HTTP headers, a cache keyed by user IDs — any of those names can collide with an inherited property. A null-prototype object's chain is just dict → null, so the only keys it has are the ones you put in.

const dict = Object.create(null);
dict.apple = 1;

"toString" in dict;      // false — a truly empty dictionary
dict.__proto__;          // undefined — even this key is safe to use
Object.hasOwn(dict, "apple"); // true (dict.hasOwnProperty would be a TypeError)

Every property has hidden attributes. Inspect them with Object.getOwnPropertyDescriptor and set them with Object.defineProperty.

A property is more than a key and a value. Each one also carries flags that say whether the value can change (writable), whether it shows up when you list keys (enumerable), and whether the property itself can be deleted or reconfigured (configurable). Normally you never see these because ordinary assignment sets them all to true. They're how the language hides built-in methods from loops, how Object.freeze works, and how libraries define read-only or hidden properties.

const user = { name: "Rohit" };
Object.getOwnPropertyDescriptor(user, "name");
// { value: "Rohit", writable: true, enumerable: true, configurable: true }

Object.defineProperty(user, "id", {
  value: 42,
  writable: false,     // can't reassign
  enumerable: false,   // hidden from keys / for...in / JSON.stringify
  configurable: false, // can't delete or redefine
});

user.id = 7;           // silently ignored (TypeError in strict mode)
Object.keys(user);     // ["name"]
JSON.stringify(user);  // '{"name":"Rohit"}'

Accessors look like properties but run a function when read or written — useful for computed values and validation.

The caller writes account.balance or account.balance = 50 as if it were a plain field, but behind it is a function. That lets you change how a value is stored or computed without changing the code that uses it, add validation at the point of assignment, or expose a derived value that's always up to date. A getter with no setter is effectively read-only.

const account = {
  _balance: 0,
  get balance() {
    return `$${this._balance.toFixed(2)}`;
  },
  set balance(value) {
    if (value < 0) throw new RangeError("Balance can't be negative");
    this._balance = value;
  },
};

account.balance = 50;    // calls the setter
account.balance;         // "$50.00" — calls the getter (no parentheses)
account.balance = -1;    // RangeError

class Temperature {
  #celsius = 0;
  get fahrenheit() {
    return this.#celsius * 1.8 + 32;
  }
  set fahrenheit(f) {
    this.#celsius = (f - 32) / 1.8;
  }
}

A Symbol is a primitive that's guaranteed unique. Two symbols with the same description are still different.

Symbols were added in ES2015 to solve a naming problem: how do you add a property to an object without any chance of colliding with keys someone else chose, now or in future? A string key like "id" might already be in use. A symbol is a key that nobody else can create by accident, because the only way to get it is to have a reference to it. The description you pass ("id") is just a label for debugging; it has no effect on identity.

const id1 = Symbol("id");
const id2 = Symbol("id");
id1 === id2; // false

const mySymbol = Symbol("privateProperty");
const obj = { name: "John", [mySymbol]: 42 };

Object.keys(obj);                     // ["name"] — symbols are skipped
JSON.stringify(obj);                  // '{"name":"John"}'
obj[mySymbol];                        // 42
Object.getOwnPropertySymbols(obj);    // [Symbol(privateProperty)]
Reflect.ownKeys(obj);                 // ["name", Symbol(privateProperty)]

Symbol.for("app.id") === Symbol.for("app.id"); // true

A Proxy wraps an object and lets you intercept operations on it — reads, writes, deletes, in, function calls — through traps. Reflect has a matching method for every trap, which you use to perform the default behaviour.

Getters and setters let you intercept one named property you know in advance. A Proxy intercepts the operation itself, for any key, including keys that don't exist yet. You create new Proxy(target, handler); the proxy is a separate object that stands in front of target. Every time code reads, writes, deletes or checks a key on the proxy, the engine looks in handler for a trap with the matching name (get, set, deleteProperty, has, …). If there's a trap, it runs; if not, the operation passes straight through to target. Think of it as a receptionist: callers talk to the receptionist, who can answer, refuse, log, or pass the request to the real person.

Reflect exists so a trap can say "now do whatever would normally happen" without reimplementing it. Reflect.get(obj, prop, receiver) is exactly the default get behaviour, including getters and the prototype chain.

const target = { name: "Rohit" };

const logged = new Proxy(target, {
  get(obj, prop, receiver) {
    console.log(`read ${String(prop)}`);
    return Reflect.get(obj, prop, receiver);
  },
});

logged.name; // logs "read name", returns "Rohit"

function withValidation(obj) {
  return new Proxy(obj, {
    set(target, prop, value) {
      if (prop === "age" && (!Number.isInteger(value) || value < 0)) {
        throw new TypeError("age must be a non-negative integer");
      }
      return Reflect.set(target, prop, value); // must return true for success
    },
  });
}

const person = withValidation({});
person.age = 30;    // ok
person.age = -5;    // TypeError
person.age = "30";  // TypeError

Prototype pollution is a security bug where attacker-controlled keys like __proto__, constructor or prototype end up modifying Object.prototype — which then affects every object in the app.

It follows directly from the rest of this chapter. Almost every object links to the one shared Object.prototype. Writing obj.__proto__.x = … (or obj.constructor.prototype.x = …) doesn't write to obj — it reaches through the link and writes to that shared object. Normally no code does that on purpose. The bug happens when generic code — a deep merge, a "set by path" helper, a query-string parser — takes keys from user input and uses them as property names, so the attacker chooses the path. Once Object.prototype.isAdmin is true, every if (user.isAdmin) check in the process passes for objects that never had the key.

// A naive deep merge
function merge(target, source) {
  for (const key in source) {
    if (typeof source[key] === "object" && source[key] !== null) {
      target[key] ??= {};
      merge(target[key], source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

const payload = JSON.parse('{"__proto__": {"isAdmin": true}}');
merge({}, payload);

({}).isAdmin; // true 😱 — every object is now "admin"

const BLOCKED = new Set(["__proto__", "constructor", "prototype"]);

function safeMerge(target, source) {
  for (const key of Object.keys(source)) {
    if (BLOCKED.has(key)) continue;
    const value = source[key];
    if (typeof value === "object" && value !== null) {
      if (!Object.hasOwn(target, key)) target[key] = {};
      safeMerge(target[key], value);
    } else {
      target[key] = value;
    }
  }
  return target;
}

const input = JSON.parse('{"__proto__": {"isAdmin": true}, "theme": {"dark": true}}');
safeMerge({}, input); // { theme: { dark: true } }
({}).isAdmin;         // undefined