Check out a free preview of the full Deep JavaScript Foundations, v3 course:
The "Origin of Closure" Lesson is part of the full, Deep JavaScript Foundations, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Kyle discusses the context of closure in JavaScript in relation to functional programming languages. - https://static.frontendmasters.com/resources/2019-03-07-deep-javascript-v2/deep-js-foundations-v2.pdf

Get Unlimited Access Now

Transcript from the "Origin of Closure" Lesson

[00:00:00]
>> Kyle Simpson: We've been talking about lexical scope in this unit, and that is a foundational understanding to be able to jump into closure. How many of you have ever heard or given that interview question before, what is closure and then the answer seems to sort of fumble around like, something about asynchronous callbacks?

[00:00:22] I think closure is one of the most, it's certainly one of the most prevalent and maybe one of the most important ideas ever invented in computer science. In all fairness, I've mentioned a few times in this course that I have some disagreements with Doug, but he, Doug Crawford, has had a lot of really great things that he's done for our industry and a lot of things that he said.

[00:00:46] And when he says something brilliant, he deserves credit for it. Years ago, he had a conference talk that he was giving about computer science things that have been created over the course of the history of computer science. And he was making a point that, essentially, all great ideas take a whole generation of programmers before they get implemented, before they become popular.

[00:01:13] And he gave a variety of examples. And when he went to explain why that phenomenon exists, it was sort of a tongue in cheek kind of response or explanation, which is kind of half-true and half-funny. He said, well, the reason why it takes a full generation is because we're so stubborn.

[00:01:34] We're stuck in our ways. So we have to wait around for all of the current generation to die or retire llll before the new great idea picks up. [LAUGH] Again, it's like half-true and half-funny. But he went on to say we know that closure must be truly great cuz it took two full generations to catch on.

[00:01:56] [LAUGH] We really had to wait for a lot of people to die or retire. It's one of the most prevalent concepts in all of programming. And yet, when it was introduced in JavaScript in the mid to late 90s, it was somewhat of a revolutionary idea that we would take a language that was ostensibly designed for the common man, the consumer-oriented developer, not the academic.

[00:02:22] Designed for them, designed to build consumer-oriented applications and consumer-driven applications. Those sorts of languages didn't pick up on features, typically, that had only really been in academic languages. So closure was not new, that was around from the very beginning, very early days. In Lisp and other things like that.

[00:02:44] But it was somewhat of a divide, where there were features that were considered to be, no real developer, no non-academic developer will ever use something like closure, okay? And then in 1995, when Brendan Eich was hired to go to Netscape, the story goes that ostensibly he was going there and he was wanting to put scheme in the browser.

[00:03:09] Scheme being an old functional programming language. It is not necessarily an academic language, but I think it can arguably be an academic language in 1995. And so he wanted to put that in the browser. And the Netscape folks said, no, no, no, that'll never work. Nobody will ever write that language.

[00:03:29] You need to make a language that looks like Java. Now, I wasn't there, but I like to imagine in my mind that Brendan is sort of sauntering back to his disappointed, like, stupid Netscape won't let me put scheme on the browser. And then he has that light bulb idea and he says, I know what I'll do, I'll put scheme in the browser but I'll call it JavaScript.

[00:03:48] I'll make it look like Java and I'll call it JavaScript. And that's essentially what it is. That JavaScript is probably, in some respects, related to something like Scheme, than even to Java or C++. Yeah, we use curly braces and semicolons. And it's real hard. Some of those core concepts from functional programming languages were there, or at least planned, from really the day one of the language.

[00:04:13] And I think that's one of the reasons why JavaScript succeeded and survived, and thrived and became the ubiquitous language that it is today. Matter of fact, I like to suggest, essentially, that this was kind of accidental genius on his part. Not to disparage him in any way, but I don't think there's any possible way any human being could have imagined in 1995 that this little prototype language [LAUGH] would end up being as ubiquitous is today.

[00:04:42] That it is in TVs and refrigerators, and watches, and glasses, and light bulbs, and computers, and smartphones. Billions and billions of devices worldwide. Robots, I mean, I don't think you could have possibly imagined that the language would have served such a widespread use case. And I think a testament to it is because the language embraced an approachable syntax, or at least what was felt to be an approachable syntax at the time.

[00:05:13] But brought it some of the most powerful features that had ever been invented. In that case, closure. And it was really kind of one of the first major movers in that space. I mean, arguably, you could say that the only other language at the time that was really maybe starting to become more consumer-oriented and had closure would have been Pearl.

[00:05:33] So JavaScript's either the first or nearly the first language to move in that direction. And as things stand today, 24 years later, every single language has closure because it turns out that closure is just that important. And so with that foundation, then, it strikes me as troublesome that something that is so great and so pervasive is something that we still stumble over.

[00:06:01] And we can't even give a definition of. We can't even really give precise examples of. In fact, I'd go so far as to say every one of you that is a JavaScript developer, if you've written JavaScript for more than three hours, you have interacted with closure in some way, shape, or form.

[00:06:16] And in fact, most of you do it all the time, all day, every day without even realizing it, in various different paradigms. It's not only functional programming that uses closure, but closure is used in lots of different places. It's used for asynchronous AJAX. It's use for all sorts of different things.

[00:06:33] And so I want us to take a moment to be more precise about it. Now, closure as an idea is actually predating computer science, it actually comes to us from lambda calculus. This idea of closure, it even predates the idea of a programming language in that sense. And so if I were to try to show you a bunch of symbols and teach you lambda calculus, I am completely not up to that task.

[00:06:56] I have read the Wikipedia page for lambda calculus. I know it is a thing. I don't know anything about it. I don't understand it at all. And I have a CS background and I still don't get it. So it turns out that, at least from my perspective, the academic definition, the mathematical definition for closure, not useful.

[00:07:15] Matter of fact, even if you go to Wikipedia and you try to ask Wikipedia what is closure, or if you try to go to a computer science textbook and ask it, what is closure? I mean, I was taught those things in school, but none of that ever stuck.

[00:07:27] None of it ever clicked. So I'm gonna try to substitute a different definition, which instead of focusing on the academics, focuses on what we can observe in our programs that is different as a result of closure being a characteristic of the language. To understand this definition, you have to understand lexical scope.

[00:07:47] That's why we've built ourselves in this direction. We're headed towards the module pattern, and a step along the way is we've gotta understand closure. Can't get there if you don't understand lexical scope.