You Don't Know JS: this & Object Prototypes

EDIT. The below review was originally 2 star. Kyle's book falls into the (unfortunate in my opinion) trend of bashing constructor functions. They're easily abused, but they're a part of the language with definite, valid uses. Given that this is hardly an invention of Kyle's, and given that the content of the book, apart from those parts influenced by this bias are great, I think it deserves a far higher rating. The prospective reader should definitely give it a shot, though hopefully after having a decent foundation of JavaScript nuts and bolts: objects, prototype chains, constructor functions, Object.create, etc. And the new developer should absolutely know that Kyle Simpson's—and Douglas Crockford's—opinions are just that, and that your mileage may therefore vary :) -------- tl;dr This book accurately explains how `this` and object prototypes work, and explains some interesting edge cases that many senior JS developers wouldn't even know; but the end product is utterly destroyed by the author's Douglas Crockford-like opinions on how JavaScript *should* be used (hint: very differently than how it was designed to be used, and how it idiomatically is used by developers). --- This book seems to take a page from Douglas Crockford's JavaScript the Good Parts and offers (potentially unsuspecting) readers horrible, horrible advice that run absolutely contrary to standard idioms in the language. Chapters 1 and 2 start off quite well. He does a splendid job of explaining how the `this` value is determined inside of a function call. But already things start to turn sour at the end of chapter 2. To wit: " While arrow functions provide an alternative to using bind(...) on a function to ensure its `this`, which can seem attractive, it's important to note that they essentially are disabling the traditional `this` mechanism in favor of more widely understood lexical scoping. Pre-ES6, we already have a fairly common pattern for doing so, which is almost indistinguishable from the spirit of the ES6 arrow-function: [code sample follows with the classic var self = this, where self is subsequently used in a callback] While self = this and arrow functions both seem like good "solutions" to not wanting to use bind(...) they are essentially fleeing from `this` instead of understanding and embracing it. " I was quite surprised to read this. I've been writing ES6 code for a reasonable amount of time at work, and these arrow functions are a godsend. They obviate the need to constantly and annoyingly tack a .bind onto every. single. ajax callback (or do var self = this;) Similar writings occur in the appendix where the author surmises that the new ES6 class syntax is some sort of escape for JavaScript developers to not have to (seem to) work with JavaScript's dynamic nature. Again, the class syntax is nothing more than some nice syntactic sugar to ease standard JavaScript idioms--constructor functions, in this case--and require less code to implement. It's disappointing to me that new language features which make developers' lives simpler are being bashed and reduced to things to let developers not understand the language. Chapter 3 does a fine job of explaining object and property creation. He explains well ES5 mechanisms for defining writeability, enumerability, getters, setters, etc. Chapter 4 describes classical OO development, and then goes into all the various, awkward ways in which these patterns can be hacked in JavaScript. This chapter was a bit stretched at times, but I assumed he was going to tie things together in chapter 5; I was wrong. Chapter 5 starts off well. He explains how prototype chains work, he then shows how to create an object from a prototype: Object.create. From here I assumed he would show the limitations of Object.create: that to create a "family" (I'm avoiding using the word class for obvious reasons) of objects using Object.create, 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 relevant 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 off to chapter 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. Instead it seemed to devolve into a tirade about how standard JavaScript idioms aren't to the author's liking, and why developers should instead use an almost bizarre alternative that actively works against how the language was designed (objects linked to other objects, or OLOO as he calls it). Any non-expert JS developer who reads this chapter may be in for a rude awakening if she were to try to apply this advice in an actual dev shop. Worst of all are the gross misrepresentations and sleights of hand the author uses to disparage (typical) prototypal inheritance (constructor functions with chained prototypes). On page 132 he presents 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); } If you're wondering why he had to override a base method just to lock in a string prefix, then you're not alone. But whatever. Book examples can be contrived. The problem is that the alternative he presents with his OOLA is this AuthController.rejected = function(err){ this.failure("Auth Failed: " + err); } Yep. He 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 is left wondering why this possibility was never brought up for the "traditional" way LoginController.prototype.rejected = function(err){ this.failure("Login invalid: " + err); } The rest of his apples-to-oranges comparison involves similar sleights of hand to give the illusion that (normal) prototypal inheritance (constructor functions) is more cumbersome than it is. On page 134, when implementing his OOLA pattern he completely cuts his inheritance hierarchy up to appear simpler, without noting that this same structure could have just as easily been accomplished with (normal) prototypal inheritance. He fails to point out that his 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 (his object only had the one, so again his example hides this complexity). And he fails to consider the difficulty his code would have if he ever needed to create a second, or third of these objects. These are all things that constructor functions handle seamlessly for you. Finally, preceding this code, on page 123 were a set of "mental models" he uses to show what (normal) prototypal inheritance is like. He starts with a purposefully convoluted mental model of prototypal inheritance, then admits it's unrealistic, and moves to a slightly less convoluted mental model. In real life the mental model of JavaScript prototypal inheritance with constructor functions is more like this: 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. With maybe a subsequent note that there are also constructor properties at each level pointing to the relevant constructor function. To the author's credit, he *did* explain how prototype chains work earlier in the book. But when he got to this point he decided to pretend things are crazy and convoluted now that constructor functions are involved. In volume 1 of this series the author complained that the let keyword in JavaScript relies on "implicit" block scoping, motivating him to advocate for an alternative let syntax, along with a transpiler to convert your code back to what the language expects (!!!!!). It should be noted that JavaScript's let syntax relies on the same scoping rules that (all?) block-scoped languages have used for decades. Kyle Simpson is entitled to have his opinions about what a programming language should be like. But young developers reading this book (volume 1 was actually quite good) risk picking up horrendous habits that will have to be beaten out of them when they find themselves in a software shop where working code is expected to be shipped. Reader beware. For a more sane exploration of JavaScript, I would highly recommend anything by Stoyan Stefanov, and particularly High Performance JavaScript by Nick Zakas.

