The first common temptation is to assume this refers to the function itself. That’s a reasonable grammatical inference, at least.

Page 3

Every time you feel yourself trying to mix lexical scope look-ups with this, remind yourself: there is no bridge.

Page 8

We said earlier that this is not an author-time binding but a runtime binding. It is contextual based on the conditions of the function’s invocation. this binding has nothing to do with where a function is declared, but has instead everything to do with the manner in which the function is called.

Page 10

When a function is invoked, an activation record, otherwise known as an execution context, is created. This record contains information about where the function was called from (the call-stack), how the function was invoked, what parameters were passed, etc. One of the properties of this record is the this reference, which will be used for the duration of that function’s execution.

Page 10

this is actually a binding that is made when a function is invoked, and what it references is determined entirely by the call-site where the function is called.

Page 10

Intentionally mixing strict mode and non-strict mode together in your own code is generally frowned upon. Your entire program should probably either be strict or non-strict. However, sometimes you include a third-party library that has different strictness than your own code, so care must be taken over these subtle compatibility details.

Page 14

Arrays assume numeric indexing, which means that values are stored in locations, usually called indices, at positive integers, such as 0 and 42:

Page 43

Use objects to store key/value pairs, and arrays to store values at numeric indices.

Page 43

But what if you want to iterate over the values directly instead of the array indices (or object properties)? Helpfully, ES6 adds a for..of loop syntax for iterating over arrays (and objects, if the object defines its own custom iterator):

Page 60

Class/inheritance describes a certain form of code organization and architecture — a way of modeling real world problem domains in our software.

Page 65

Another key concept with classes is polymorphism, which describes the idea that a general behavior from a parent class can be overridden in a child class to give it more specifics.

Page 66

But does that mean JavaScript actually has classes? Plain and simple: NO.

Page 67

But because of JavaScript’s peculiarities, explicit pseudopolymorphism (because of shadowing!) creates brittle manual/explicit linkage in every single function where you need such a (pseudo)polymorphic reference. This can significantly increase the maintenance cost. Moreover, while explicit pseudopolymorphism can emulate the behavior of multiple inheritance, it only increases the complexity and brittleness. The result of such approaches is usually more complex, harder-to-read, and harder-to-maintain code. Explicit pseudopolymorphism should be avoided wherever possible, because the cost outweighs the benefit in most respects.

Page 79

In fact, JavaScript is almost unique among languages as perhaps the only language with the right to use the label “object-oriented,” because it’s one of a very short list of languages where an object can be created directly, without a class at all.

Page 90

Inheritance implies a copy operation, and JavaScript doesn’t copy object properties (natively, by default). Instead, JS creates a link between two objects, where one object can essentially delegate property/function access to another object. Delegation (see Chapter 6) is a much more accurate term for JavaScript’s object-linking mechanism.

Page 94

Functions aren’t constructors, but function calls are “constructor calls” if and only if new is used.

Page 96

As we’ve now seen, the [[Prototype]] mechanism is an internal link that exists on one object that references some other object. This linkage is (primarily) exercised when a property/method reference is made against the first object, and no such property/method exists. In that case, the [[Prototype]] linkage tells the engine to look for the property/method on the linked-to object. In turn, if that object cannot fulfill the lookup, its [[Prototype]] is followed, and so on. This series of links between objects forms what is called the “prototype chain.”

Page 107

Object.create(..) creates a new object (bar) linked to the object we specified (foo), which gives us all the power (delegation) of the [[Prototype]] mechanism, but without any of the unnecessary complication of new functions acting as classes and constructor calls, confusing .prototype and .constructor references, or any of that extra stuff.

Page 107

Functions called with new are often called “constructors,” despite the fact that they are not actually instantiating a class as constructors do in traditional class-oriented languages.

Page 112

While these JavaScript mechanisms can seem to resemble “class instantiation” and “class inheritance” from traditional class-oriented languages, the key distinction is that in JavaScript, no copies are made. Rather, objects end up linked to each other via an internal [[Prototype]] chain.

Page 112

In other words, the actual mechanism, the essence of what’s important to the functionality we can leverage in JavaScript, is all about objects being linked to other objects.

Page 114

We need to try to change our thinking from the class/inheritance design pattern to the behavior delegation design pattern.

Page 114

Basically, think about needing behaviors from two sibling/peer objects (XYZ and Task) to perform task “XYZ.” But rather than needing to compose them together, via class copies, we can keep them in their separate objects, and we can allow the XYZ object to delegate to Task when needed.

Page 116

In JavaScript, the [[Prototype]] mechanism links objects to other objects. There are no abstract mechanisms like “classes,” no matter how much you try to convince yourself otherwise.

Page 116

In general, with [[Prototype]] delegation, you want state to be on the delegators (XYZ, ABC), not on the delegate (Task).

Page 117

This is an extremely powerful design pattern, very distinct from the ideas of parent and child classes, inheritance, polymorphism, etc. Rather than organizing the objects in your mind vertically, with parents flowing down to children, think of objects side by side, as peers, with any direction of delegation links between the objects as necessary.

Page 118

Ask yourself: if I can get the same functionality with OLOO-style code as I do with class-style code, but OLOO is simpler and has less things to think about, isn’t OLOO better?

Page 122

OLOO better supports the principle of separation of concerns, where creation and initialization are not necessarily conflated into the same operation.

Page 131

We didn’t need a base Controller class to “share” behavior between the two, because delegation is a powerful enough mechanism to give us the functionality we need.

Page 136

Another common, but perhaps less robust, pattern for type introspection, which many devs seem to prefer over instanceof, is called “duck typing.” This term comes from the adage, “if it looks like a duck, and it quacks like a duck, it must be a duck.”

Page 141

Classes and inheritance are a design pattern you can choose, or not choose, in your software architecture. Most developers take for granted that classes are the only (proper) way to organize code, but here we’ve seen there’s another less-commonly talked about pattern that’s actually quite powerful: behavior delegation.

Page 143

First, the class syntax may convince you a new “class” mechanism exists in JS as of ES6. Not so. class is, mostly, just syntactic sugar on top of the existing [[Prototype]] (delegation!) mechanism.

Page 144

class does a very good job of pretending to fix the problems with the class/inheritance design pattern in JS. But it actually does the opposite: it hides many of the problems and introduces other subtle but dangerous ones.

Page 144