“Hoisting” is necessary for mutually recursive functions (and everything else that uses variable references in a circular manner): function even(n) { return n == 0 || !odd(n-1); } function odd(n) { return !even(n-1); } Without “hoisting”, the odd function would not be in scope for the even function. Languages that don’t support it require forward … Read more
What is happening here is that you are accessing window.name. This is a predefined property on window, so your hoisted var name isn’t actually creating a new variable. There’s already one in the global scope with that name and by default, it has a blank string value. To observe the behavior you were expecting, you … Read more
According to the web compat semantics at the place of the function declaration, the value of the blocked scope variable is bound to the outer scope². This code is equivalent to: let outerFoo; // the functions create a binding outside of the scope { let innerFoo; // but also inside // due to hoisting, functions … Read more
It’s not a matter of one taking precedence over the other (there is precedence taking place, but that’s largely just a matter of semantics). What matters here is that the assignment part of the variable declaration is not hoisted, whereas the entire function definition is. Functions are hoisted before variable declarations, but the net effect … Read more
Functions are a type of object which are a type of value. Values can be stored in variables (and properties, and passed as arguments to functions, etc). A function declaration: Creates a named function Creates a variable in the current scope with the same name as the function (unless such a variable already exists) Assigns … Read more
JavaScript hoisting within functions means that the declaration of variables are moved to the top of the function block. When you enter foo(), var boo is redeclared instantly even though you have not reached it (because the JS engine knows that this declaration exists within the function). Accordingly, the reason that it is undefined is … Read more
After doing some more research, I’ve found: Imports ARE hoisted! according to the spec of ModuleDeclarationInstantiation ALL the dependent Modules will be loaded before running any code. This code will have no errors, and will work: localFunc(); import {myFunc1} from ‘mymodule’; function localFunc() { // localFunc is hoisted myFunc1(); }
Yes, catch clauses indeed have their own Lexical Environments. Check out what happens when it is evaluated: It creates a new one (deriving from the current one) and binds the exception-identifier to it. When executing the catch block, the current Execution Context’s LexicalEnvironment is switched to the new one, while the VariableEnvironment(“whose environment record holds … Read more
You have just stumbled on a js “feature” called hoisting var myname = “global”; // global variable function func() { alert(myname); // “undefined” var myname = “local”; alert(myname); // “local” } func(); In this code when you define func the compiler looks at the function body. It sees that you are declaring a variable called … Read more
Yes, blocks are going to replace IEFEs, as soon as block-scoped declarations (functions, let/const/class) become widely adopted. You need a scope, e.g. for a closure? Here you have a block, be it a loop body or just part of a statement list. However, there is still one application of IEFEs that blocks cannot replace: the … Read more