Prototype Inheritance Bug — Shared Array Leaks Tenant Data

Production story: A team wrote a class for a UI component. The render method called this.fetchData() which was inherited from a base class. They passed render as a callback to a timeout: setTimeout(this.render, 1000). Every single render failed because this was undefined. The fix was one line: setTimeout(this.render.bind(this), 1000). You'll make this mistake once. Then you'll bind everything.

One sharp rule: if you ever pass a method as a callback, bind it before handing it off. Or use an arrow wrapper. Don't assume this travels with the function — it doesn't.

'use strict';

const parent = {
  name: 'Parent',
  greet() {
    console.log(`Hello from ${this.name}`);
  },
  sayHello() {
    return 'Hello ' + this.name;
  },
  sayGoodbye() {
    console.log(this.sayHello() + ' and goodbye!');
  }
};

const child = Object.create(parent);
child.name = 'Child';

child.greet();        // 'Hello from Child'
child.sayGoodbye();   // 'Hello Child and goodbye!'

const extracted = child.greet;
// extracted(); // TypeError: Cannot read properties of undefined (reading 'name') in strict mode

// Fix via bind
const boundGreet = child.greet.bind(child);
boundGreet();         // 'Hello from Child'

Writing to the Prototype — Property Shadowing and Setter Interception

You set a property on an object. That property already exists on the prototype. What happens next depends on the property descriptor. There are exactly three outcomes. You need to know all three before you write another line of object-oriented code.

First case: normal data property on the prototype. Assign obj.prop = value. JavaScript creates a new own property directly on obj. The prototype's property is untouched. This is called shadowing — your instance property casts a shadow over the inherited one. obj.hasOwnProperty('prop') becomes true. The prototype's value still exists, but your instance will never see it.

Second case: non-writable data property on the prototype. You used Object.defineProperty(proto, 'prop', { value: 42, writable: false }). Now try obj.prop = 100. In sloppy mode, the assignment silently fails. No own property is created. The value stays 42. In strict mode, you get a TypeError: Cannot assign to read only property 'prop'. This is a production trap. Your code looks correct, but the assignment does nothing. Shadowing is blocked.

Third case: setter on the prototype. Object.defineProperty(proto, 'prop', { set(val) { this._prop = val; } }). Assign obj.prop = 'new'. The setter runs with this set to obj. No own property is created on obj. The setter's side effect happens — in this case, obj._prop becomes 'new'. The prototype's descriptor wins. You can't shadow a setter with a simple assignment.

Let's see all three in code. The non-writable case is the most dangerous. You might expect to override a inherited configuration, but the assignment does nothing. Production bug: a library defines a property as non-writable on SomeConstructor.prototype. Your application code tries to set it on an instance. It silently fails. You spend hours debugging why your component doesn't update.

The fix: always use Object.defineProperty on the instance directly if you need to override a non-writable or setter-defended property. Object.defineProperty(obj, 'prop', { value: yourValue, writable: true }). This bypasses the prototype's descriptor entirely.

One more thing: property descriptors on the prototype affect Object.assign too. Object.assign(obj, { prop: value }) does a Set internally, so it follows the same rules. If the prototype has a non-writable prop, the assignment in Object.assign fails silently too.

Rule to live by: never assume a simple assignment will create an own property. Know the descriptor. Use Object.getOwnPropertyDescriptor(proto, 'prop') before you assign.

'use strict';

const proto = {};
Object.defineProperty(proto, 'x', {
  value: 10,
  writable: false
});
Object.defineProperty(proto, 'y', {
  set(val) {
    console.log(`Setter called with ${val}`);
    this._y = val * 2;
  },
  get() {
    return this._y;
  }
});

const obj = Object.create(proto);
obj.x = 20;          // silent failure in sloppy, TypeError in strict
console.log(obj.x);  // 10 (unchanged)

obj.y = 5;           // Setter runs — 'Setter called with 5'
console.log(obj.y);  // 10 (5 * 2)
console.log(obj.hasOwnProperty('y')); // false — setter, not own property

Iterating Own vs Inherited Properties — for..in, Object.keys, and hasOwnProperty

You loop over an object. You expect three keys. You get five. You’ve just hit inherited properties. This is one of the most common JavaScript surprises.

