The full video and many others like it are all available as part of our Frontend Masters subscription.

Kyle Simpson

Kyle Simpson is an Open Web Evangelist from Austin, TX, who's passionate about all things JavaScript. He's an author, workshop trainer, tech speaker, and OSS contributor/leader.

Kyle Simpson

You Don't Know JS

Kyle revisits the prototype diagram he drew on the whiteboard earlier. This time, however, he shows a more complex version outlining the relationship of the two linked prototypes.

Get Unlimited Access Now

Kyle Simpson: Here's that diagram, the one that I have up on the board, in a much more complete fashion, and showing you both the bar and the foo in play. So we have an object, I'm going to use my laser pointer, if you want to try to show up on the screen.

I don't have line numbers to use, so you just have to hear me. We have this square that's next to the foo. That's foo prototype and E as a constructor back. And we have a square that's next to the bar, that's a prototype. But you notice the dotted line shows us the implied relationship.

Because this guy didn't have a constructor on it, so his implied relationship is that the constructor is foo. Same thing down here with b1 and b2. They have an implied relationship that their constructor is foo, which is just nonsense. But, we see the consistency that those bracket, bracket, pre relationships link exactly where we expect them to link, okay?

Now, unfortunately, this is kind of a fib, because this isn't all that's going on in that previous code. I actually have to show you an even more complex diagram to let you see what's really happening with that previous set of code. So you should note that some of this stuff will look familiar.

We already see foo and the bar. Those are still here. But now all this stuff up here in the top left corner, that's all brand new with a whole bunch more arrows and dotted lines. And your brain is probably going to start to explode at this point if you think about this diagram.

This took me more than a day just to create this one diagram so it's complex. Now, there are two takeaways to get here. The first takeaway is this is really complex, and if you feel like that you want to deal with these mechanisms with all of this. Then you better print this diagram out and stick it on your monitor next to those other post-it notes, because you're going to have to deal with this complexity every day of your life.

That's one takeaway. There is another takeaway. There is a more optimistic takeaway from this. That even though there's a lot of complexity here, there's actually an amazing amount of internal consistency going on. Because everything that we can observe about the language is explained by the exact same core set of rules that we've already talked about.

For example, you remember when we talked about the function prototype bind, and magically foo could call foo bind. You may have wondered how is that possible? This diagram explains exactly how that's possible because look at bar and foo. Functions are objects, which means that functions have an internal prototype linkage.

So they delegate up to the function.prototype. So that's where they get .call and .apply and .bind and so forth. So all of the mechanisms that you can observe about the language are explainable through these relationships and these arrows. Which is a nice internal consistency. There's not actually a lot of magic going on.

It's all the same thing, but it's complex, it's difficult. What we come back to is, when it comes down to it, all of these circles and arrows are completely irrelevant. What we really only care about are these squares. because the squares are where all the action happens. The objects are where all the action happens.

All this other stuff is a whole bunch of distraction that we use to get there. So wouldn't it be nice if we could just make the squares without all the other crap. And that's where we're headed, yes?
Chris W: A little bit confused on this question so I'll ask it as best I can.

Is wondering, in the previous couple of slides example where you were assigning bar.prototype to object create foo.prototype. If you were to reassign foo.prototype later, would bar.prototype inherit it? Or would bar.prototype be pointing to the original foo.prototype?
Kyle Simpson: Kind of neither, because inherit is the wrong word. Let me see if I can,

Kyle Simpson: What Chris W says there is correct. It creates a brand new object that has a prototype linkage to the foo prototype object. It's not a copy, it's not an inheritance, it's a new object with a linkage. So hopefully that answers it. We'll see more about object create in a little bit.

We'll come back to it. All right, so this diagram sucks. But there's hope, because there's a way to get a lot of this complexity erased, okay?

Ready to take your code to the next level?

Intense courses with world-class teachers and unlimited access to our growing library of videos for the great price of $39 per month.

Get Unlimited Access Now