Check out a free preview of the full Hard Parts: Functional JS Foundations course:
The "Closure Clarifications" Lesson is part of the full, Hard Parts: Functional JS Foundations course featured in this preview video. Here's what you'd learn in this lesson:

Will clarifies what it means in JavaScript to pass on code from one function to the next, and how code is stored in the heap.

Get Unlimited Access Now

Transcript from the "Closure Clarifications" Lesson

>> Will Sentance: I'm gonna bring it up as a little bonus. Here's what actually happens. There is actually, cuz Virginia asked, hold on, do we pass out the code? What does it mean to pass out the code from one function or other? Here's what it actually means. And I'm only giving this to you as a little bonus, people.

[00:00:16] Actually, in JavaScript, functions, objects and arrays, anything that's not like a number, string, Boolean, undefined, whatever. They ain't stored directly up here in our very, very tightly restricted direct memory here. Instead, they're stored in, and I'm gonna keep this somewhat simplified. Because in the end, we don't actually have to interface with this.

[00:00:40] We don't even necessarily need to know this, but it can give another way of looking at this that's gonna be clearer for some people. There's actually a special, very flexible, messy kind of put anything in there, store of memory called the Heap, behind the scenes in JavaScript, in most programming languages.

[00:00:55] And into here, it's actually, whenever we declare a function like add3, it ain't stored directly in this little local memory. Instead, it's stored down here in the Heap. So our add3 function, as soon as we declare it, we actually store it down here. This isn't global memory, this is a totally separate,

>> Will Sentance: A totally separate store of memory down here. There's our add3 function. We don't actually directly store the function here in the local memory. Instead we store, think of it as an address like a zip code, I don't know, 10012, to a position in the computer's memory down here where the function is actually stored.

[00:01:40] This should start to give you a little hint, Virginia, of your question. What actually happens when I return out add3, I look up add3, I don't grab the definitions code. I grab the link to the stored version down here that I created when I executed functionCreator and I return that out.

[00:02:00] So when I run generatedFunc, I go, what am I meant to do? What is, the function that was birthed as add3, but its label add3 was only one that was inside functionCreator. The function's code was more permanent, and that was stored in the Heap, but with a label that's not very meaningful to us.

[00:02:17] And so we passed out the label, the thing that points to this underlying stored function. Does that answer your question, Virginia? Do you wanna follow up to that?
>> Virginia: So then, if I go and execute functionCreator again with a new label, will it point to that same?
>> Will Sentance: Absolutely not, absolutely not.

[00:02:36] That's gonna run functionCreator again, create a brand new local memory inside of it, you create a brand new counter of 0 and a brand new add3 function which will be stored, I don't know, 10013, and a new copy of it, okay.
>> Virginia: So it'll be pointing to two different?

>> Will Sentance: Absolutely.
>> Virginia: Got it.
>> Will Sentance: Absolutely, so we didn't pass out. We did not return out the full code of add3. I talk about that metaphorically, when you grab all the code of add3 and store it into generatedFunc. Instead, we passed out a link to where add3 was stored in this messy total memory of JavaScript.

[00:03:08] Unrelated to global, it's not global memory. Cuz this is a hidden-behind-the-scenes memory in which all arrays, objects, and functions ever declared, they're all stored down here. And when we store up in the local memory and even in the global memory is a link to this single, shared store of, to this permanent store of memory down here.

[00:03:29] No, not permanent, to this store of memory down here that we don't get to interact with directly. And we just store links to those, meaning we can pass those links around, still linking back to the originally saved function. I don't always bring that up. Hope that's a nice little bonus for people.

[00:03:45] If that didn't make any sense, I don't think it matters. Just think of always we return out of a function, another function and all of its code, without its name, and store it into the new label globally generatedFunc. But now the question is, and people, we're starting to get to why we might do this.

[00:04:04] But why would I save a function inside another function only then to not use it inside that function and instead return it out?
>> Will Sentance: We're gonna get, delete that, we're gonna get [LAUGH] we're gonna get the most powerful, to be fair, that's just the title of this whole section so it's not.

[00:04:22] [LAUGH] I sort of gave it away from the start. We're gonna get super powers for this returned out function. So this returned out baby function is gonna get, the most powerful property in JavaScript, without a doubt. And the one that infiltrates everything, way more than just functional programming.

[00:04:38] This technique dominates asynchronous JavaScript and the persistence of states around asynchronous callbacks. It dominates iterators, generators are just as behind the scenes. Async or they're all just this behind the scenes. It is the most significant concept in JavaScript. It is my favorite. Its only more important concept out there is the event loop.

[00:04:59] This concept otherwise is the most dominant thing in all of JavaScript and it's honestly the most misunderstood, but it dominates everything.