Now that the rest of scope has been explained, this chapter has the freedom to genuinely focus on closures. It makes a nice capstone on the previous conversation!
Big Picture
I think you could combine this with the intro, just dropping the headline, and improve the flow a bit. (It still feels like intro text.)
See the Closure
This is getting into copyediting, but:
"First, closure is a behavioral characteristic of functions."
I'm wondering if this could be more easily stated "First, closure is a behavior of functions, and only of functions."
"the completion of each lookupStudent(..) call would immediately tear down its scope and GC the students and studentID variables"
This reminds me of a strange conversation I had years ago with someone at Fluent, or maybe OSCON? Not an amateur in any case. He insisted that these kinds of behaviors were the root of JavaScript memory leaks, and that the cost of using closures was too high. A sentence or two allaying those fears might be useful to avoid future similar oddities.
The example is good. I spent a lot of time going back and forth between the text and the example. Normally I would complain about that level, but I'm not sure that work is avoidable given that creating a closure requires code of a certain complexity.
Pointed Closure
Thanks for noting this, even though it's a small thing that doesn't affect this outcome.
Adding Up Closures
I go back and forth on this, but because it's a smaller and maybe more familiar example, it might make sense to put it before See the Closure.
Live Link, Not a Snapshot
Architecturally, this seems (to me at least) like the most important aspect of closures. Could you extend the second paragraph with some of the excitement, with a few sentences about the kinds of possibilities it opens? You demonstrate a lot of them later in the chapter, but getting readers motivated here might help them reach those magical moments.
"Though the enclosing scope of a closure is typically from function, that's not actually required"
I had to read this a few times, for a missing word in "from function", but I think the missing word is just "a".
"Because closure is not a snapshot of a value, but rather a live link to a variable, developers sometimes get tripped up trying to use closure to preserve a desired value."
How were you watching me the first few times I was trying to work with closures?
Common Closures
Maybe put Async and Event Handling right in the section title?
What If I Can't See It?
Part of me thinks this section is a weird distraction, but a larger part of me thinks it's necessary, and may prove useful to people who can't figure out why their code isn't working the way they think it should.
Observable Definition
This is solid, and I think the bullet points make it much clearer.
The Closure Lifecycle
This material is great, but I'd call out the impact on garbage collection in the headline. This gets back to the strange memory leaks conversation I noted above. There's good news here, but not all good news!
Per Variable or Per Scope?
This is a great discussion of how various engines handle (or don't handle) closure. My only question is how/if it applies to more common situations like the async and event handling examples given earlier. Those are a lot more common.
An Alternate Perspective
I'd love to see "we simplify explanation of closure to a straightforward combination of references and in-place function instances." somewhere near the front of the chapter. You do a great job of building to that conclusion, but I worry that the readers who need it most may not stick that far on something labeled "alternate". The magic then works as the glorious conclusion of the build-up.
Why Closure?
First example: how did you steal my typical event-handling code? No need to answer - I know my mistakes are not unusual.
There's a hanging reference - "(related: currying)". I think experienced developers will know why you put it there, but I don't think you can safely count on that. I'd suggest making that "related to currying" without the parentheses, and then use a parenthetical sentence at the end of the paragraph to explain currying briefly, at least enough to hold them for now.
Closer to Closure
Consider stealing the "Let's consider what closure does for our programs" list from the section above and using it to open this closing section. The second-to-last paragraph echoes the bullets, but the bullets are easier. ("Closer" is a neat double-meaning in the headline, too.)
Editorial review, not a searchable issue.
Edition: (1st or 2nd) 2nd
Book Title: Scope & Closures
Chapter: 7
General
Now that the rest of scope has been explained, this chapter has the freedom to genuinely focus on closures. It makes a nice capstone on the previous conversation!
Big Picture
I think you could combine this with the intro, just dropping the headline, and improve the flow a bit. (It still feels like intro text.)
See the Closure
This is getting into copyediting, but:
I'm wondering if this could be more easily stated "First, closure is a behavior of functions, and only of functions."
This reminds me of a strange conversation I had years ago with someone at Fluent, or maybe OSCON? Not an amateur in any case. He insisted that these kinds of behaviors were the root of JavaScript memory leaks, and that the cost of using closures was too high. A sentence or two allaying those fears might be useful to avoid future similar oddities.
The example is good. I spent a lot of time going back and forth between the text and the example. Normally I would complain about that level, but I'm not sure that work is avoidable given that creating a closure requires code of a certain complexity.
Pointed Closure
Thanks for noting this, even though it's a small thing that doesn't affect this outcome.
Adding Up Closures
I go back and forth on this, but because it's a smaller and maybe more familiar example, it might make sense to put it before See the Closure.
Live Link, Not a Snapshot
Architecturally, this seems (to me at least) like the most important aspect of closures. Could you extend the second paragraph with some of the excitement, with a few sentences about the kinds of possibilities it opens? You demonstrate a lot of them later in the chapter, but getting readers motivated here might help them reach those magical moments.
I had to read this a few times, for a missing word in "from function", but I think the missing word is just "a".
How were you watching me the first few times I was trying to work with closures?
Common Closures
Maybe put Async and Event Handling right in the section title?
What If I Can't See It?
Part of me thinks this section is a weird distraction, but a larger part of me thinks it's necessary, and may prove useful to people who can't figure out why their code isn't working the way they think it should.
Observable Definition
This is solid, and I think the bullet points make it much clearer.
The Closure Lifecycle
This material is great, but I'd call out the impact on garbage collection in the headline. This gets back to the strange memory leaks conversation I noted above. There's good news here, but not all good news!
Per Variable or Per Scope?
This is a great discussion of how various engines handle (or don't handle) closure. My only question is how/if it applies to more common situations like the async and event handling examples given earlier. Those are a lot more common.
An Alternate Perspective
I'd love to see "we simplify explanation of closure to a straightforward combination of references and in-place function instances." somewhere near the front of the chapter. You do a great job of building to that conclusion, but I worry that the readers who need it most may not stick that far on something labeled "alternate". The magic then works as the glorious conclusion of the build-up.
Why Closure?
First example: how did you steal my typical event-handling code? No need to answer - I know my mistakes are not unusual.
There's a hanging reference - "(related: currying)". I think experienced developers will know why you put it there, but I don't think you can safely count on that. I'd suggest making that "related to currying" without the parentheses, and then use a parenthetical sentence at the end of the paragraph to explain currying briefly, at least enough to hold them for now.
Closer to Closure
Consider stealing the "Let's consider what closure does for our programs" list from the section above and using it to open this closing section. The second-to-last paragraph echoes the bullets, but the bullets are easier. ("Closer" is a neat double-meaning in the headline, too.)