for..in iterates ALL enumerable properties, including inherited ones. If you added a method to a shared prototype, for..in will yield it. Here’s the concrete example from a real incident at io.thecodeforge:

const userProto = {
  login() {}
};

const user = Object.create(userProto);
user.name = 'alice';
user.role = 'admin';

for (const key in user) {
  console.log(key);
}
// Output: name, role, login

// Using Object.keys:
Object.keys(user).forEach(key => console.log(key));
// Output: name, role

// Using hasOwnProperty inside for..in:
for (const key in user) {
  if (Object.hasOwn(user, key)) {
    console.log(key);
  }
}
// Output: name, role

Monkey Patching Built-In Prototypes — Why You Should Never Touch Array.prototype

You want a method on every array. You think: 'I'll just add it to Array.prototype.' Don't. This is the wrong move. Built-in prototypes are global. Everyone shares them. You don't own them. Touching them is a contract with every piece of code that runs in your process.

Why does it seem attractive? Polyfills. Before Array.prototype.includes was standard, you could add it. But the problem isn't polyfilling a well-defined spec. The problem is adding custom methods. Let's count the ways it breaks.

First: for..in loops. Try for (let key in arr) { console.log(key); }. You get '0', '1', '2', and then — your custom method name. This was a classic jQuery bug in early versions. for..in iterates enumerable own and inherited properties. Adding a method to Array.prototype makes it enumerable by default. Your arrays now have extra keys. Object.keys and for..of are safe, but for..in is not. The web is full of code using for..in on arrays.

Second: conflicts. Library A patches Array.prototype.flatten to return a flat array. Library B patches it to return a string. The order of script loading decides which behaviour wins. You get inconsistent results. You debug for hours. You curse the universe. This is the reason the SmooshGate incident happened. In 2018, TC39 proposed Array.prototype.flatten. MooTools had already patched it with different semantics. Browsers couldn't ship the new method without breaking MooTools sites. The proposal had to be renamed to flat(). One library's monkey patch changed the world's array API.

Third: native platform internals. Node.js and browser engines use prototypes internally. If you patch Object.prototype.hasOwnProperty or Array.prototype.push, you might break engine optimizations or internal calls. The engine assumes the original implementation. Your patch could cause infinite recursion or silent corruption. This is not theoretical — it has happened.

The alternative: standalone utility functions. import { flatten } from './utils.js' — no global state, no conflicts. Or use subclassing: class MyArray extends Array { flatten() { ... } }. Instance methods belong to your instances, not to every array in the universe.

One exception: polyfilling standard methods that are well-specified and not yet implemented. Even then, use a polyfill library like core-js that checks for existence first. Don't write your own.

Rule: if you ever type Array.prototype.something =, stop. Delete the line. Write a utility function instead. Your future colleagues will thank you.

// DON'T
Array.prototype.customMethod = function() { return 'patched'; };

const arr = [1, 2, 3];
for (let key in arr) {
  console.log(key);  // 0, 1, 2, 'customMethod'
}

// DO
function customMethod(arr) {
  return 'standalone';
}

console.log(customMethod(arr)); // 'standalone'

// Or subclass
class MyArray extends Array {
  customMethod() {
    return 'subclass';
  }
}
const myArr = new MyArray(1, 2, 3);
console.log(myArr.customMethod()); // 'subclass'

Performance Implications of Deep Prototype Chains

Every property access walks the prototype chain. A chain depth of 10 means up to 10 pointer dereferences per access. In a hot loop, that adds up. V8 mitigates this with inline caching (ICs) and hidden classes (“shapes”). But prototype mutation invalidates those caches.

If you call Object.setPrototypeOf(obj, newProto) after obj is already in use, V8 deoptimises the entire function. The next time that function runs, it falls back to a slow path. We measured a ~2x slowdown in a production service at io.thecodeforge after a developer mutated a prototype in a session setup handler.

Keep your chains shallow. Four levels max. If you need more, use composition. Here’s a real example:

// Slow: deep chain
class A {}
class B extends A {}
class C extends B {}
class D extends C {}
class E extends D {}
class F extends E {}

const obj = new F();
const start = performance.now();
for (let i = 0; i < 1000000; i++) {
  // accessing a property that doesn't exist on F, forces full chain walk
  obj.nonExistent;
}
console.log(`Deep chain: ${performance.now() - start}ms`);

