The most important thing to understand about hoisting is that let and const don't have it. It's 2017, unless you are targeting very old browsers or working is some legacy code base, you should not use var ever again.
Senior Engineering Manager at GitHub, building APIs.
Passionate about fostering strong engineering cultures in distributed organizations.
Husband and dad of 4.
That's true, ES6 is the future and is what most developers will be using moving forward. That said, it's not entirely true that hoisting doesn't apply to let and const variables. It doesn't apply the same way as for var, but these let and const variables are still hoisted. The difference though is that they cannot be accessed until the assignment is done at runtime.
The variables are created when their containing Lexical Environment is instantiated but may not be accessed in any way until the variable’s LexicalBinding is evaluated.
At the end of the day, it's a small technicality where the interpreter applies hoisting to these variables on the compile run but they'll throw reference errors when accessed before the assignment happens, so your point is right :)
I'll update my post, thanks!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The most important thing to understand about hoisting is that let and const don't have it. It's 2017, unless you are targeting very old browsers or working is some legacy code base, you should not use var ever again.
Thanks for the feedback Daniel!
That's true, ES6 is the future and is what most developers will be using moving forward. That said, it's not entirely true that hoisting doesn't apply to
letandconstvariables. It doesn't apply the same way as forvar, but theseletandconstvariables are still hoisted. The difference though is that they cannot be accessed until the assignment is done at runtime.From ES6's documentation:
At the end of the day, it's a small technicality where the interpreter applies hoisting to these variables on the compile run but they'll throw reference errors when accessed before the assignment happens, so your point is right :)
I'll update my post, thanks!