This is not about efficiency, but about a paradigm. If you are using a script paradigm, you can simply run it off without worries. If you use the classical paradigm, you need to define classes, but you do not need nested functions. However, in scripts and classic, you can use nested functions if you want.
Only if you move on to a functional paradigm, which is the actual โnativeโ javascript paradigm, in some cases you will need nested functions.
Until you use functional programming, you will not use the full power of javascript. This is an example factory that uses closures that cannot be done otherwise (there are several other uses for nested functions, not just closures):
function create(a, b) { function compute() { return a + b; } return { "compute": compute }; }
User code will do:
f = create(19, 73);
Without calculating anything. Let's say that it takes a lot of time to calculate this time, and you don't want to calculate it if necessary. Now you can pass the function f another code that does not belong to you (eG jQuery event handler code):
$("#id").on("click", function () { console.log(f()); });
This f will be executed when you press #id , but there is nothing you can do about it. Arguments a and b already implemented when calling create() .
This means that you can hide information and use contextual coverage. Imagine that the creator and user are two different code files not written by the same person. Or that a and b are secrets that should be kept as such from another code base.
Look at the various words that I sprinkled in the text above to learn more about functional programming.
If you want to know why we can't get around , look at currying and monads , which are fundamental elements of a functional paradigm. You need some mechanisms with which you can perform these basic operations, otherwise the paradigm may not be functional.