// Fast: shallow chain
class Simple {
  constructor() {
    this.nonExistent = undefined;
  }
}
const simple = new Simple();
const start2 = performance.now();
for (let i = 0; i < 1000000; i++) {
  simple.nonExistent;
}
console.log(`Shallow: ${performance.now() - start2}ms`);

Class vs Prototype (Sugar vs Foundation) Comparison Table

One of the most common interview questions is 'Are ES6 classes just syntactic sugar over prototypes?' The short answer is 'mostly yes,' but the full answer requires understanding what the sugar buys you and what you lose. The table below breaks down the exact differences and equivalences between the two patterns.

Both approaches produce a constructor function and set up a prototype chain. The class syntax enforces some rules automatically (strict mode, super() requirement) and adds features that are impossible to replicate exactly (private fields). Conversely, the prototypal pattern allows runtime prototype mutation and mixin composition in ways that class syntax doesn't directly support.

Choosing between them in production often comes down to codebase conventions. If you're working on a modern codebase, prefer class syntax for its readability and safety. If you're maintaining legacy code or need maximum flexibility (e.g., mixing in behaviours at runtime), the prototypal pattern remains useful.

The key insight: both produce objects with the same prototype chain structure. The difference is in the syntax and the enforced semantics, not in the inheritance mechanism itself.

// --- Both produce identical prototype chains ---

// Prototypal way
function AnimalProto(name) { this.name = name; }
AnimalProto.prototype.speak = function() { return `${this.name} says...`; };

// Class way
class AnimalClass {
  constructor(name) { this.name = name; }
  speak() { return `${this.name} says...`; }
}

// Both build the same structure
const p = new AnimalProto('Proto');
const c = new AnimalClass('Class');

console.log(p.__proto__ === AnimalProto.prototype); // true
console.log(c.__proto__ === AnimalClass.prototype);  // true
console.log(AnimalProto.prototype.constructor === AnimalProto); // true
console.log(AnimalClass.prototype.constructor === AnimalClass); // true

// But classes have strict mode and super requirements
class Child extends AnimalClass {
  constructor(name, age) {
    super(name);  // must be called before this
    this.age = age;
  }
}

// Same prototype chain manually:
function ChildProto(name, age) {
  AnimalProto.call(this, name);
  this.age = age;
}
ChildProto.prototype = Object.create(AnimalProto.prototype);
ChildProto.prototype.constructor = ChildProto;

// The prototype chains are structurally identical

Real-World Pattern — Composable Mixins Over Deep Inheritance

Here's the dirty secret senior engineers know: deep inheritance hierarchies are fragile. The moment your requirements change, the base class is impossible to modify without breaking every subclass. This is the 'gorilla banana problem' — you wanted a banana, but you inherited the gorilla holding it and the entire jungle it lives in.

The JavaScript prototype chain gives you a practical alternative: mixins. Instead of inheriting from a chain of parent classes, you compose objects by copying or delegating methods from multiple sources. This is idiomatic modern JavaScript and it sidesteps the rigidity of single-parent inheritance entirely.

The most common mixin pattern uses Object.assign() to copy methods onto a prototype, or uses a function that takes a superclass and returns an extended class (a 'class factory mixin'). This lets you snap in capabilities like Serializable, Timestamped, or Auditable without creating a brittle hierarchy.

This matters in the real world because UI component libraries, state management systems, and ORMs all use composition patterns like this. Recognising them — and knowing when to choose composition over inheritance — is what separates intermediate developers from senior ones.

// --- Mixins: composing behaviour without deep inheritance ---

// Mixin factory: a function that takes a Base class and returns an extended class
// This lets us 'snap in' abilities without a fixed hierarchy

const Serialisable = (BaseClass) => class extends BaseClass {
  toJSON() {
    // Serialise all own enumerable properties to a JSON string
    const ownProps = {};
    for (const key of Object.keys(this)) {
      ownProps[key] = this[key];
    }
    return JSON.stringify(ownProps);
  }

  static fromJSON(json) {
    const data = JSON.parse(json);
    // Creates an instance and copies all properties on to it
    return Object.assign(new this(), data);
  }
};

