6

A couple of days ago, I had an interview, and one of the questions was 'what is hoisting?' then I explained the hoisting concept thoroughly, then the interviewer asked me, 'what is the main advantage of hoisting?' I couldn't answer. Really what is the main advantage of hoisting in javascript?

S. Hesam
  • 5,266
  • 3
  • 37
  • 59
  • 1
    I really like the way function declaration is hoisted to the top of the scope with its value. So you don't have to worry about order of use and declaration. – Maheer Ali May 21 '19 at 07:08
  • @MaheerAli Yep, you can put the most abstract code at the top of the script that way, want to post that as an answer? (though for anything other than a function declaration, I can't think of a useful advantage) – CertainPerformance May 21 '19 at 07:10
  • @MaherAli that is the main concept of hoisting, not the main advantage. – S. Hesam May 21 '19 at 07:16
  • @CertainPerformance I heard from somebody that the advantage of hoisting is in the closure concept, Is it right? – S. Hesam May 21 '19 at 07:24
  • [Why does JavaScript hoist variables?](https://stackoverflow.com/questions/15005098) – adiga May 21 '19 at 07:25
  • The main advance of hoisting is to ask interview questions. – Epicurist May 21 '19 at 07:34
  • 5
    @Epicurist . . . Almost. The main advantage of hoisting is the ability to ask senseless and confusing interview questions about it. – Bart Hofland Dec 29 '20 at 12:55

5 Answers5

7

Convenience?

No really. It is convenient. Both to the reader of code as the coder themselves. Not so much for variable hoisting, but for function hoisting. This way you can put the helper functions to the bottom of your code and the more abstract ones which show your business logic at the top.

I like this answer on quora on the same topic https://www.quora.com/Why-does-JavaScript-hoist-variables

In other words, what happened was that JavaScript implemented hoisting of function declarations so that programmers would not be forced to place the inner-most functions at the top of the script block, and the outer-most (top-level) functions at the bottom. This order, which is forced in ML languages (such as LISP) is painful because programmers prefer reading code top-to-bottom, rather than bottom-to-top. Languages like C/C++ get around this issue by using header files, and standalone declarations, which JavaScript doesn’t have. Also, hoisting was required for implementing mutual recursion.

yunzen
  • 32,854
  • 11
  • 73
  • 106
  • 1
    You exclusively focus on function hoisting. What about regular variables? – deceze May 21 '19 at 07:29
  • Variable hoisting is more or less just a by-product of function hoisting. – yunzen May 21 '19 at 07:48
  • Which came first, the hen or the egg… – deceze May 21 '19 at 08:18
  • Functions are variables as well. Instead of `function foo() { ... }`, you could also write `var foo = function () { ... }`. So I see no technical difference between function hoisting and variable hoisting. That's just a kind of conceptual difference, I guess. – Bart Hofland Dec 25 '20 at 19:27
0

A name (variable name, function name) is scoped to its block. With var that's the function body, with let/const that's the closest enclosing {} block. Due to the nested scopes possible in Javascript, it must be clear which block a variable belongs to. If you mention var foo/let foo anywhere within a specific block, that block is reserved as the scope for this variable.

function () {
/**** scope of foo *****/
/*/
/*/ var foo;
/*/
/*/ function () {
/*/ /** scope of bar **/
/*/ /*/
/*/ /*/ var bar;
/*/ /*/
/*/ /******************/
/*/ }
/**********************/
}

It would be very confusing if the variable scope would only start at the exact line at which var ... is declared; then half the function would have one variable scope and half another. Hence, if var/let exists anywhere within a block, that name is hoisted to encompass the entire block.

deceze
  • 510,633
  • 85
  • 743
  • 889
0

Well, everything has its advantages and its disadvantages, but in this case, the disadvantages seem to outweigh the advantages.

In my opinion, hoisting makes the code harder to reason about. But that's just my opinion. When I write code, I want my bindings declared at the point in code where I declare them. That way, I get informed if I mistakenly use them before I declare them, for example. And I certainly do not want to accidentally declare them twice, which would be perfectly valid and perfectly confusing.

I would like the compiler/interpreter to help me when I do something stupid. Hoisting allows me to do too much convenient and/or stupid things, potentially resulting in hours of complex debugging sessions. So since ES6, I primarily use let and const instead of var. No hoisting for me if I can help it. ;)

So my answer to the question "What is the (main) advantage of hoisting?" would be: "I really don't care."

Edit:

Well, perhaps I am a little too harsh here. Function hoisting might actually be useful and convenient and improve readability of code. But within functions, I would avoid variable hoisting as much as possible.

Bart Hofland
  • 3,700
  • 1
  • 13
  • 22
0

Hosting is useful to create a chain of function calls. Like the ones RxJS offers

https://youtube.com/shorts/JTPozUVicGo?feature=share

Tom Smykowski
  • 25,487
  • 54
  • 159
  • 236
-2

Hoisting can be useful in some of the cases. For example we are creating a big project. It has alot of helper methods which are separated by putting then in another script. Now if they are declared using function declaration we don't have to worry about the order of scripts. Otherwise we could have issues.

Another use is that when we use recursion. Consider a function which prints numbers using recursion.

(function print(n){
  if(n === 0) return;
  console.log(n)
  print(n-1)
})(4);

Now if there wouldn't be any hoisting the code may have thrown error that print is not defined

Maheer Ali
  • 35,834
  • 5
  • 42
  • 73
  • 1
    Your example is not a demonstration of hoisting. – deceze May 21 '19 at 07:30
  • 1
    Sorry, n is defined already defined in the parameter list of the your recursion function and IMHO no hoisting is involved. – Epicurist May 21 '19 at 07:32
  • @deceze Can you please elaborate that? – Maheer Ali May 21 '19 at 07:34
  • Actually, the fact that your `print` function recursively calls itself also works fine without hoising: `const print = function (n) { if (n === 0) return; console.log(n); print(n - 1); };` is perfectly valid as well. Recursive functions might only become an issue if they are *mutually recursive*, like when function A calls function B and function B calls function A again. Without hoisting it will be tricky to create such functions. (First you would need to to create placeholder variables using `let` for both functions and then assign them their function bodies. That's not very intuitive.) – Bart Hofland Dec 29 '20 at 13:08