"Exploring Deeper" doesn't really capture this chapter. Where Chapter 2 was basic and mostly familiar structures, this one has most of the parts that confuse newcomers. It's the level where JavaScript sounds arcane to people who aren't familiar with the arcana. You describe it as "some of the lower-level characteristics of JS that underpin virtually every line of code", and that's true. There's also, though, a crossing of a cultural chasm.
Calling it "JavaScript Arcana" probably wouldn't work, since some readers would think you were using it in the "arcane is pointless" style rather than the "hallowed mysteries that allow amazing things to happen" style, (Or they'd think it was Dungeons & Dragons. Oops.) I'd take another look over the title and introduction. There's more welcoming to do for readers, more celebration to do of the upcoming parts.
Closure
Everything you say here feels right, but I still really want a diagram. Between the text and the code, there's a lot to assemble, and it's the kind of moment where I would take out a pencil and write in the book, bracketing which code does what. That usually means a diagram, or at least some extra formatting would help.
I would motivate this story a little more. Closure is a weird mix of powerful when understood and booby trap when not. A few of the weirdest problems I've heard about, where programmers wondered if there was a ghost in the browser, came from connections people hadn't realized still were 'live'. I was talking about arcana above, but "closure can actually observe (or make!) updates to these variables over time" really kind of is magical until you see what's underneath.
This
Again, wow. There's a lot happening in the interplay between the text and the code. This time I'm less eager for a diagram and more eager to convert some of the text into console interactions with the code. Add something simple but interactive here?
Prototypes
My favorite part of JavaScript! I like that you dive right into prototypes and don't spend the opening comparing prototypes to inheritance. (It's good that classes were in the previous chapter, and you get to them later in the section.)
Here, it's not so much that I want to write on the code, but I want images of the bigger concepts and linkages. What's connected to what, and why? Was it automatic? Did I explicitly specify them? How do changes in one part of the system affect other parts?
Object linkage
All good, except again, maybe a diagram.
Class linkage
For this quick guide, I think I'd leave out the prototypal class pattern. The history and detail are great, but feel like a side-trip in an already dense chapter. Absolutely cover it later, just not in this briefer intro.
this Revisited
The content all makes sense, but I was confused about the placement and "revisited" until I got to the end. Could you put a more explicit transition like "Now that you've seen how prototypes and class linkage work, you also know more about this."
Iteration
Could this section go earlier in the chapter? It feels like much easier and friendlier stuff, and I don't think it depends on the material that currently comes earlier.
Again, this section could benefit from some diagrams. Thankfully, I think they'll be much easier diagrams than the rest.
Also, iteration is a topic where I've noticed an age divide. People who learned to program with integer loops often have a hard time letting go. (I still mentally translate back to that.) People who learned to program once iterators were a normal thing, though, move from programming language to programming language knowing to seek out the iteration tools. I'm not sure if that affects the text here. For Erlang and Elixir, I just didn't mention the numeric model, but that was for a different programming culture.
The last question learners might have, and maybe it doesn't fit the level of depth here, is what happens if the items being processed change? The classic model is filtering a list, where some items get deleted. Again, probably not critical to have here.
Your coverage of Consuming Iterators and Iterables looks right on, though I continue to hunger for diagrams. They probably aren't necessary at that concrete syntax level, though.
Asking Why
I love this conclusion. It does a great job of shifting gears from the traditional "JavaScript is an accident and we work amidst the chaos" complaint of too many programmers from other languages to "there is great stuff here if you keep your eyes open and try it out."
Overall
This chapter manages to cover a lot of difficult material without feeling impossibly dense. There are some nice "and now you know" and "enjoy the exploration" moments in it.
getify
commented
4 years ago
Editorial review, not a searchable issue.
Edition: (1st or 2nd) 2nd
Book Title: Get Started
Chapter: 3
Title
"Exploring Deeper" doesn't really capture this chapter. Where Chapter 2 was basic and mostly familiar structures, this one has most of the parts that confuse newcomers. It's the level where JavaScript sounds arcane to people who aren't familiar with the arcana. You describe it as "some of the lower-level characteristics of JS that underpin virtually every line of code", and that's true. There's also, though, a crossing of a cultural chasm.
Calling it "JavaScript Arcana" probably wouldn't work, since some readers would think you were using it in the "arcane is pointless" style rather than the "hallowed mysteries that allow amazing things to happen" style, (Or they'd think it was Dungeons & Dragons. Oops.) I'd take another look over the title and introduction. There's more welcoming to do for readers, more celebration to do of the upcoming parts.
Closure
Everything you say here feels right, but I still really want a diagram. Between the text and the code, there's a lot to assemble, and it's the kind of moment where I would take out a pencil and write in the book, bracketing which code does what. That usually means a diagram, or at least some extra formatting would help.
I would motivate this story a little more. Closure is a weird mix of powerful when understood and booby trap when not. A few of the weirdest problems I've heard about, where programmers wondered if there was a ghost in the browser, came from connections people hadn't realized still were 'live'. I was talking about arcana above, but "closure can actually observe (or make!) updates to these variables over time" really kind of is magical until you see what's underneath.
This
Again, wow. There's a lot happening in the interplay between the text and the code. This time I'm less eager for a diagram and more eager to convert some of the text into console interactions with the code. Add something simple but interactive here?
Prototypes
My favorite part of JavaScript! I like that you dive right into prototypes and don't spend the opening comparing prototypes to inheritance. (It's good that classes were in the previous chapter, and you get to them later in the section.)
Here, it's not so much that I want to write on the code, but I want images of the bigger concepts and linkages. What's connected to what, and why? Was it automatic? Did I explicitly specify them? How do changes in one part of the system affect other parts?
Object linkage
All good, except again, maybe a diagram.
Class linkage
For this quick guide, I think I'd leave out the prototypal class pattern. The history and detail are great, but feel like a side-trip in an already dense chapter. Absolutely cover it later, just not in this briefer intro.
this Revisited
The content all makes sense, but I was confused about the placement and "revisited" until I got to the end. Could you put a more explicit transition like "Now that you've seen how prototypes and class linkage work, you also know more about this."
Iteration
Could this section go earlier in the chapter? It feels like much easier and friendlier stuff, and I don't think it depends on the material that currently comes earlier.
Again, this section could benefit from some diagrams. Thankfully, I think they'll be much easier diagrams than the rest.
Also, iteration is a topic where I've noticed an age divide. People who learned to program with integer loops often have a hard time letting go. (I still mentally translate back to that.) People who learned to program once iterators were a normal thing, though, move from programming language to programming language knowing to seek out the iteration tools. I'm not sure if that affects the text here. For Erlang and Elixir, I just didn't mention the numeric model, but that was for a different programming culture.
The last question learners might have, and maybe it doesn't fit the level of depth here, is what happens if the items being processed change? The classic model is filtering a list, where some items get deleted. Again, probably not critical to have here.
Your coverage of Consuming Iterators and Iterables looks right on, though I continue to hunger for diagrams. They probably aren't necessary at that concrete syntax level, though.
Asking Why
I love this conclusion. It does a great job of shifting gears from the traditional "JavaScript is an accident and we work amidst the chaos" complaint of too many programmers from other languages to "there is great stuff here if you keep your eyes open and try it out."
Overall
This chapter manages to cover a lot of difficult material without feeling impossibly dense. There are some nice "and now you know" and "enjoy the exploration" moments in it.