IMPORTANT: I want to make a few clarifications to this video based on some comments. 1. JavaScript does not actually move your code around before executing. I know I talk a lot about how JavaScript will act like it moves your functions to the top of your file, but it doesn't actually do this moving. In reality what happens is it first reads your code before executing the code so it knows which functions you have defined before executing. This is really not important, though, as all that matters is how the code actually works and not what happens with your code when the computer parses it. 2. One thing I did not mention in this video is how hoisting works within scopes. For example if you define a function called a and inside that a function you define another function called b the b function would only be hoisted to the top of the a function since the b function is inside the scope of the a function. I probably should have covered this, but this topic is more related to scoping which could be its entirely own video. 3. Technically, let and const are actually hoisted, but they are not initialized with a value which is why you get an error when trying to use them before they are declared. The code example people use to demonstrate this generally looks like this. function log(){ console.log(value) } let value = 1 log() //output: 1 In this example value is technically used above where it is declared, but it is used inside a function that is called after value is defined which is why there is no error. In some programming languages this would cause an error, but not in JavaScript. For these types of examples you can still use the top to bottom nature of JavaScript to understand what is happening and see why this works. First we define a function called log. None of the code in this function is executed when we define it so we can ignore the code in the function for now. Next we define a variable called value and set it to 1. Finally we call the log function we defined previously which prints out the variable value. As you can see from this top to bottom example the variable value is only ever used after it is defined which is why there is no error and for all intents and purposes you can treat let/const as if they are not hoisted since they are not able to be used before initialization like var/function. Now the reason I did not include all this information is for 2 reasons (I did not know some of it, and it is irrelevant). The point of this video is to help someone that does not understand hoisting understand what it is, how you can use it, and why it is important. I could have made this video 10-20 minutes long and talked about every edge case and technicality behind hoisting, but that needlessly bloats the video, makes things much more complicated for someone just learning hoisting, and goes against everything my channel is about. I called the channel Web Dev Simplified for a reason. I want to simplify the web for everyone and not worry about technicalities that don't impact how your program day to day. In my opinion this video covers all the main concepts behind hoisting without being too long or too complicated so that someone can easily watch this video and walk away with a solid understanding of what they need to know about hoisting to do work as a developer. For example, I had no idea that let and const were technically hoisted when making this video, but I have never ran into an issue where that information would have been relevant in my development career so it probably isn't important for me to teach in this video even if I did know it.
@@fluffyniki3257 If you believe this, then you severely underestimate how long it takes to make a video. Even a simple 5 minute video like this takes much longer than writing out a few paragraphs of text.
I suggest you re-upload the video. There are many missing points you did not cover as you already mentioned in your comment. The quick answer on the whats and hows of hoisting is "the two step compilation process". By that token you will also cover hoisted scopes. Just a suggestion. Don't get me wrong but your video now creates more confusion than it solves, especially for beginner javascript devs.
I would really recommend people going to the MDN documentation. There’s some weirdness of hoisting that they give good examples of. Especially in concern of block scopes.
Great and short read which makes a lot of sense! So it's basically: 1. for functions: Being able to use a variable's value in its scope before the line it is declared. ("Value hoisting") 2. for var: Being able to reference a variable in its scope before the line it is declared, without throwing a ReferenceError, but the value is always undefined. ("Declaration hoisting") 3. for let, const and class: The declaration of the variable causes behavior changes in its scope before the line in which it is declared.
Hoisting is a made up term that doesn't exist anywhere in the ECMAScript specification. It is a useful shortcut to explain why you can reference functions before their initialization but that's all it really is. The actual reason for this behavior is due to the two phases of the JavaScript interpreter. Here's a lot better explanation of "hoisting" by Brad on Traversy media: th-cam.com/video/Fd9VaW0M7K4/w-d-xo.html
You're quite right. If more developers understood the phases of the Global Execution Context, we wouldn't need terms like "hoisting." To your point, telling developers that hoisting is the equivalent of moving declarations to the top of the file, while easy to grasp, is also an incredibly inaccurate explanation of what's actually happening. In many ways, it fuels the confusion on this subject. Here I have the quirky advantage of being old. For a long long time, ALL interpreters needed a separate memory creation phase that preceded code execution. You had to know up front if you had enough memory to to store and act upon your objects and methods, otherwise there was no point in proceeding to runtime and very likely overflowing the execution stack. It's something young developers pretty much never need to think about or concern themselves with because memory space is generally so abundant, stable, and dirt cheap. That said, it consistently explains everything a modern developer would ever need to know about what we collectively call hoisting. By the way, technically, const and let ARE also "hoisted" to memory but just not to the global scope. They are waiting patiently for us in a special allocation we used to call "reserve memory" or a "reserved block" - what the official ECMA spec hilariously calls the "Temporal Dead Zone." But that's a whole other conversation. Cheers! ...and thanks for your great comment.
let and const are hoisted, it’s just they don’t get assigned a default value like var does. It’s an incredibly small detail, but it’s worth nothing if you truly want to understand hoisting.
2:34 - 3:00 let and const are hoisted MDN web docs: Variables declared with let and const are also hoisted but, unlike var, are not initialized with a default value. An exception will be thrown if a variable declared with let or const is read before it is initialized. Example: function foo(){ console.log(bar) } let bar = 1 foo(); //output: 1
Akshay Saini does a pretty good job at explaining hoisting in his Namaste Javascript series on youtube, and goes into detail about how the call stack works and why let and const are hoisted, but in a different manner than var
@@ashy7198 Written code: function foo(){ console.log(bar) } let bar = 1 foo() //output: 1 Equivalent code or when hoisting is applied: let bar function foo(){ console.log(bar) } bar = 1 foo() //output: 1 Another way of thinking about hoisting is that memory will be allocated for variables and functions before execution. If variables aren't hoisted then the code above would throw an error inside the function stating that bar is undeclared. Does this make sense? As mentioned by another comment, I recommend this video for a deeper dive on hoisting/execution context: th-cam.com/video/Fd9VaW0M7K4/w-d-xo.html
@@StrayKev If I am not mistaken here the reason for this is that while JavaScript is interperted is that it is ran twice, once for memory allocation and once for execution :)
let and const are actually hoisted, you get a reference error if you try to access them in their TDZ (i.e. Temporal Dead Zone) which is different from them not being hoisted at all
I would love if you could explain what you feel I did wrong or messed up in this video so I can correct it. I also added a pinned comment to this video with some clarifications based on comments.
When running the JS code, a global execution context is created. It is created in two phases: 1. Creation Phase Creation of the Variable Object Creation of the Scope Chain Setting the value of this keyword 2. Execution Phase Runs code line by line.
Doesn't this make using the function keyword somewhat superior to declaring functions with const? Except for being hip and ES6, what are the advantages to using const?
I would strongly recommend avoiding this. Hoisting is going to make your code harder to read. It's right up there with "import *" and global variables in making it really hard to see where a particular function or variable comes from. When ES6 introduced class declarations, they did remember to not allow hoisting even when done as a declaration ("class MyCLass{") instead of an expression ("const MyClass=class{"). They then went and immediately blew it by allowing blind imports with "import *" that obscure from which module an asset was imported. There's another problem with using the "function" keyword in general, either as declaration or expression: they can be treated as either methods or constructors. Especially for functions exported out into the big scary real world, you should allow a function to be a constructor OR a method, and never both. Class constructors will throw an error if they're called without the "new" keyword. Arrow functions will throw an error if called with the "new" keyword. What some gentle viewers might or might not know is that class methods and object methods also with throw errors if used with "new": class MyClass{ constructor(){ //This will throw if not called with "new" } aMethod(){ //This will throw if called with "new" even if separated from the class //such as with "const aMethod=MyClass.prototype.aMethod;new aMethod()" } } const someObject{ bMethod(){ //This will also throw if called with "new" even if separated from the object }, cMethod: function(){ //This will NOT throw if called with "new" because it's a pointer to a function //and not a class/object method }, } function dFunction(){ //This will not throw if called with or without "new" } const eArrow=()=>{ // this will throw if called with "new" } Arrow functions are a good idea for general-purpose methods. They have the characteristics of A) lexical (code-position) inheritance of "this" and B) inheritance of the "arguments" variable from the lexical scope as well. These are often either desired or not a problem, which is good, because JavaScript doesn't have a clean way to make just a method otherwise. I've used a few patterns, and this is ugly but as good as any: const {method}={method(){ // this will throw if called with "new" }} Finally, this can't be done with generators or async generators, and they're all technically constructors as they create the iterator object. Fortunately, "new" doesn't work with them, and you'll likely get a "not a constructor" error even though it is internally. The "this" value will even kindly work properly, even though the iterator object is not the same as the object holding the generator.
It all comes down to the history of JavaScript and how Var and Function is implemented. These constructs are members of the enclosing Function object or Global object - to which the variable is scoped. Vars are not scoped to blocks. Since JavaScript runs from top down the Var statement is not executed until the line is hit and the member not created until then. Function declarations are treated differently, detected when the code is parsed, and the identifier/name is hoisted. Let and Const are later inventions that are implemented a bit differently and don't result in members on the enclosing object. That is why they are not hoisted.
does hoisting breech the encapsulation barrier of frameworks like react/angular/etc? and please watch kevin's video about moving lines up and down (ALT + UP/Down to move the line up/down one line). it's driving me nuts haha
Comment made after watching a useful video so I don't forget what it was about #1. So, hoisting is like a hierarchy that JavaScript follows when some code is running, I mean, functions and var come on top of everything even when those are declared later butt const, let and more are the mortal ones and have to wait for their turn and, if they're called before they are declared, there's an error.
"var is probably something you should never use in programming" ... unless you prefer to use it and have used it way before let came along and it makes no difference to the way you code anyway, so go jump!
My work uses an old version of a js framework that can't be transpilled. And we require IE support. So we have to use var instead of let and const in our legacy front end.
And moral of this story - always use linter at strict mode, and don't anything creepy in you code, moreover at you teem code. Write so simple, that every junior developer can understand you code without disturbing you.
I don't think you're correct that const not being hoisted.. if that was true the error would be a reference error, not an initialize error.. const must be initialized;
why tf does JS has all of these weird names that you cant even guess anything about it from the name, so annoying. Like the most simple thing, problem, has a weird ass name.
Good simplified explanation. Brad at Traversy Media deep dives the JavaScript engine in his JavaScript Under The Hood series if you want a more thorough understanding of hoisting
I know there is a lot of recent hate for var because const and let are more precise in their scoping. That said, in my opinion, there are still valid use cases for choosing var over let. If you want to make sure a variable or variable-function is always scoped globally, var is still a good way to go. That, of course, gives rise to the argument against the use of globals in general but that's a separate debate. Global scoping actually removes code complexity if you use it properly and sparingly.
"...to make themselves seem smarter, like they know what they're talking about..." And then you talk about things you know nothing about. Sry, but it's better for you as a mediocre junior dev to learn things for yourself before trying to teach them.
I would love if you could explain what you feel I did wrong or messed up in this video so I can correct it. I also added a pinned comment to this video with some clarifications based on comments.
The way how hoisting works is that there is a creation phase when the code is executed where all declare values in certain scope are initilize. There is no moving code around.
Let & const are also hoisted but you got reference error by calling inside temporal dead zone. & JavaScript doesn't move any function at top of file it gets parsed into the memory while memory allocation process.
I read in the O'Reilly book that even import statements are hoisted: 10.3.2 ES6 Imports "By near-universal convention, the imports needed by a module are placed at the start of the module. Interestingly, however, this is not required: like function declarations, imports are hoisted to the top, and all imported values are available for any of the module's code runs."
Nice simplification of this topic, Kyle! As seen in the comments here, hoisting is one of those topics that mostly just let's the nerds come out and try and show how smart they are. Really, though, outside of job interviews, the concept is largely irrelevant. Not because it is not important, but because of how easy it is to spot and fix if you do get it wrong. Oh, got an error... 30 seconds later, oh, just need to move this line above that line...done. Not a big deal (unless you just want to show how smart you are by blasting a brilliant TH-camr).
Hey kyle, I am big fan the way you describe the issue, many ideas and pr i resolved after watching your tuts, I have an request can you make a tutorial on @mentions, that we find on any chat app, how we can do this? Thanks very much for your effort.
All this time I thought undefined variables just return undefined, but actually they only return undefined if you declare it somewhere otherwise that's an error
Actually i can say this is very important because i was having interview about hoisting and they gave me the same tricky questions It's a very popular question on javascript interview
Kyle - I think you did a great job, and I think you're right. The point of a video like this is to give the general overview to someone who does not understand what the concept is and to simplify it. If they would like to know more, there are always docs that they can go look at elsewhere. I also know you like to do your blog posts so I'm sure you will do one at some point on this topic if you haven't already. All in all, disregard the people who have to make it such a big deal to write negative comments when you clearly created such an amazing channel that has helped individuals like me learn way more than I ever thought I could learn without formalized education. Keep it up, my man!
You shouldn't encourage him to ignore feedback. He's explaining why it works like that, the details matter. And for someone who focuses most of his time on cringe thumbnails and very opinionated topics you'd think he can manage less than constructive feedback.
I agree. This video is awesome. Everyone needs to freaking chill. Kyle does really amazing work and thanks to him, I was able to learm faster and get a job.
My opinion: 1. Consistency with the rest of the syntax. Treat functions as any other type (string, number, object, etc.). I like to only use arrow functions in my code. 2. No function scope. Virtually everyone agrees that we shouldn't use 'var', so let's apply the same standard to functions. 3. Arrow functions doesn't bind 'this'. 'this' has a lot of weirdness and I find it easiest to just not use it at all. That means no usage of 'function', 'new', or 'class'. These features are just not needed. Use closures instead. Closures is largely what makes JavaScript an amazing language. There's generally no reason to hoist stuff. When you export arrow functions from modules, the order of the function declarations doesn't matter anyways. When you declare functions within another function, just use arrow functions and limit yourself to block scopes. So I'd only use arrow functions and never use 'function'.
Named function doesn't get moved to the top of the file rather it's copied within the memory itself and the same for const and let, it's just they are not assigned a value until and unless the program run. The steps are like 1. copy named functions and all the const, let and var to the memory 2. then run the run code from the memory
More in depth hoisting is due to LFS = RHS reference, javascript act as compiler where they will define LFS (left hand side) first prior code execution
Pro tip: You can use ALT + up/down to move line of code up or down instead of cutting and pasting Btw very good video, it really helped to understand the topic
I understand you are eager to share learning tips, but you should make sure to share the correct information. You have done this on more than one occasion.
IMPORTANT: I want to make a few clarifications to this video based on some comments.
1. JavaScript does not actually move your code around before executing. I know I talk a lot about how JavaScript will act like it moves your functions to the top of your file, but it doesn't actually do this moving. In reality what happens is it first reads your code before executing the code so it knows which functions you have defined before executing. This is really not important, though, as all that matters is how the code actually works and not what happens with your code when the computer parses it.
2. One thing I did not mention in this video is how hoisting works within scopes. For example if you define a function called a and inside that a function you define another function called b the b function would only be hoisted to the top of the a function since the b function is inside the scope of the a function. I probably should have covered this, but this topic is more related to scoping which could be its entirely own video.
3. Technically, let and const are actually hoisted, but they are not initialized with a value which is why you get an error when trying to use them before they are declared. The code example people use to demonstrate this generally looks like this.
function log(){
console.log(value)
}
let value = 1
log() //output: 1
In this example value is technically used above where it is declared, but it is used inside a function that is called after value is defined which is why there is no error. In some programming languages this would cause an error, but not in JavaScript. For these types of examples you can still use the top to bottom nature of JavaScript to understand what is happening and see why this works. First we define a function called log. None of the code in this function is executed when we define it so we can ignore the code in the function for now. Next we define a variable called value and set it to 1. Finally we call the log function we defined previously which prints out the variable value. As you can see from this top to bottom example the variable value is only ever used after it is defined which is why there is no error and for all intents and purposes you can treat let/const as if they are not hoisted since they are not able to be used before initialization like var/function.
Now the reason I did not include all this information is for 2 reasons (I did not know some of it, and it is irrelevant). The point of this video is to help someone that does not understand hoisting understand what it is, how you can use it, and why it is important. I could have made this video 10-20 minutes long and talked about every edge case and technicality behind hoisting, but that needlessly bloats the video, makes things much more complicated for someone just learning hoisting, and goes against everything my channel is about. I called the channel Web Dev Simplified for a reason. I want to simplify the web for everyone and not worry about technicalities that don't impact how your program day to day.
In my opinion this video covers all the main concepts behind hoisting without being too long or too complicated so that someone can easily watch this video and walk away with a solid understanding of what they need to know about hoisting to do work as a developer. For example, I had no idea that let and const were technically hoisted when making this video, but I have never ran into an issue where that information would have been relevant in my development career so it probably isn't important for me to teach in this video even if I did know it.
I bet it took you to write this comment longer than making this video 😆
Thanks for the extra info Kyle!
@@fluffyniki3257 If you believe this, then you severely underestimate how long it takes to make a video. Even a simple 5 minute video like this takes much longer than writing out a few paragraphs of text.
I suggest you re-upload the video. There are many missing points you did not cover as you already mentioned in your comment. The quick answer on the whats and hows of hoisting is "the two step compilation process". By that token you will also cover hoisted scopes. Just a suggestion. Don't get me wrong but your video now creates more confusion than it solves, especially for beginner javascript devs.
Great stuff, as always, Kyle. Just fyi, the expression is "for all intents and purposes."
I would really recommend people going to the MDN documentation. There’s some weirdness of hoisting that they give good examples of. Especially in concern of block scopes.
Exactly 💯
Great and short read which makes a lot of sense!
So it's basically:
1. for functions:
Being able to use a variable's value in its scope before the line it is declared. ("Value hoisting")
2. for var:
Being able to reference a variable in its scope before the line it is declared, without throwing a ReferenceError, but the value is always undefined. ("Declaration hoisting")
3. for let, const and class:
The declaration of the variable causes behavior changes in its scope before the line in which it is declared.
Oh, isn't that common sense though?
Not really
Hoisting is a made up term that doesn't exist anywhere in the ECMAScript specification. It is a useful shortcut to explain why you can reference functions before their initialization but that's all it really is. The actual reason for this behavior is due to the two phases of the JavaScript interpreter. Here's a lot better explanation of "hoisting" by Brad on Traversy media: th-cam.com/video/Fd9VaW0M7K4/w-d-xo.html
Really useful, thanks for sharing it.
You're quite right. If more developers understood the phases of the Global Execution Context, we wouldn't need terms like "hoisting." To your point, telling developers that hoisting is the equivalent of moving declarations to the top of the file, while easy to grasp, is also an incredibly inaccurate explanation of what's actually happening. In many ways, it fuels the confusion on this subject. Here I have the quirky advantage of being old. For a long long time, ALL interpreters needed a separate memory creation phase that preceded code execution. You had to know up front if you had enough memory to to store and act upon your objects and methods, otherwise there was no point in proceeding to runtime and very likely overflowing the execution stack. It's something young developers pretty much never need to think about or concern themselves with because memory space is generally so abundant, stable, and dirt cheap. That said, it consistently explains everything a modern developer would ever need to know about what we collectively call hoisting. By the way, technically, const and let ARE also "hoisted" to memory but just not to the global scope. They are waiting patiently for us in a special allocation we used to call "reserve memory" or a "reserved block" - what the official ECMA spec hilariously calls the "Temporal Dead Zone." But that's a whole other conversation. Cheers! ...and thanks for your great comment.
let and const are hoisted, it’s just they don’t get assigned a default value like var does. It’s an incredibly small detail, but it’s worth nothing if you truly want to understand hoisting.
2:34 - 3:00 let and const are hoisted
MDN web docs:
Variables declared with let and const are also hoisted but, unlike var, are not initialized with a default value. An exception will be thrown if a variable declared with let or const is read before it is initialized.
Example:
function foo(){
console.log(bar)
}
let bar = 1
foo(); //output: 1
Akshay Saini does a pretty good job at explaining hoisting in his Namaste Javascript series on youtube, and goes into detail about how the call stack works and why let and const are hoisted, but in a different manner than var
if they are hoisted but not initialized, isnt that just the same as them not being hoisted in the first place? Or am i missing something?
@@ashy7198
Written code:
function foo(){
console.log(bar)
}
let bar = 1
foo() //output: 1
Equivalent code or when hoisting is applied:
let bar
function foo(){
console.log(bar)
}
bar = 1
foo() //output: 1
Another way of thinking about hoisting is that memory will be allocated for variables and functions before execution. If variables aren't hoisted then the code above would throw an error inside the function stating that bar is undeclared.
Does this make sense?
As mentioned by another comment, I recommend this video for a deeper dive on hoisting/execution context: th-cam.com/video/Fd9VaW0M7K4/w-d-xo.html
@@StrayKev yes! That does make sense thanks for clearing that up for me 🙂
@@StrayKev If I am not mistaken here the reason for this is that while JavaScript is interperted is that it is ran twice, once for memory allocation and once for execution :)
let and const are actually hoisted, you get a reference error if you try to access them in their TDZ (i.e. Temporal Dead Zone) which is different from them not being hoisted at all
Make sure you know what you are talking about before making a video. You are that dude in 00:03
I would love if you could explain what you feel I did wrong or messed up in this video so I can correct it. I also added a pinned comment to this video with some clarifications based on comments.
When running the JS code, a global execution context is created. It is created in two phases:
1. Creation Phase
Creation of the Variable Object
Creation of the Scope Chain
Setting the value of this keyword
2. Execution Phase
Runs code line by line.
This is the correct answer. I was about to post this as well.
Thank you for rectifying that.
@@robertholtz welcome
@@its_maalik thanks
Doesn't this make using the function keyword somewhat superior to declaring functions with const? Except for being hip and ES6, what are the advantages to using const?
Not changing 'this' when needed, for example if 'this' is something else than window
Thanks Kyle! Best tutorial ever!
Bruh atleast watch the full video.
He said 5 mins not 18 seconds
Video came out 2 minutes ago. How have you even watched it so quickly smh
Yeah right
@@adarsh-chakraborty I'm watching the full video, but I'm always here in the comments section commenting, as always.
Web Dev Challenge-Ethiopia
I would strongly recommend avoiding this. Hoisting is going to make your code harder to read. It's right up there with "import *" and global variables in making it really hard to see where a particular function or variable comes from. When ES6 introduced class declarations, they did remember to not allow hoisting even when done as a declaration ("class MyCLass{") instead of an expression ("const MyClass=class{"). They then went and immediately blew it by allowing blind imports with "import *" that obscure from which module an asset was imported.
There's another problem with using the "function" keyword in general, either as declaration or expression: they can be treated as either methods or constructors. Especially for functions exported out into the big scary real world, you should allow a function to be a constructor OR a method, and never both. Class constructors will throw an error if they're called without the "new" keyword. Arrow functions will throw an error if called with the "new" keyword. What some gentle viewers might or might not know is that class methods and object methods also with throw errors if used with "new":
class MyClass{
constructor(){
//This will throw if not called with "new"
}
aMethod(){
//This will throw if called with "new" even if separated from the class
//such as with "const aMethod=MyClass.prototype.aMethod;new aMethod()"
}
}
const someObject{
bMethod(){
//This will also throw if called with "new" even if separated from the object
},
cMethod: function(){
//This will NOT throw if called with "new" because it's a pointer to a function
//and not a class/object method
},
}
function dFunction(){
//This will not throw if called with or without "new"
}
const eArrow=()=>{
// this will throw if called with "new"
}
Arrow functions are a good idea for general-purpose methods. They have the characteristics of A) lexical (code-position) inheritance of "this" and B) inheritance of the "arguments" variable from the lexical scope as well. These are often either desired or not a problem, which is good, because JavaScript doesn't have a clean way to make just a method otherwise. I've used a few patterns, and this is ugly but as good as any:
const {method}={method(){
// this will throw if called with "new"
}}
Finally, this can't be done with generators or async generators, and they're all technically constructors as they create the iterator object. Fortunately, "new" doesn't work with them, and you'll likely get a "not a constructor" error even though it is internally. The "this" value will even kindly work properly, even though the iterator object is not the same as the object holding the generator.
It all comes down to the history of JavaScript and how Var and Function is implemented. These constructs are members of the enclosing Function object or Global object - to which the variable is scoped. Vars are not scoped to blocks.
Since JavaScript runs from top down the Var statement is not executed until the line is hit and the member not created until then. Function declarations are treated differently, detected when the code is parsed, and the identifier/name is hoisted. Let and Const are later inventions that are implemented a bit differently and don't result in members on the enclosing object. That is why they are not hoisted.
does hoisting breech the encapsulation barrier of frameworks like react/angular/etc?
and please watch kevin's video about moving lines up and down (ALT + UP/Down to move the line up/down one line). it's driving me nuts haha
Comment made after watching a useful video so I don't forget what it was about #1.
So, hoisting is like a hierarchy that JavaScript follows when some code is running, I mean, functions and var come on top of everything even when those are declared later butt const, let and more are the mortal ones and have to wait for their turn and, if they're called before they are declared, there's an error.
JS dev: I made this language that lets you write your own code!
JS dev: also it changes your code without your consent! 😈
Last example is wrong. When you log a before define, javascript checks window.a which is undefined
i kinda understanded hoisting before this video, but now i understand it completely (me dumb basically)
"var is probably something you should never use in programming" ... unless you prefer to use it and have used it way before let came along and it makes no difference to the way you code anyway, so go jump!
My work uses an old version of a js framework that can't be transpilled. And we require IE support.
So we have to use var instead of let and const in our legacy front end.
You talk waaay to fast bro. JS is hard enough to understand without you talking 100 MPH!
And moral of this story - always use linter at strict mode, and don't anything creepy in you code, moreover at you teem code. Write so simple, that every junior developer can understand you code without disturbing you.
Very basic, but it's always good to refresh your basics
As always super clean and concise in explaining the concepts; you are great!
I don't think you're correct that const not being hoisted.. if that was true the error would be a reference error, not an initialize error.. const must be initialized;
great video can you give me roadmap for javascript I want to be a backend devs with this javascript spell
why tf does JS has all of these weird names that you cant even guess anything about it from the name, so annoying. Like the most simple thing, problem, has a weird ass name.
Actually it doesnt move any code, but reads code before running and save in memory.
very clean explaination !
Good simplified explanation. Brad at Traversy Media deep dives the JavaScript engine in his JavaScript Under The Hood series if you want a more thorough understanding of hoisting
have u got a link mate?
@@noy1009 th-cam.com/video/Fd9VaW0M7K4/w-d-xo.html
The real lesson here is to use const to define functions so that you don't get unexpected or confusing behavior, as you highlight at 1:18
Kyle, ignore the idiots posting the criticism. If they know this stuff they dont even need to be watching this vid
Thanks.
Am i only one who thinks Kyle is pretty much suitable for Peter Parker 😅
I know there is a lot of recent hate for var because const and let are more precise in their scoping. That said, in my opinion, there are still valid use cases for choosing var over let. If you want to make sure a variable or variable-function is always scoped globally, var is still a good way to go. That, of course, gives rise to the argument against the use of globals in general but that's a separate debate. Global scoping actually removes code complexity if you use it properly and sparingly.
and now that you spoke about hoisting, can you talk a bit about hosting - ie websites to host for beginners please.
Functions are not moved to the top but it's declaration is hoisted to the top, the function code remains where it is.
let and const variables are hoisted, only they are hoisted without a default initialization.
just when you think javascript cannot get any worse, but it does
Please do more on closures and other weird parts of js
It is good but also Watch Akshay saini series on javascript
I understood hoisting just from the thumbnail alone :o
A daily dose of Web Dev Simplified makes one a better programmer
"...to make themselves seem smarter, like they know what they're talking about..."
And then you talk about things you know nothing about. Sry, but it's better for you as a mediocre junior dev to learn things for yourself before trying to teach them.
I would love if you could explain what you feel I did wrong or messed up in this video so I can correct it. I also added a pinned comment to this video with some clarifications based on comments.
This video feels emotionally motivated
Which isn't a bad thing if it is
If anyone wants to deep dive just look for "namaste js"
The way how hoisting works is that there is a creation phase when the code is executed where all declare values in certain scope are initilize. There is no moving code around.
Regardless, this creation phase is hidden from the programmer. It is essentially a program that runs outside your program which you can't switch off.
Ukraine. коментар заради коментара
Thanks, I didn't know it was called 'hoisting'
you got a Jackson, you are aa Metaliprogrammer
The first video of yours that I did not like...
Really good explanation about the topic, also i really love your content, you are helping me become a greater developer, thanks Kyle
Do you play the guitar intro in your videos?
Thank u ,
Teach a man how hoist and he will have func for life
This is a common interview question!!
Is a function defined in another function hoisted?
It's very easy to understand thank you so much for your explanation about hosting 😊👌🏼👌🏼👌🏼👌🏼👌🏼
hoisting is definitely an interview question for EVERY js programmer, followed by "this", hhhhhh
brooooooooooo..........you can explain so nicely!
Let & const are also hoisted but you got reference error by calling inside temporal dead zone. & JavaScript doesn't move any function at top of file it gets parsed into the memory while memory allocation process.
u break down evry complex concepts..keep uploading more such js vid.!!!!!! huge respect...
You are really dope at explaining
Isn’t this just basic concepts that you learn on languages like C?
You don't know what you are talking about.
Good to know but let’s declare shit before we call it. Ps. Sick axe. Play me some Def Leppard!
helpful. i wish i click earlier .
I read in the O'Reilly book that even import statements are hoisted:
10.3.2 ES6 Imports
"By near-universal convention, the imports needed by a module are placed at the start of the module. Interestingly, however, this is not required: like function declarations, imports are hoisted to the top, and all imported values are available for any of the module's code runs."
i really like your videos bro
we love not only your course😁
make more videos like this.....
Nice simplification of this topic, Kyle! As seen in the comments here, hoisting is one of those topics that mostly just let's the nerds come out and try and show how smart they are. Really, though, outside of job interviews, the concept is largely irrelevant. Not because it is not important, but because of how easy it is to spot and fix if you do get it wrong. Oh, got an error... 30 seconds later, oh, just need to move this line above that line...done. Not a big deal (unless you just want to show how smart you are by blasting a brilliant TH-camr).
Hey Kyle...awesome lesson. Thanks. Can you tell me how you skipped using semicolons in your file.
Good at teaching code and styling your hair. Very informative video with great explanations:)
You are wonderful Kyle❤
IMO Hoisting makes js more unintuitiv and harder to debug, a clear error because would be much nicer.
Effective explanation
Hey kyle, I am big fan the way you describe the issue, many ideas and pr i resolved after watching your tuts, I have an request can you make a tutorial on @mentions, that we find on any chat app, how we can do this?
Thanks very much for your effort.
All this time I thought undefined variables just return undefined, but actually they only return undefined if you declare it somewhere otherwise that's an error
Actually i can say this is very important because i was having interview about hoisting and they gave me the same tricky questions
It's a very popular question on javascript interview
You are awesome, thank a lot
Kyle - I think you did a great job, and I think you're right. The point of a video like this is to give the general overview to someone who does not understand what the concept is and to simplify it. If they would like to know more, there are always docs that they can go look at elsewhere. I also know you like to do your blog posts so I'm sure you will do one at some point on this topic if you haven't already. All in all, disregard the people who have to make it such a big deal to write negative comments when you clearly created such an amazing channel that has helped individuals like me learn way more than I ever thought I could learn without formalized education. Keep it up, my man!
You shouldn't encourage him to ignore feedback. He's explaining why it works like that, the details matter. And for someone who focuses most of his time on cringe thumbnails and very opinionated topics you'd think he can manage less than constructive feedback.
I agree. This video is awesome. Everyone needs to freaking chill. Kyle does really amazing work and thanks to him, I was able to learm faster and get a job.
Thanks bruh
looking forward to see more videos of yours
OH! MY! GOD!
WOW! just WOW!
Great explanation :)
Namaste JavaScript described in more details. @akshay_saini
So what's the advantage of using const for functions? Only when you don't want it hoisted and if so when would that be?
My opinion:
1. Consistency with the rest of the syntax. Treat functions as any other type (string, number, object, etc.). I like to only use arrow functions in my code.
2. No function scope. Virtually everyone agrees that we shouldn't use 'var', so let's apply the same standard to functions.
3. Arrow functions doesn't bind 'this'. 'this' has a lot of weirdness and I find it easiest to just not use it at all. That means no usage of 'function', 'new', or 'class'. These features are just not needed. Use closures instead. Closures is largely what makes JavaScript an amazing language.
There's generally no reason to hoist stuff. When you export arrow functions from modules, the order of the function declarations doesn't matter anyways. When you declare functions within another function, just use arrow functions and limit yourself to block scopes. So I'd only use arrow functions and never use 'function'.
@@majorhumbert676 thanks for awesome reply. It's cool when people are so helpful just to be nice
@@nickthequick13 It's my pleasure
why i love HTML & CSS & JS
As always aswome video.
Helpful 💕
Thankyou sir
Ty sir!
Named function doesn't get moved to the top of the file rather it's copied within the memory itself and the same for const and let, it's just they are not assigned a value until and unless the program run.
The steps are like 1. copy named functions and all the const, let and var to the memory
2. then run the run code from the memory
Coming from Java, this makes absolutely sense :)
More in depth hoisting is due to LFS = RHS reference, javascript act as compiler where they will define LFS (left hand side) first prior code execution
Pro tip: You can use ALT + up/down to move line of code up or down instead of cutting and pasting
Btw very good video, it really helped to understand the topic
@Jojo there's nothing wrong with saying you can do this... anyway, protip: get out and talk to some real people
@Jojo i wonder why you thought of saying this
@Jojo I wonder if your name is a jojo reference
You can press alt and wherever you click will be cursor
Or was it ctrl 🤔
@@fluffyniki3257 You made me think again. I checked again and it is definitely ALT. Pressing Ctrl does not move line. It only moves screen up/down
perfect as ever you
Love you bro 🥰🥰🥰🥰
Well I learned something new today. Thanks for the great vid.
yo, you got any guitar videos? I’d love to see web dev simplified shred it up haha
I understand you are eager to share learning tips, but you should make sure to share the correct information. You have done this on more than one occasion.