Flanagan’s book is more than 1000 pages (six times Crockford’s book). Again, as its title suggests, the book can be considered the “definitive guide” if by “definitive” we understand “you don’t have to keep looking for more info around the web, this book is enough”. And certainly, it covers most of the aspects of the language that you are going to use in your day to day work (debugging time included). Unfortunately, reading the whole book can be a hard job for newcomers.
None of them mention the new incorporations added in ES6.
On the other hand, the YDKJS book series seems to be a good intermediate point:
- It does cover the good and bad parts of the language, and
- It does it in a way that it’s easy to follow and understand… and in less than 1000 pages.
This is not a book review of the YDKJS series, just something I found interesting. If you really want to know more about this topic then you should check the third book this & Object Prototypes.
Classes Versus Objects
Classical inheritance mechanism is all about copying. The child class inherits the behaviour of its parent class copying its behaviour (data values and methods) but at the same time it’s allowed to the child to override part of this behaviour (polymorphism).
In JS there is no such things as classes 1, all we have are objects; so how do we share behaviour in JS? Via delegation: we let some object A provide a delegation (to another object B) for property or method references if they are not found on the object itself (A). So rather than viewing the relationship between your objects as an strictly child-parent structure, we can think of objects as peers with any direction of delegation links between them.
Let’s implement some functionality using the approaches mentioned.
Simulating classical inheritance
We think of
Rectangle as a child of
Glyph and override the
Using behaviour delegation
With this approach we don’t think of
Rectangle as a child of
Glyph but rather
as an object that requires some behaviour of
achieving this using delegation. We deliberately use a different name (
draw) to express the idea that
Glyph are two
standalone objects and the former requires a specific behaviour of the latter.
ES6 besides, we see that some mental overhead has been eliminated:
new operator, no
prototype references, no pseudopolymorphism
Glyph.prototype.draw); all we got are objects and delegate
calls to the
ES6 introduces the
classkeyword and despite the syntactic
improvements, JS still operates on top of the Prototype mechanism. ↩