const Timestamped = (BaseClass) => class extends BaseClass {
  constructor(...args) {
    super(...args);
    // Automatically stamp with created time when constructed
    this.createdAt = new Date().toISOString();
  }

  getAge() {
    const ms = Date.now() - new Date(this.createdAt).getTime();
    return `${Math.floor(ms / 1000)} seconds old`;
  }
};

// The base class stays lean — only core identity
class User {
  constructor(username, email) {
    this.username = username;
    this.email = email;
  }

  greet() {
    return `Hello, I'm ${this.username}`;
  }
}

// Compose: User + Timestamped + Serialisable
// Read right to left: start with User, add Timestamped, add Serialisable
class PlatformUser extends Serialisable(Timestamped(User)) {
  constructor(username, email, role) {
    super(username, email);  // chains up through all the mixins to User
    this.role = role;
  }
}

// --- Usage ---
const admin = new PlatformUser('sarah_dev', 'sarah@example.com', 'admin');

console.log(admin.greet());          // from User
console.log(admin.getAge());         // from Timestamped mixin
console.log(admin.toJSON());         // from Serialisable mixin

// instanceof still works for all layers
console.log(admin instanceof User);  // true
console.log(admin instanceof PlatformUser); // true

// The prototype chain records every mixin link:
// admin
//   --> PlatformUser.prototype
//   --> Serialisable(Timestamped(User)).prototype  [anonymous class]
//   --> Timestamped(User).prototype               [anonymous class]
//   --> User.prototype
//   --> Object.prototype
//   --> null

Prototype Pollution: The Security Vulnerability You Didn't Know You Had

Prototype pollution is a JavaScript vulnerability where an attacker injects properties into Object.prototype. Since every object inherits from Object.prototype, a single injection can affect all objects in the runtime. This typically happens when recursive merge functions or unsafe JSON parsing overwrite __proto__ or constructor.prototype.

The attack surface is any code that merges user-controlled objects without sanitisation. Libraries like lodash had CVEs for this. The fix is to use Object.create(null) for dictionaries, sanitise property keys, or freeze Object.prototype in high-security environments.

This isn't just a theoretical attack — real breaches have happened via prototype pollution in client-side frameworks and server-side Node.js applications. Understanding the prototype chain is the only way to fully grasp why pollution works and how to prevent it.

// --- Example of Prototype Pollution and Mitigation ---

