Hoisting

[00:00:00]
>> WebDevSimplified: Now hoisting is a concept in JavaScript that kind of plays around with making sure things work inside your scoping properly by taking certain things and moving them up inside your code. So normally when you want to use a variable, since JavaScript always executes your code from top to bottom, you define your variable and then you use it afterwards. Variable first, usage afterwards. If you try to flop that, for example, here, I try to define my variable B after I try to use it, I'm going to get an error because that variable is not defined yet because JavaScript always runs the code from top to bottom all the way down.

[00:00:30]
Functions are a little bit different though because JavaScript does something called hoisting. Essentially, if we look at this code here, you can see I define my function sum at the bottom of my code, and I call it at the top here. But this code, if we run it inside of the script here, this actually prints out 3. It runs just fine, and that's because JavaScript takes functions and treats them a little bit differently.

[00:00:50]
It does something called hoisting where essentially it takes your entire function and it moves it to the very top of whatever scope you're currently in. Generally that's going to be the file you're inside of. So JavaScript actually reads your code something like this where it moves your function to the top, so then you can use it later on in your code. This is a somewhat confusing topic because variables do not behave this way, but functions do.

[00:01:11]
So you can define functions anywhere you want and you can use them even before you actually define them. So you know, back when we had our code like this, even though our function was defined at the bottom, we can still use it at the top because JavaScript essentially moves that function to the top automatically for you. Now this is a little bit confusing behavior to understand how this works, and technically that's not exactly what's happening.

[00:01:30]
Like JavaScript doesn't physically move the code in your file, but when JavaScript reads your code, that's kind of how it views your particular code. Now what makes this even more confusing is arrow functions are not hoisted, but that's because arrow functions are variables. We talked about how you define them with a constant keyword, and since constant and let are not hoisted because variables are not hoisted, we don't get that same behavior.

[00:01:52]
So if I try to use this particular code, which is using an arrow function version here, I'm going to get an error on the side of my screen because variables, which are what arrow functions are made out of, do not get hoisted to the top of the file. So if you want to take advantage of hoisting for putting your files at the bottom or your functions at the bottom, sorry, you're going to want to use the normal function keyword.

[00:02:11]
Now again, this is a lot of extra confusing stuff that JavaScript throws on. We have 7 different ways to do the same thing and half of them work one way, half of them don't. So why do they have this hoisting thing? The main reason for hoisting to even exist is it makes your code much more flexible when you write it. Usually when you open up a brand new file of code, it's going to be much longer than this very simple example we have here.

[00:02:31]
You may have hundreds of lines of code, and usually what you want is you want the most important code in your file to be somewhere towards the top, so it's easy to find, and the less important code you want to have all the way at the very bottom of your file. So with hoisting that allows us to take these functions that are less important, put them at the bottom, even though we still want to use them at the top.

[00:02:51]
A quick example of this is just a really simple function that processes some user data, displays the results to the screen, and then cleans up any stuff behind the scenes. You can think of these functions as doing anything you want right now. They don't do anything, but you'll notice when I read my code, this is pretty easy to read. I can read these function names and I know generally what the program is going to do.

[00:03:09]
But the only reason this is able to work where I put this really important easy to read code at the top is because all these helper functions at the bottom, I'm able to put after I actually use them. So I can take all this stuff that I don't really care what process user data does. I just want to know we're processing the user data. So I put all this important stuff that's easy to read and understand at the top and then the more complicated implementation details that I probably don't really care about, I can put at the bottom.

[00:03:34]
So now when someone else comes and reads my code, they can just read these three lines at the top and know probably in general what my entire function and file does without having to read all these functions in line to figure out where the real code is. And this is my opinion, is the big benefit of actually using hoisting inside of JavaScript. Any questions about that concept? It's a relatively simple concept, but it definitely can be really tricky with what goes on.

[00:03:58]
Yeah, functions were implemented after traditional functions, correct? So why did they make that decision? Was there rationale as to why they wouldn't hoist? So the reason that they don't hoist arrow functions is because when you define an arrow function, you specifically use constant and let to define them, and they are defined with those keywords and those keywords themselves don't hoist. So like the function keyword is what tells JavaScript to hoist this thing, and constant let were created specifically not to be hoisted, so an arrow function says it uses constant or let is never going to be hoisted.

[00:04:28]
Generally, when I write my functions, I don't use arrow functions like this. Normally I would write this as a normal function, you know, with the traditional function keyword, as I find that's an easier way of writing certain functions like this, but some people use only arrow functions, so it's important to understand they don't hoist like a traditional function would. Is that viewed as a trade-off when they were designing arrow functions?

[00:04:50]
Is it just usability versus giving up hoisting, or is this intentional? Um, I'm not 100% sure what the rationale was. It's been a long time since arrow functions were implemented, but I believe since they wanted them to align perfectly with how constant let work, if they made like an exception where functions hoisted while other variables didn't, it would probably add more confusion than just making them so they don't hoist at all.

[00:05:12]
This might be a question that you covered earlier, but is the order of the functions important or is everything compiled? So if a function calls another function, is the order important? The order is only important if you're using arrow functions because they don't have that hoisting. But otherwise, no, it doesn't matter what order they are. So like for example in this code, we'll just bring this over.

[00:05:35]
Oops, there we go. So it doesn't matter. For example, if I put display result up above here or down below, and even if I wanted to, for example, call display result inside of here, that's still going to work fine even though it's defined or it's used before it's actually defined. It doesn't matter what order you do it in. That's another reason why hoisting is really important. Otherwise, you know, if I had this function calling one function and then this function was calling my process user data, for example, they would obviously, how would I know which order to put them in because they're referencing each other, but with hoisting it's just smart enough to know I have these functions available, so I don't have to worry about the fact of what order I put them in.

[00:06:11]
Is it a good practice to place a function call at the top of the code? So it depends a lot on what your code looks like, but generally I would say it's better to have your most important code at the top. If that means calling a function, then put a function call at the top. If that means doing something else, put that at the top. But generally when I'm writing my code, especially in like a simple JavaScript file like this, the top of my code is generally going to be a couple function calls or whatever the core piece of logic inside my code is like.

[00:06:34]
Think about it this way. When I open up this file, what is the most important thing for me to understand, to know what the code is doing? That's the thing you should put towards the top of your file if it makes sense. And then all the stuff that helps make that thing do what it does, such as functions for like formatting data or logging data to the screen, those can be put at the bottom because they're just helper pieces that make the main code work properly.

[00:00:00]
So that thing at the top may be a function call, it may be something else entirely. It really depends on what the main purpose of that code is.