Repository: You-Dont-Know-JS
Issue: "this & object prototypes": editorial review (about chapter 6)
Labels: for second edition,editorial

Per Kyle's request, I'm posting what I find to be the serious issues with chapter 6 as they now stand; of course I'm open to being persuaded that I may have missed something.  This is mostly from an Amazon review.  I'll do my best to translate to second person, but forgive me if a few third person references to you survive.

The tl;dr is that this chapter does not adequately discuss how constructor functions are used idiomatically, and not honestly compared to OLOO.  Specifically, there are many, many situations where OLOO is far worse than well designed constructor functions, and an unsuspecting new developer reading this book may take away some simply awful habits.

Chapter 5 was good. You explain how prototype chains work, and how to create an object from a prototype: `Object.create`. From here I assumed you would show the limitations of `Object.create`: that to create a "family" (I'm avoiding using the word class for obvious reasons) of objects you'll need to repetitively code up factory functions of some sort that create the object using `Object.create`, then set the relevant properties, then return the object. Something like this (contrived of course):

```
function createPerson(name, birthday){
    var result = Object.create(personPrototype);
    result.name = name;
    result.birthday = birthday;
    return result;
}
```

Which would then be a perfect time to explain why constructor invocation exists, and how it very cleanly solves this very common problem, albeit with some syntactic baggage unfortunately borrowed from Java.

Nope. The chapter ends, and into 6.

Chapter 6 would have been a tremendous opportunity to thoroughly explain how OO development in JavaScript is typically done--constructor functions--with alternatives that might occasionally be appropriate, namely your OLOO. Instead it seemed to devolve into a tirade about how standard JavaScript idioms aren't to the your liking, and why developers should instead use OLOO, which actively hampers many common use cases (use cases you do not bring up). Any non-expert JS developer who reads this chapter may pick up some bad advice which is very easy to misuse in a professional environment. 

Many of your examples seemed like gross misrepresentations and sleights of hand picked to make (typical) prototypal inheritance (constructor functions with chained prototypes) look unnecessarily bad. On page 132 you present the following, as part of the "traditional class design pattern"

```
LoginController.prototype.failure = function(err){
    //super call
    Controller.prototype.failure.call(this, "Login invalid: " + err);
}
```

Overriding a base method just to lock in a string prefix?  Fine; book examples can be contrived. The problem is that the alternative you present with his OOLA is this

```
AuthController.rejected = function(err){
    this.failure("Auth Failed: " + err);
}
```

You just made a brand new method with a new name that calls this.failure, with this.failure resolving up to the prototype (just like before). The reader may be left wondering why this possibility was never brought up for the "traditional" way

```
LoginController.prototype.rejected = function(err){
    this.failure("Login invalid: " + err);
}
```

or a new reader may be left with the impression that this way does not exist in the traditional idiom. 

The rest of your comparison seemed to involve similar sleights of hand; it almost seemed apples-to-oranges. On page 134, when implementing your OOLA pattern you completely cut the inheritance hierarchy up to appear simpler.  Couldn't this have been done with the "traditional" pattern?  You also don't point out that the errors array had to be re-initialized, and that any developer following this pattern would have to also re-initialize every. single. other. property a base object may have (yours had only had the one, and so hid this complexity). And of course you fail to consider the difficulty this code would have if you ever needed to create a second, or third of these objects. These are all things that constructor functions handle seamlessly for you.

Why not discuss these issues so the reader has a fuller picture?  Was there a word limit I'm unaware of? 

Finally, is your mental model for the traditional way really honest?  Surely this suffices for the vast majority of developers

obj.foo();
- box is shown of obj, listing obj's own properties
- foo is not there, arrow takes you up to obj's prototype
- check there
- repeat step 2 until found, or prototype chain exhausted.

While—if they're a senior dev—also knowing (in the back of their heads) that there are also constructor properties at each level pointing to the relevant constructor function.

You _did_ explain how prototype chains work earlier in the book—and well. Why not tie it together with a more thorough exploration of constructor functions? 

Note, I took the time to write all this up, albeit originally excessively angrily on Amazon, because many young developers learn their trade from books like this.  Years ago Crockford's text was extremely influential to me—in a bad way.  I accepted his opinions as fact, and frankly wound up looking foolish.  I don't know if Crockford's reasons for (ostensibly at least) hating constructor functions are the same as yours, but it can be a (somewhat) harmful thing to put out there when presented like this.