Classical vs prototypal inheritance

Both let one thing reuse another's behaviour, but they differ in what inherits from what.

Classical inheritance — used by Java, C#, C++ — is built on classes. A class is a blueprint, not an object. You define the blueprint, then instantiate it, and each instance receives its own copy of the structure the class describes. Inheritance is a relationship between blueprints, fixed at compile time.

Prototypal inheritance — what JavaScript actually has — has no blueprints. Objects inherit directly from other objects. An object holds a link to its prototype, and when a property is missing the engine follows that link. Nothing is copied: the lookup is resolved at runtime, every time.

const base = { greet() { return `hi ${this.name}`; } };

const user = Object.create(base);   // user delegates to base
user.name = "Mai";
user.greet();                       // "hi Mai" — found on base, run on user

Consequences of the difference

• Live link. Add a method to base now and user gains it immediately. With classical inheritance, existing instances are unaffected by later changes to the class.
• Flexible at runtime. You can build an object, then decide its prototype. Classes fix the relationship up front.
• One copy of methods. Methods live on the prototype, shared by every object that delegates to it, rather than duplicated per instance.

What about class?

ES2015 class looks classical but is not. It is syntax over the prototype chain — Dog.prototype's prototype is Animal.prototype, and super walks that chain. Nothing is copied anywhere. The syntax is worth using because it is familiar and less error-prone, but knowing what sits underneath explains behaviour that otherwise looks strange, such as methods appearing on instances you created before the method existed.