Chapter 1
General:
This chapter needs a hook, something for the reader to DO. It could be as basic as a Hello World, but the reader should see some code in this chapter. If the point is that functional code is more readable, show me a comparison of something I'd do day-to-day in JS, followed by how it should be done in FP. A simple example, if possible, so that I can understand why the FP version is more readable. And be prepared to argue for why the functional version is more readable, because it's going to look strange (and scary, and not-worth-it) to FP newbies.
You seem to be apologizing a lot in this chapter. That undermines your authority as the author, and makes the reader doubt whether this book is what they need. I'd suggest setting aside your own personal struggles with this content, at least for the time being.
The intro paragraph could push harder on the "what's in it for me?" of functional. Specifically, what's the benefit to a JS developer? Your audience is probably people who've been working in JS for a while, and will need to see a reason to change. What's the main benefit? You say later that it's "readability, therefore trustability, which leads to reduced maintenance time." If that's the primary benefit, say it up here. You can make the argument more thoroughly later, but introduce it here.
"Confidence" section:
"code that you cannot trust is code that you do not understand."
Maybe reverse that? "code that you do not understand is code you can't trust" follows a cause-to-effect pattern more clearly.
"Communication" section:
"researchers who've studied this topic" Do you have a citation for that assertion?
Lots of short paragraphs in this chapter. That's effective in a blog post, but at book length, a staccato style tends to be off-putting. Whether you change that depends on what you think the reading pattern for this audience will be.
"I think we should focus a lot -- a LOT! -- more on the readability of our code. Like, a lot more."
I suggest dropping one of the "a lot" instances. One is fine; two is overkill.
This paragraph is problematic:
"So, if we are going to spend more time concerned with making code that will be more readable and understandable, FP turns out to be a really handy pattern in that effort. The principles of FP are well established, deeply studied and vetted, and provably verifiable."
The problem is that you don't really say why FP is more readable. That's why I think an example would help. Failing that, citing a source for "deeply studied and vetted" would be helpful.
"If we use FP principles, I believe we will create code that is easier to reason about."
- I suggest turning around "we" to "you." If you say "we," the reader may think it's helpful for you, but not for them. Change it to "you," and your focus is helping the reader.
- Drop "I believe." That again ties the benefit to your experience, which may not be the reader's.
- What are the "principles" you're referring to? You've talked about functional as a single entity up until now; why switch to principles now?
"Readability Curve" section:
I suggest bumping this to a level-1 head. It's related to "Communication," sure, but you're also talking a lot about the learning curve here, which is about the process, where communication is the goal.
"It's really important I take a moment to call out a phenomena that has derailed and frustrated me many times over the years, and was especially acute while writing this book."
You're talking about the readability curve for two paragraphs, and a figure, without saying exactly what it is, or giving it a name. The beginning of the above sentence wastes a lot of words: "It's really important that I take a moment..." You can skip all that and get to the point. Problem is, the point isn't immediately clear. I think it's something along these lines: "When you start to transition to functional programming, you'll probably find that the readability of your code decreases at first. That's frustrating, seems counterproductive, and causes many people to give up on FP. But if you stick with it, you'll find that the readability not only comes back as you gain experience, but increases dramatically."
(Also, "phenomena" is plural; the singular is "phenomenon.")
"minimize or eliminate most of the places where you might write bugs." -- I think there's an important point here, one that you're burying. If I understand this correctly, if you're writing good functional code, you eliminate a lot of bugs not because FP is magically better, but because you're taking out the places where bugs could occur in the first place. The overall number of bugs decreases because they literally can't happen. That's a big selling point, and it's not emphasized. (Again, a side-by-side code comparison would really illustrate the point well.)
I think this section goes on a bit too long with your personal struggle. I don't deny its validity, and I think anybody who's made the transition will recognize it, but it's kind of discouraging for a new reader. Instead of telling them how big the hill is, and how it's worth it from the top, how about helping them to take the first few steps?
"Take" section
I'm not sure what this section title means. (Is that just me being old?)
I'd change the "we" language to "I" in the first paragraph. It's not what "the author and the reader" will be doing, because the reader has no say in the matter. You're outlining your approach, so say "I."
"I hope this book can..." Don't suggest what the book may do, say what it will do.
When you're talking about formalism in this section, can you break it down? Take one of those formal terms and translate it into a simple English phrase a JS user would understand. Maybe it's not possible, but talking about "formalism" in the abstract just gives readers the impression that there's something vague and scary down the road that they'd like to avoid.
"YAGNI" section
After giving this some thought, I recommend pulling this entire section, or at least postponing it until later. The section title is misleading -- readers could easily get the impression that all of FP is something they don't really need, or will trip them up later. You're telling them "don't FP unless you need to FP." Problem is, for readers in Chapter 1, FP is unknown as of yet, so how will they tell the difference between "this is hard, but will be useful later" and "I won't need this later"? This section is basically giving them another excuse to back out of the book. It's good advice, but won't make sense until they've gotten their feet under them.
Summary section
- I suggest putting the summary before the resources, if you want people to read it.
- I suggest "conclusion" or "wrapping up" rather than "summary," because it should do more than summarize.
- My standard advice for conclusions:
a) An indication that the promise of the introduction was kept
b) Hints for further exploration
c) An organic connection to the following chapter
The conclusion in this chapter isn't working because there wasn't a promise to this chapter -- the reader didn't DO anything.