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;drThis 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 thisAuthController.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" wayLoginController.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.

Explains "this" perfectly and understandably, in one chapter. And the reality is so complex, that you can see why "this' is such a mystery.The book then goes on to cogently show how misguided it is to try to impose any sort of Class system on javascript, despite attempts in the latest ECMAScript to do so. I've come to appreciate his description of "ugly explicit pseudopolymorphism" -- but no, the book is not jargony and is clearly written.

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.

his helped get me through a coding immersion program that got me a job as asoftware engineer. Kyle explains things so well. Not necessarily a beginner's book.Get through the basics and then use this to dig deeper. Excellent read.

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. .

An amazing introduction for JavaScript. It has a lot of deep details and simple way of teaching which makes it easier for people who don’t speak English as mother language

Kyle Simpson is like a highly experienced mechanic who can teach his (or her) students by taking apart the engine, or the drive train, or the break system piece by piece, illustrating how the whole system works by demonstrating the purpose and function that each piece performs for the whole assembly.The perplexed and misinformed readers can finally understand where and how their assumptions led them astray in their JavaScript code. In place of frustration over JavaScript's seemingly contradictory and mysterious behavior the reader can understand the underlying logic and beauty of the current standard (as well as the blunders and wrong directions in the previous versions, that can also cause problems!).This is no exaggeration. It was my experience in reading the different volumes in the series.

This has very deep concepts of this and prototypes. This will definitely help you write or debug code more confidently.

Llevo varios años desarrollando con JavaScript, pero nunca está demás esta clase de libros que se enfocan en las bases del lenguaje, bastante recomendado (No para principiantes, más para un nivel principiante-intermedio), por el precio no deja duda alguna.

Excellent ouvrage.L'auteur maîtrise vraiment le JavaScript.Ayant 12 ans d'expérience en développement Java, j'ai décidé de me mettre à jour sur les technologies Front.Très vite, je me suis rendu compte que je connaissais moins le JavaScript que je ne l'ai cru depuis plus de 10 ans.JavaScript n'est pas un sous langage.C'est un langage à part entière qui doit être appris depuis les bases afin d'être maitrisé.Il ne suffit pas de maîtriser le C# ou le Java et de croire pouvoir en déduire les caractéristiques de JavaScript. Il ne suffit pas, non plus de copier-coller du code depuis Stackoverflow lorsqu'on est bloqué devant un problème Javascript.C'est une grosse erreur commise pendant longtemps par bon nombre de développeurs.Pour bien comprendre les bases, éviter les pièges et maîtriser les concepts fondamentaux de JavaScript, la série "You Don't Know JS" de Kyle Simpson est excellente.Ce volume a démystifié les notions de prototype ainsi que le mot clef this.Parlant de ce fameux mot clef this, il est présenté dans plusieurs autres références comme une notion avancée.Ce livre de Kyle Simpson vous permettra de comprendre que this n'est pas une notion avancée mais plutôt une des bases même de Javascript.À l'attention des développeurs provenant d'autres langages orientés objet: il vaut mieux éviter de croire que le "this" en JavaScript a les mêmes propriétés que celui du java ou de C#.Un bon moyen d'aborder cet ouvrage est de faire table rase de nos connaissances et d'étudier cet ouvrage dans l'ordre des chapitres comme un débutant.