hoisting

I am getting a very strange output on the below scenarios: function test(){ var test=123; console.log(test) } // this output : 123 (function test(){ var test=123; console.log(test) })() // this output: 123 But when using the below code (function test(){ test=123; console.log(test) })() //output: function test(){ test=123; console.log(test) } Can anybody please explain. What you're seeing isn't related to hoisting. Your first example is quite straightforward: (function test(){ var test=123; console.log(test) })() You're creating a variable (via var ) called test within the scope of the function

Ben Cherry's excellent article explains hoisting in JavaScript adequately. My problem, however, is that I cannot conceive a use case for this notorious perpetrator of confusion. Please explain if there is a design pattern that actually takes advantage of this language feature. Secondly, is scope hoisting unique to JavaScript? UPDATE --- I'm adding a bounty for an answer that satisfies my curiosity: Which design pattern(s) actually take advantage of JavaScript's hoisting behavior? I understand why JavaScript supports hoisting, but I want to know how I can take advantage of this feature .

function mymethod(){ alert("global mymethod"); } function mysecondmethod(){ alert("global mysecondmethod"); } function hoisting(){ alert(typeof mymethod); alert(typeof mysecondmethod); mymethod(); // local mymethod mysecondmethod(); // TypeError: undefined is not a function // mymethod AND the implementation get hoisted function mymethod(){ alert("local mymethod"); } // Only the variable mysecondmethod get's hoisted var mysecondmethod = function() { alert("local mysecondmethod"); }; } hoisting(); I am not able to understand how the hoisting works in this case and why alert("local

W.r.t Hoisting of fxn definitions. if (true) { function foo() { alert(1) } } else { function foo() { alert(2) } } foo() Chrome, some 2-3 months ago - would print 2. Now, it's printing 1. Did I miss something or, did console stop hoisting on fxn's! DEMO -- prints 1. I'm not sure where to find demo of the older browser version. Probably older v8 engine's node installation?. Current chrome version - 49 Bergi The code you have is invalid in strict mode. Functions don't get hoisted out of blocks (or at least they shouldn't), function declarations inside blocks were completely illegal until ES6. You

I read the concept of Javascript Hoisting.Its pretty confusing but I saw some examples and got the idea what hoisting actually does. So basically " Hoisting is JavaScript's default behavior of moving all declarations to the top of the current scope (to the top of the current script or the current function). " But I am not able to understand the below implementation : var is_android = true; if (is_android) { function foo() { alert('I am Android'); } } else { function foo() { alert('I am NOT Android'); } } foo(); The output shows " I am NOT Android " in alert box. I want to know why foo() is

I've been reading about JavaScript hoisting sometime back. JavaScript Scoping and Hoisting by Ben Cherry Two words about “hoisting” by Dmitry Soshnikov and, some more about JavaScript type-coercion, truth & false test: Truth, Equality and JavaScript and some other resource And while practicing some, and found I m missing some important concept about the hoisting and a variable' truthy & falsy. 1: 'if' truth test with duplicate variable declaration var foo = 1; function bar() { if (!foo) { alert('inside if'); var foo = 10; } } bar(); o/p: inside if Doubt: 'foo' value being '1', if(!foo) should

I’m trying to wrap my head around the behavior of reference errors thrown in JavaScript. In the following example, a ReferenceError is thrown at the second line, and execution breaks: var obj = {}; obj.func1 = func2; alert('Completed'); Whereas in this example, the code completes successfully, though obj.func1 remains undefined : var obj = {}; obj.func1 = func2; var func2 = function() { alert('func2'); }; alert('Completed'); My assumption was that an error would be thrown at the second line just the same, and when that wasn’t the case, I’d have expected obj.func1 to properly reference func2 ,