I've had this book for a while now. On the first read through, I found myself overwhelmed and almost a little offended. I find Kyle's personality seems to really express itself through his books somehow and it's almost like he despises JavaScript at times. The "foo and "bar" theoretical examples can get hard to concentrate on at times as you struggle to relate them to real world problems. Having said that, I knew what I was reading would make sense after a good sleep and a clearer mind. I've had certain perplexing moments in JavaScript lately and I've found myself going back through this book and having these liberating "that's it, that's the problem I'm having!" moments. It's an outstanding read and wonderful debugger for things that are confusing you in JavaScript. Keep them coming!

Most examples are written in pre-ES6 syntax which feels very outdated at this point. I felt like I was learning “extinct” syntax at times, then Kyle would explain “actually its different in ES6 so be aware of that”. ES6 feels like an afterthought, which explains why Kyle is working on version 2.0. Kyle does a good job explaining the nuisances of the language, but this book is starting to age.

This book is a must, whether you are a JS newbie or have been in the programming trenches for years. In it, Kyle Simpson explains the inner workings of two of the most misunderstood and misused features of JS, `this` and Object prototypes. This `this` portion clearly outlines the criteria and priority JS engines use to determine a particular function's call site or context, which in and of itself is enlightening. The real value, in my opinion, comes from the Object prototype section. Simpson does an excellent job of explaining prototypal inheritance, and why inheritance is in and of itself a bad term to use with regards to JS. If you are a programmer coming from a traditional classical-inheritance language, this should clear up a lot of confusion you may have. Simpson's call for an OLOO workflow is clearly reasoned through showcasing the difficulty of bending JS to emulate a Class workflow vs. simply interacting directly with the objects themselves. He even includes an appendix outlying his argument against the `class` syntactic sugar added in ES6/ES2015 (still not true class support). Ultimately, this book is Simpson's plea that we see the dynamic power JS has and use it the way it was meant to be used. Note: this book is available for free on github, but I highly recommend you buy it as you will want to make many notes.

These kinds of books are great even if JS isn't a priority. This series not only helps one learn and think about JS but about programming in general and for all these reasons this book imo is a must have regardless of one's level of interest in JS.

If you want to know all about "this" and object prototypes (because who doesn't want to do that!) then this book is perfect for you! Kyle Simpson dives into incredible detail about many javascript object related things that you've likely never even considered inside your own head, if you're a novice (or non-expert) in Javascript objects. I found a lot of useful and informative detail about inheritance and calling stacks.

This book is available online free in fact but I prefer to read paper version than online. As far as the content goes, there is no better book that explains OOP and this. I finally understand what's going on with inheritance and where is this pointing.

Nice explanation of JS OO and behavior delegator. Makes it clear what JS has and does not have wrt OO design patterns and shows clearly why traditional OO patterns based on classes don’t work. .