JS tries to satisfy the extremely pervasive desire to design with classes by providing seemingly class-like syntax.

A class is a blueprint. To actually get an object we can interact with, we must build something from the class i.e. instantiate. The end result of such "construction" is an object, typically called an instance, which we can directly call methods on and access any public data properties from, as necessary.

The object is a copy of all the characteristics described by the class.

The constructor of a class belongs to the class and almost universally has the same name as the class. Also, constructors pretty much always need to be called with new to let the language engine know you want to const a "new" class instance.

In many languages, the keyword "super" is used, in place of this example's inherited :, which leans on the idea that a "superclass" is the parent/ancestor of the current class.

When classes are inherited, there is a way for the classes themselves to relatively reference the class inherited from, and this relative reference is usually called super.

Polymorphism doesn't mean a child class is linked to its parent class. A child class instead gets a copy of what needs from the parent class. Class inheritance implies copies.

JavaScript is simpler. It doesn't provide a native mechanism for "multip[le inheritance". Many see this as a good thing because the complexity savings more than makeup for the "reduced" functionality. But this doesn't stop developers from trying to fake it in various ways as we'll see next.

JS developers fake the missing copy behavior of classes in JavaScript: mixins. We'll look at two types of mixin: explicit and implicit.

Explicit pseudopolymorphism should be avoided wherever possible because the cost outweighs the benefit in most respects.

JavaScript functions can't really be duplicated, so what you end with instead is a "duplicated reference" to the same shared function object.

Classes mean copies.

In general, faking classes in JS often sets more landmines for future coding than solving present real problems.