Introduction

[00:00:00]
>> Kyle Simpson: Seven years ago, Mark gave me my start in teaching. He reached out to me, had seen me giving conference talks, but I had never taught anything in this industry, whatsoever. And he reached out and said, hey, I think you should give it a shot. And he took a couple of weeks to coax me, mostly because I was having to come up to snowy, cold Minnesota.

[00:00:18]
But he took a couple weeks to coax me and I came up here and gave my first workshop. And midway through that day, it clicked in my mind that this is what I wanted to do, and this is what I'm here for, is to teach. So I'm a teacher now full-time, thanks completely to Mark.

[00:00:38]
So I always appreciate that and I always feel like I'm coming back home, if you will, when I come back to Frontend Masters. So this course, we're gonna be talking about JavaScript and we're gonna be talking about it much more deeply than you're used to likely going. Most people may know that I have a fairly strong online presence under the name GETIFY.

[00:01:00]
So if you've read my Twitter streams, especially lately, I've been talking a lot about all this stuff while preparing the course. But you can find all of my thoughts on my Twitter, on GitHub, that's my email address. So feel free to reach out or look for more of that information.

[00:01:16]
I've written a number of books including the You Don't Know JS book series. A lot of material from this course tracks directly with the first three major books of the series. The Scope and Closures book, the This & Object Prototypes book, and the Types & Grammar book. So those are the best places to go after this course to get more information.

[00:01:35]
You can read those for free or you can purchase them. I always appreciate purchases if you like those. So I wanna talk to you a little bit about why we're gonna jump into JavaScript so much more deeply. Rather than a broad survey of every kind of framework and acronym that's possible, why are we diving deep into JavaScript, and why does that even matter today?

[00:01:53]
Because it seems the trend is nobody even writes JavaScript anymore. They write something else, whether it's TypeScript or an entirely different language like Go or Closure. But nobody seems to really write their JavaScript. I mean, nobody even ships JavaScript that they wrote anymore. They ship the code that 14 layers of Babble transformations have done.

[00:02:13]
So why does it even matter why we learn and understand and why should we learn and understand JavaScript? So I wanna, just a quick brief, this is an overview of what we're gonna be covering. This is obviously very simple code, but this is actually something that I experienced or I learned just recently, in the preparation and buildup to this course.

[00:02:36]
So most of you probably know about the ++ operator. And that when it shows up in the postfix position, like it is here on line 3, when it shows up in that postfixed position it's an after increment. So it gives you the value and then it increments, which is why x++ still returns us 40, but then x has been updated to 41.

[00:02:56]
And then on line 6 we have the pre-increment which does the updating first and then returns the value, which is why on that line we get both 42s. Now I've had in my head and I think most developers have had in their head a mental model for what the ++ operator is doing.

[00:03:13]
Yes, there's the before and after kind of nuance, but I've had in my mind that essentially, this ++ operator is basically x+1. And I think most people probably think that that is the case. And so I was digging into this in particular, and you'll find out later in the course why I was thinking so deeply about something as sort of nuanced as this.

[00:03:35]
But I was trying to think about if you have ++ on some value and it's in the postfix position, does that mean that the value comes back completely untouched? I assumed that that was the case, that it returned the value completely untouched and then it made whatever increments it updated.

[00:03:54]
So the question then becomes, well, what happens when you use ++ in that postfix position, but you use it on some value that's not already a number? And we're gonna be talking in just a little bit in this course about types and coercion. And I'm gonna get real deep into this topic.

[00:04:08]
But the question becomes, what happens when there's a string representation of a number and then you do something fundamentally mathematic like incrementing it? In my mind thought process, again, because thinking of x++ as x equals x+1, I was thinking, well, it will return this string 5, and then it'll coerce that string 5 to the number 5 and update it to 6.

[00:04:30]
That was the mental model I had. And it turns out that even though that seems reasonable, that's not what happens. It turns out that it goes ahead and coerces it to a number first, or at least that's what appears to happen. You notice that I didn't get back the string 5 there on line 7, I got back the number 5.

[00:04:47]
So it does go ahead and modify, in a sense, the value if it needs to coerce it to a number, before it does any incrementing. So it's not even really an after, it's sort of in the middle. It's kind of a strange thing. And this was a nuance that had never occurred to me before.

[00:05:03]
Now I'm not suggesting that you're gonna run across these problems in code. But this is to be illustrative of a larger point, which is that we as developers tend to assume mental models about code. And then when bugs happen, and I say when, not if, when bugs happen we blame the language, right?

[00:05:20]
We blame the language. JavaScript clearly must have been designed poorly because this happened. Now I have lots of opinions. Those that follow me know, I have lots of opinions on JavaScript. I'm never at a loss for those. I like to say the only thing I'm an expert on is my own opinions, right?

[00:05:36]
I'm never at a loss for those. So I have lots of opinions on whether or not some particular thing was a good or smart or wise decision in the design of JavaScript. But what I never think is appropriate is for us to take something where we get surprised and say, because we're surprised, therefore JavaScript is at fault.

[00:05:56]
If you ask a room of C++ developers, have you ever read any part of the specification for C++? Most hands will go up, same for Java. But if I ask that same question, and I do, all over the world I ask this question almost every time, how many of you have read any part of the JavaScript spec?

[00:06:12]
And I hardly ever get any hands. And I think part of what I'm getting at here is that many developers in the JavaScript community seem to think that JavaScript with its low barrier to entry, should be so automatically understandable, so intuitive, that if it's not immediately intuitive, therefore it was poorly designed.

[00:06:32]
As if we don't own a responsibility to learn how our tool works. So if you're looking for any sort of overarching theme to what I teach and why I teach and specifically this course, it is that that's not good enough as developers for us to assume something, our assumption to be incorrect.

[00:06:53]
And then when we get bitten by it we shift the blame to someone else. Instead of most developers in other communities saying, well, the fault is my own. I didn't understand it enough, okay? So here, when I experienced it coming back as the number 5 instead of the string 5, I didn't say, stupid JavaScript, how could you be so poorly designed?

[00:07:13]
My question was why, what specifically? And there's really only one way to answer that question. So the question of have you ever read any part of the specification is really an ever-present question that you should always be asking yourself. If I don't understand something, where is that source of authority?

[00:07:30]
I actually had this argument recently where somebody said, I don't know, the JavaScript engine is the source of authority. No, it isn't. The specification is the source of authority. And if you're wondering why does something do it, why am I seeing this behavior? Why does it seem weird or mysterious or black box or buggy or whatever?

[00:07:47]
The first question you need to ask is what does the specification say should happen? And then ask does my behavior that I'm seeing match the spec? If they don't match, well, then you have a bug. But if they do match, then you have a different sort of a bug and it's a bug inside of your brain which is incorrect thinking.