// UNSAFE merge — vulnerable to pollution
function unsafeMerge(target, source) {
  for (const key in source) {
    if (typeof source[key] === 'object' && source[key] !== null) {
      target[key] = unsafeMerge(target[key] || {}, source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

// Attacker sends payload with __proto__
const maliciousPayload = JSON.parse('{"__proto__": {"isAdmin": true}}');

const innocentConfig = { role: 'user' };
unsafeMerge(innocentConfig, maliciousPayload);

// Now every object in the app has isAdmin: true
console.log(({}).isAdmin);  // true — pollution occurred!

// --- Safe alternatives ---

// 1. Use Object.create(null) for maps
const safeConfig = Object.create(null);
safeConfig.role = 'user';
// merging into safeConfig won't affect global Object.prototype

// 2. Check for __proto__ and constructor in merge
function safeMerge(target, source) {
  for (const key in source) {
    if (key === '__proto__' || key === 'constructor') continue;
    if (typeof source[key] === 'object' && source[key] !== null) {
      target[key] = safeMerge(target[key] || {}, source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

// 3. Freeze Object.prototype in critical apps
// Object.freeze(Object.prototype);  // uncomment with caution

console.log(safeMerge({}, { __proto__: { isAdmin: true } }).__proto__);  // undefined

Inheritance Is Just Object Linking — There's No Copy, Despite What You Think

Here's where most devs get it wrong: inheritance in JavaScript is not copy. When a child object inherits from a prototype, it doesn't receive a copy of the parent's properties. It gets a live link. That link is [[Prototype]], and it points upward. Property lookup walks the chain every single time. Mutation does not bubble up — you shadow. If you set child.color = 'red', you're not editing the prototype. You're slapping a new own property on child. Now child.color is 'red', and parent.color stays whatever it was. This is why shared mutable state on prototypes cause production bugs. Array.prototype is not a constructor. It's a shared object. Push something onto one array? Fine. Push something onto Array.prototype? Every array in your runtime suddenly has that item. You just broke every for...in loop across your app. The chain is for reading, not writing. Design for that.

// io.thecodeforge — javascript tutorial

const vehicle = { type: 'car', wheels: 4 };
const sedan = Object.create(vehicle);
sedan.doors = 4;

console.log(sedan.wheels); // 4 (inherited)
console.log(sedan.hasOwnProperty('wheels')); // false

sedan.wheels = 6; // shadowing — does NOT touch vehicle
console.log(vehicle.wheels); // 4 (unchanged)
console.log(sedan.hasOwnProperty('wheels')); // true
console.log(sedan.wheels); // 6 (own property now)

Building Longer Chains Is Usually a Mistake — Here's Why

Three levels deep? Fine. Five? You're debugging. Ten? You're fired. Deep prototype chains kill performance because property lookup is O(depth). Every failed lookup walks the entire chain until it hits null. That's wasted CPU cycles on every property access. Worse, it creates a readability nightmare. user.admin.manager.ceo.salary — which level defines salary? You don't know without Object.getPrototypeOf spamming. Production code stays shallow. Two levels max: a base prototype and one child. If you need more, compose. Mixins, factory functions, or plain object spread — they all beat inheritance once you cross three levels. The built-in chain itself (Object → null) is already two levels. Don't stack more. Your future self debugging a memory leak at 2 AM will thank you.

// io.thecodeforge — javascript tutorial

const level1 = { a: 1 };
const level2 = Object.create(level1);
const level3 = Object.create(level2);
const level4 = Object.create(level3);
const level5 = Object.create(level4);

// Property lookup walks 5 links
console.time('deep-lookup');
for (let i = 0; i < 1e6; i++) {
  level5.a;
}
console.timeEnd('deep-lookup');

// Flat object, 1 lookup
const flat = { a: 1 };
console.time('flat-lookup');
for (let i = 0; i < 1e6; i++) {
  flat.a;
}
console.timeEnd('flat-lookup');

Factory Functions Beat Prototypes for Composable Behavior

Prototypes are rigid. Once you set the chain, you're locked into a linear hierarchy. Try giving a User object both loggable and serializable behavior. With prototypes, you'd need a diamond inheritance mess or Object.assign hacks. Factory functions solve this without any chain. A factory is just a function that returns an object. Spread mixins, compose behavior, and return plain objects. No constructor, no new, no TypeScript fighting over super(). Real example: an API client needs logging, caching, and retry logic. Each is a plain object with methods. The factory spreads them into one object. If two mixins collide on a property name, you catch it at merge time, not at runtime. This is how production systems avoid prototype pollution entirely. ES6 classes are fine for UI components. For service objects, data mappers, and middleware? Factories. Every time.

// io.thecodeforge — javascript tutorial

const withLogging = {
  log(method, url) {
    console.log(`[${new Date().toISOString()}] ${method} ${url}`);
  }
};

const withRetry = {
  async fetchWithRetry(url, options, retries = 3) {
    for (let attempt = 1; attempt <= retries; attempt++) {
      try {
        return await fetch(url, options);
      } catch (err) {
        if (attempt === retries) throw err;
        await new Promise(r => setTimeout(r, 100 * attempt));
      }
    }
  }
};

function createApiClient(baseUrl) {
  return {
    baseUrl,
    ...withLogging,
    ...withRetry,
    async get(endpoint) {
      this.log('GET', `${this.baseUrl}${endpoint}`);
      return this.fetchWithRetry(`${this.baseUrl}${endpoint}`);
    }
  };
}

const client = createApiClient('https://api.example.com');
console.log(Object.getPrototypeOf(client)); // Object.prototype

Object.create() — The Cleanest Way to Link Prototypes

Forget constructor functions. Forget new. If you want a clean prototype chain, Object.create() is the tool. It does one thing: creates a new object and sets its [[Prototype]] to whatever you pass in. No constructor cruft, no this confusion, no accidental globals.

Here’s the production reality: you often need an object that inherits from another without side effects. Object.create(null) gives you a truly empty dictionary—no prototype pollution, no toString, no hasOwnProperty. Use it for maps or when you’re paranoid about key collisions.

The WHY: Object.create() separates the act of linking from the act of construction. That’s it. No magic. No sugar. Just a plain object with a parent. You want inheritance without ceremony? This is your weapon.

// io.thecodeforge — javascript tutorial

const animal = {
  speak() {
    return `${this.name} makes a sound`;
  }
};

const dog = Object.create(animal);
dog.name = 'Rex';

// Inherits speak from animal
console.log(dog.speak());

// True empty object — no prototype at all
const safeMap = Object.create(null);
safeMap['__proto__'] = 'polluted'; // Safe from pollution
console.log(Object.keys(safeMap)); // ['__proto__']

Object.setPrototypeOf() — The Escape Hatch You Shouldn't Use

You can mutate an object’s prototype after creation with Object.setPrototypeOf(). Does it work? Yes. Should you use it? Almost never. Here’s the WHY: changing an object’s prototype at runtime forces the engine to de-optimize that object and every object sharing its hidden class. Performance tanks. V8 gives up on optimizations for that entire function.

The only production case that justifies it is polyfilling — overriding Array.prototype methods on an array-like object that can’t be rebuilt. That’s it. For everything else, you rebuild the object with Object.create() or assign properties fresh.

Bottom line: Object.setPrototypeOf() is the eval of inheritance. It exists because JavaScript is flexible, not because you’re supposed to use it. If you reach for it, ask yourself hard questions about your architecture first.

// io.thecodeforge — javascript tutorial

const base = { greet() { return 'Hi'; } };
const obj = { name: 'Alice' };

// Don't do this in production unless you have no choice
Object.setPrototypeOf(obj, base);

console.log(obj.greet()); // 'Hi'

// The cost: obj becomes 'slow' in V8
// Check performance in DevTools — it's real

// Better: build it right from the start
const betterObj = Object.assign(Object.create(base), { name: 'Alice' });
console.log(betterObj.greet()); // 'Hi'

Inspecting Prototypes — Beyond console.log

Why inspect prototypes? Because debugging inheritance bugs means knowing exactly what exists on an object versus its chain. The simplest tool is Object.getPrototypeOf() — it returns the actual [[Prototype]] without the confusion of __proto__ (which is a getter/setter on Object.prototype, not a true property). For breadcrumb trails, use .constructor.name to identify the constructor behind an instance. For full chain snapshots, walk the chain manually: let proto = Object.getPrototypeOf(obj); while (proto) { console.log(proto.constructor.name); proto = Object.getPrototypeOf(proto); }. Avoid relying on __proto__ in production — it's slow, non-standard, and fails on objects with null prototypes. The real power is combining getPrototypeOf with hasOwnProperty to separate own properties from inherited ones without guesswork.

// io.thecodeforge — javascript tutorial

function Animal() {}
Animal.prototype.eat = function() {};

const dog = new Animal();
dog.bark = function() {};

const proto = Object.getPrototypeOf(dog);
console.log(proto === Animal.prototype); // true

let current = dog;
const chain = [];
while (current) {
  chain.push(current.constructor?.name || 'null');
  current = Object.getPrototypeOf(current);
}
console.log(chain); // ['Animal', 'Object', 'null']

Object.create() — Prototypes Without Constructors

Object.create(proto) builds an object whose [[Prototype]] points directly to proto, bypassing constructors entirely. This gives you pure prototype linking without the baggage of a constructor function or ES6 class. The real gain: you can create objects that inherit from any object — including null (no prototype), which is perfect for plain data maps. Object.create also accepts a second properties descriptor argument to define own properties with fine-grained control (writable, enumerable, configurable). Unlike new Constructor(), there is no initialization step — you get an empty object linked to the prototype. This pattern dominates when you need composable behavior without pretending everything is a class. Use it for mixins, cloning, and when you want an object that truly starts blank.

// io.thecodeforge — javascript tutorial

const animal = { eat() { return 'yum'; } };

const dog = Object.create(animal);
dog.bark = () => 'woof';

console.log(dog.eat());                  // yum (inherited)
console.log(Object.getPrototypeOf(dog) === animal); // true

const nullMap = Object.create(null);
nullMap.key = 'value';
console.log(nullMap.toString); // undefined — no Object.prototype