You Don't Know JS: this & Object Prototypes

Appendix A. ES6 Class

If there’s any takeaway message from the second half of this book (Chapters 4-6), it’s that classes are an optional design pattern for code (not a necessary given), and that furthermore they are often quite awkward to implement in a [[Prototype]] language like JavaScript.

This awkwardness is not just about syntax, although that’s a big part of it. Chapters 4 and 5 examined quite a bit of syntactic ugliness, from the verbosity of .prototype references cluttering the code, to explicit pseudo-polymorphism (see Chapter 4) when you give methods the same name at different levels of the chain and try to implement a polymorphic reference from a lower-level method to a higher-level method. .constructor being wrongly interpreted as “was constructed by” and yet being unreliable for that definition is yet another syntactic ugly.

But the problems with class design are much deeper. Chapter 4 points out that classes in traditional class-oriented languages actually produce a copy action from parent to child to instance, whereas in [[Prototype]], the action is not a copy, but rather the opposite—a delegation link.

When compared to the simplicity of OLOO-style code and behavior delegation (see Chapter 6), which embrace [[Prototype]] rather than hide from it, classes stand out as a sore thumb in JS.

class

But we don’t need to argue that case again. I remention those issues briefly only so that you keep them fresh in your mind now that we turn our attention to the ...