 The inspiration for this talk is, there's a designer that I followed named Brad Frost and he wrote a post last year actually called Why I'm Not a JavaScript Developer. And he basically took a list of front end interview questions specific to JavaScript that is on the HTML5 boilerplate GitHub. And he sort of took every question and wrote kind of a smart ass remark to it. So for instance, he said, why is it called a ternary expression? What does the word ternary indicate? Ternary means it involves three things and strings them all on one line, so it's harder to read. And then he said, create a loop. So this is the fizz-buzz question. Create a loop that iterates up to 100 while outputting fizz at multiples of three, buzz at multiples of five and fizz-buzz at multiples of three and five. So this is a actual kind of standard coding question. And his response was, that sounds hard and for some strange reason, I'm suddenly jonesing for Dr. Pepper. And so it was funny, I read it and I was like, yeah, that's funny. But it was funny, but then I thought, I don't know that I could answer those questions. Like, I use JavaScript every day and I build software with it, but these seem kind of basic and I don't know the answer to them. So, and I figured that I'm probably not alone in that. Like, you can actually build a lot of awesome stuff with the tools that you use and not completely understand the tools themselves. So I thought a good talk idea was to take some of these questions and just try and answer them and answer them like succinctly as if I would have to be in an interview and maybe give some real world application to them. But before I jump into the questions themselves, I kind of want to address the point of like, our interview questions, are they a good idea? I think that this is definitely something and if you're a junior developer and you're going to be going to a lot of interviews and you're going to probably doing a lot of co-tests and things like that. Or if you're a hiring manager looking at it from the other way, you should know that a lot of times, putting people on the spot with things like this is essentially creating a adversarial relationship with the person that you're interviewing. And that really may not be what you want to do. You might want to be in a position where you want a person to feel comfortable with your company, with your team. So I'm not necessarily a proponent of asking a bunch of arbitrary code questions in interviews, but I figured it doesn't hurt to know the answers. So let's get started. We'll start with, this one is kind of a softball. And I guess I'll preface this by saying, if you're a senior dev in here, you're probably, this is old turf for you, but hopefully maybe there's some new things that you hadn't ever known exactly how it works. I learned something this morning just from researching this. And if you are a junior or a beginner, hopefully this will sort of answer a couple questions for you. But this one is pretty basic, but it was one that I couldn't succinctly answer, explain event delegation. Event delegation is JavaScript as it relates to the DOM. It basically means that if you attach an event listener to a DOM element, that listener is not only firing on that DOM element, it's actually firing on every children in that. So for instance, if you have a navigation, and so you've got an unordered list, and you've got list items, and then you've got anchor tags inside that navigation. What you have, if you add an event listener to the UL, in essence, you're actually adding event listeners to all of the children as well. So it's something to, and this happens through a process called event bubbling. So it's sort of the inverse of the idea of delegating down. Bubbling is when it comes back up. So events on an element will bubble up to all of their parents. So when you click on that A, you're actually clicking on the LI, and you're clicking on the UL, and you're clicking on the body, ultimately. So that's the concept of event bubbling. So how it actually works out in practice, ways that I've found it useful are, for instance, if you have live edits to a form that you wanna track. And you've got a form with a group of inputs in here. I may have to go over here to scroll, yeah. But you've got all different types of inputs, and you want to maybe test when they blur out of one of these inputs, or they key up, or something like that. Well, you could go through and you could target each one of these individually. You could grab all of them by a specific tag, and then you could do the special loop over them in order to add an event listener to every single one, so that would totally work. And then you'd have one function that would, you would probably have to create a different case for what type of thing it is in there, but you combine to it. But you can also just simply bind to the parent. So just grab the form itself, and everything inside of it that can change, that can fire a change event, is going to fire a change event. And so your form would run, and then in here you might have some sort of switch based on the name of that element or something like that. And this kind of demonstrates for us, this wasn't part of the questions, but it's sort of a bonus tidbit. You'll notice that when I'm listening to kind of a more universal event on looking for child elements that would trigger it, I want to use event target, not event current target. And so that's a bonus little tidbit that the difference between target and current target whenever on an event listener is that target is the actual thing that was clicked. Whereas current target is what you attach the event listener to. So if you've ever wondered what that is, I had to answer that question like just last week, so. So that's a little bit about the DOM. Moving on, next question. Explain why the following doesn't work as an iffy. Well, in order to answer that, I actually didn't know what an iffy was. So what is an iffy? Iffy stands for immediately invoked function expression. So if you actually ran this code the way that it looks right now, you would get a syntax error in your browser. And what you would want to do is basically, it's the idea of an immediately invoked function expression is basically, I write this function and I run it. I just want to write it and then run it immediately. But you can't do it this way. And the reason why has to do with kind of another related question is the difference between writing a function as a statement or as a definition and writing it as an expression. So in JavaScript, anytime there are sort of you have statements and you have expressions. Expressions result in a value and that's the concept of an expression. So if you assign a variable and try to attach a value to it, that will be read and interpreted as an expression and it will create a value. This creates more of sort of like a reference, but it's not an actual value. So you can't just run it. In fact, if you sort of try to run this code immediately, this is how JavaScript is reading it. And it's like, this doesn't make any sense to me. You wrote this thing and then later on, you're trying to call a function that you doesn't have a name. This is weird. So instead, you need to, but there are a lot of benefits, and I'll call it again into the benefits of the second, of writing it this way. How can I write it that way and get it to run immediately? Well, you can make that function an expression simply by putting parentheses around it. So now that this is in parentheses, JavaScript is going to interpret whatever is inside that parentheses to be an expression, not to be a statement, and then it can run immediately. So this is called an immediately invoked function expression. So I guess that begs the question, like why would I actually need to use this? Well, in a lot of situations, and this is probably, if you're working within a framework or something like that, you may not need to. Like you may never end up in this situation. But the next time that somebody asks you to build, like them a simple webpage, then this is going to be relevant again. You do it in order to control variable scope. So if you wrote this function, that function is not going to be available. The variables inside that are not going to be available outside of that function. And actually, the guy who's, Josh Mock is speaking right after me. He wrote sort of the best blog post that I found on this concept, and of like why you might want to control that scope. And it used to be, I think for software developers, it used to be more of an issue because we were writing a lot of things with jQuery and there were a million jQuery plugins that could be in our application and they all had very dumb and plain naming conventions. And I was like, I want to use dumb and plain naming conventions in my application. So this is how you do it. And it kind of relates to another question on this list is that why in general, is it a good idea to leave the global scope out of a website and not touch it? And it's because you can't predict the future. So 27 years ago, Roberts and Mechis predicted that the Cubs would win the World Series in 2015 and boy was he wrong. He was a year off, what an idiot. But seriously, like you don't know, especially if you're building that webpage for your friend, like what they're gonna wanna pull in, what kind of libraries, and you wanna control your variable names so you never have collision within your scope. It also allows you to maintain independence and it makes it easier to write your own code. You call things whatever you want because it's self-contained. So that's a little bit about scope. Kind of adding on to that concept is this word which is probably my favorite JavaScript word which is hoisting, explain hoisting. And before I wrote this talk, I actually had no idea like what this was. I had observed it, but I had never quite understood it. It means that all variables that are declared using var, so this was kind of a specific problem. I'll get into how it's been addressed a little bit. But all variables using var are declared at the top of any given function scope whether you really know it or not, whether you sort of like it or not. And this actually includes the functions that are written as statements. Hold on, where were they? So the top example, this would include those as well. Those are hoisted. So this is kind of an example of what you might see. But this is, I used to try and do this all the time. I would say, okay, I've got a variable and under this condition I want that variable to be this and in this other condition I want the variable to be this. And I would just be like, well, I haven't created this variable anymore. I'll create it here and then here, I'll create it. And then maybe I have another case where I don't need to create the variable. Yay, I've saved memory or something thought myself in my head. But if you use a linter or something like this, you would probably notice that this chokes. This does not like you to write it like this. It would say something like, action is already defined on line six. Because this is in reality what is happening behind the scenes that you don't even know about. But JavaScript is taking that var and it is creating var action up here at the top. And then what it's seeing here is that you're trying to declare this variable that's already been declared. Not only are you assigning it a value again, but you're declaring it again and it's like, what are you doing? This is what JavaScript is actually doing to your code. If you write functions as statements like this, those functions are actually all being hoisted to the top, the entire function. This is sort of why, and I had never really understood this, but sometimes I would write a function and I would try and call it and it would say that it was undefined, but then I would move it in another place in the code and it would work. But then other functions didn't seem to work that way. Well, it all boils down to whether you write them as statements or assign them to variables. So yeah, liners will kind of bark at you about this because it's sort of not clean code and it's, but it actually works in the browser. Browser hasn't had no problem with it. But it means, what hoisting means is that technically this works. You can have your whole if statement, you can assign value to it, assign a different value and then declare it further on down in the code and this is totally fine for JavaScript and actually in the browser. So this is pretty absurd. This is one of the reasons why people say that they hate JavaScript and whatever and we have a bad reputation, whatever. So in walk, this has kind of been addressed with ES6 and the idea of constant and let. So constant and let are ways of assigning variables that are not hoisted. They are actually even more than scoped within the function that you're in. They're scoped within the block that you're in. So if you're just in this if statement, you can have variables that are scoped within there that the outside part of the function will have no knowledge of. I would say that this makes more sense like the more that I develop of wanting to control this kind of initially I was like, everything can know about everything, I don't care but this is really good for kind of performance and things like that to scope things as closely to where you want to use it as possible. And it sort of gives you more control and again like, I mean your colleagues might not like you but if you want to use like var x equals this and var y equals that, you can and you can use it all over. There's a really good article about it by the German Dr. Axel Rauschmeier about this variables and scoping in ES6. I would highly recommend checking it out. So I guess the question is sort of after knowing these things, what do we do with the knowledge of hoisting? Like does it actually change the way that we write our code? And I'm really, I'm not gonna touch this one. This is like, I think that this has been pretty well argued ever since constant and let came out of like which ones you should use but I do see a value in and declaring things as closely to where you're gonna use them and I think part of my original intention here, this is what I learned about hoisting was hoisting constant and let give you block scoped variables and hoisting was basically trying to fake that the whole time. So constant and let are basically solving the problem that's existed in JavaScript of we want to do this and we can't. So we use hoisting to sort of fake it. So I'll probably be writing constant and let mostly, but. So speaking of, I've used the word declare a lot. There's another question of like the, what is the difference between a variable that is null, undefined or undeclared? So we'll start with undeclared. It is not simply a short-lived show on Fox. Anybody ever see undeclared? Yeah. If you like freaks and geeks, you might check out undeclared. It's not as good. But it's, you know. So undeclared is basically when you try and use a variable that you've never sort of used before. You've never written out var foo equals or const foo equals, but you try and use it in some kind of manner. So that's a pretty simple concept of what is undeclared. It's just you forgot something somewhere or you ripped out some code. In my case, you ripped out some of your co-workers code and now it's not working. So that's undeclared. Undefined is, it's a little bit different. Undefined means that you have declared it, but it doesn't have a value. It has not been assigned a value. So these are all up here at the top are all kind of examples of ways that you might get undefined. So if you just declare a variable, don't assign a value. If you have an empty object or you try and grab something on an object and it's not there, you'll see undefined. Same goes for like the index of an array, if nothing is there. Or if you run a function and the function doesn't return anything. So that, which is totally fine to do. Undefined is not, it's not always undeclared is sort of, something's gone wrong, but undefined you could get for all kinds of reasons not necessarily an indicator that something has gone wrong. The cool thing is with constant is that you can only use constant, whoa, look at that, sorry. You are forced with constant to assign a value to it whenever you declare it. So that may change actually the way that you wanna use things because in a lot of situations, I don't want to do that. I want to create a variable and then have it change depending on situations. So, but that is kind of nice because you'll never sort of have the problem of a constant being undefined. And then you have, oh yeah, I've got this whole list of important information. Oh, it's also falsi, which kind of plays into, that it's not necessarily an indicator that something's wrong. You can definitely use it in some kind of logic condition if you're looking for falsi. Null is a little bit different and it's kind of nuanced, but null is a value. It's just not a value, you know? Null is actually the interpreted as having a value, that value is null. It's a nothing value. It's a way of sort of creating a placeholder assignment for something that would have maybe other values. You see this all the time, especially like if you're dealing with an API, you might have something on an object that's returned from your API. You might see the key there and the key's value is null and that's completely right. And if you ever have a situation where you need to sort of zero out a value, null is a great tool in order to do that because the idea of zero as a number, well, that's actually a value or zero as a string, well, that's certainly a value. So you can use null instead. Yeah, look through my notes here. So finally, what the question is, if you, how do you go about checking for any of these states? Well, the first one is kind of easy. Undeclared will usually find you. I say usually, but it doesn't always find you because if you're trying to assign a value to a variable that hasn't been declared, JavaScript will totally let you do that and it will go ahead and attach that value to the global scope, which is really bad. So essentially all that stuff that I talked about, about not touching the global scope, JavaScript will let you just do that if you leave off the word var. So be careful, use a linter. That's what I would advise for there. And this is another one of the reasons why people hate JavaScript, about whatever, haters. Now if you wanna check for undefined, this also kind of sucks because if you check, you can use type of, it's really handy to check for like, if it's a number or if it's a string or whatever. If you try and do use type of, it will return undefined as a string, which is like frustrating because all of a sudden we're dealing with like this information that is in a different type than what it actually is. So you can't use type of this inequality checks because you've got this word undefined as a string. Undeclared variables will also return undefined if you try and type of them. Now I'm beginning to see why people hate JavaScript. So the preferred method would be to use a triple equals to check if something is undefined and not in a string, by the way, even though that doesn't make any sense because, yeah, anyway. So because if you look for undefined as a string and check it against undefined, even though this is what the console spits out, it will fail. So yes, check for undefined with triple equals and the reserved word undefined. With null, type of null actually returns an object. It will say that you have an object. This is a bug in JavaScript. This is a literal bug in JavaScript that they are not fixing because they have higher priorities. And by they, I mean me because it's a community. Like it all falls on all of our shoulders. So, but you can also use the triple equals with the reserved word null in order to check for null. And then finally, like this triple equals thing is just, it's always a great question. But what is the difference between double equals and triple equals? And so here's an example. Foo is undefined, bar is null, and foo double equals bar is true. Yeah, that makes sense. Essentially, what you have when you use double equals is a check for equality. And JavaScript sees null and undefined as both sort of having no value and says that those are equal even though they are not the same type of thing. So triple equals is always gonna check for equality and type. And if anybody here has like done any sort of like recent learning, I'm gonna, everybody loves audience participation, right? How many people have been told always use triple equals no matter what? You've been lied to, you've been lied to people. The reason people tell you that is because they don't think you're smart enough to understand it and use it correctly. But you can absolutely use this correctly. And if you know what you're doing and you want to use the double equals, go ahead and use it and put a little comma above it for the rest of your developers to like not go in and change your PR or be mad at you because you know what you're doing. So that's pretty much it. I'm gonna skip the event loop because it really deserves its own talk. I just had it in there because I thought that, yeah, nevermind. I knew I was not gonna have time for that, but just in case. So anyway, you guys, since you're at this talk, you are hired, hopefully you get a boss just as fun as Kimmy Schmidt's boss, wherever you go to work. And there are a ton more of these up on HTML5 boilerplate. It was a fun exercise for me to just go through these and be like, which of these can I not answer quickly and I cannot answer well? But I just want to sort of say at the end of this talk, I've been doing this for about five years and I've now sort of like the senior guy on my team and everything else, but it doesn't really, it doesn't really account for a whole lot necessarily that you can answer these questions like super well. My encouragement to anybody at this conference who's sort of like me feeling really overwhelmed and really like, I just don't know how I'm gonna actually apply this to my application coming the next day. I just really encourage you to just keep moving forward, building whatever it is that you're building. Just build good software. I think a lot of times as developers, we focus on the tools that we're using, the best way to use those tools, the most efficient way, which I totally get and totally love to do, but we lose sort of focus on like that we're here, we're getting paid to deliver bad ass software. And if we just focus on that, then the tools we use and the decisions and the learning is gonna come alongside that and happen as well. We don't have to like learn all this stuff first and have all these perfect answers or even really know the perfect terminology for what it is that we're doing in order to make awesome software. And I am a pretty good example of that because I won't say that I can make software without knowing whatever it is that I'm doing. So anyway, that's the talk, the slides are up on my website.