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
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
.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.
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 ES6
class mechanism. ...