Superficial explanation of Modules In Chapter 2 of Book 1 (2nd edition) about you-dont-know-js

[DhiaAgrebi]

Your tone is spot on, consider me Getified.
Thank you for addressing my concerns, and I apologize again for the frustration that seeped into my tone while writing the first comment of this "issue".

I am too much of a beginner to see closure as the underlying core of modules. I summarize your answer as:

• I wasn't very thorough in illustrating my point of view. Again, I apologize and I thank you for your thorough response.
• Surveying JS is a high level view to get the reader started.
• We'll come to the underlying mechanism of modules later in the book series and for that I am grateful.

I should have explicitly mentioned the words: CommonJS, UMD and AMD instead of the nonsensical expression "word dropping". And about that paragraph, I urge every newbie to soldier on through the book instead of googling these words since the results are a minefield disguised as a dumpster.

Again, thank you for your speedy and thorough response. I will keep on reading the books and I thank you for your efforts as well as your magnificent course on FrontendMasters.com (we want more!).

Peace be upon you.

[getify]

the section is too superficial to be of any help neither to the newbie... word dropping and superficial comparison... nor to the intermediate to advanced user

I find this comment confusing, and I was tempted initially to assume a lot in how I analyze your position. But I don't want to just dismiss your concerns as invalid and close the issue prematurely. I don't know you (yet) and I might very well be missing important context in my reading of your feedback.

I want to explore your feedback by juxtaposing it with my intent as the author. What follows is detailed thoughts on that. I hope you'll read this message in that constructive tone rather than in a manner that's negative.

---

First, you're referring to chapter 2 of an intro book. Did you expect this chapter to go into a lot of depth on any topic? Or the whole book, for that matter? Do you think the primary audience of an intro book is ready for that depth?

I did present 2 whole pages on the topic of modules, including both the pre-ES6 "classic module" pattern as well as the ES6 "modern module" system. TBH, my concern at this point in the book (for beginners!) is that, if anything, I've already gone too detailed in the weeds... not that I've left too much out.

You self-describe as a newbie. I'm curious how, from that reader perspective, you can even tell that the description provided is "superficial"? How do you even know what is and isn't being covered here? I wouldn't expect a newbie on a topic to be able to judge the depth of coverage on a topic very accurately when they're first presented with it.

And if, on this topic, you're not a newbie but rather experienced, I'd expect you to adequately understand that a complex topic is often explained in multiple layers, and to recognize what level is being presented (and what's being skipped!) here. Have you encountered such "topic layering" in any other educational content (books, courses, etc)?

So I guess I'm struggling to understand which audience level would genuinely feel the way you've painted it. Which makes me believe I don't understand you as a reader enough yet.

Moreover, the chapter is literally called "Surveying JS"... the word survey here is intended to set the expectation that each topic is summarized in an overview, so as to get a broad glimpse of the major landmarks of the language -- each of which indeed deserves (and will get!) a deeper exploration later in this book and the whole series.

Do you find "surveys" of complex topics helpful or frustrating, generally?

I would've loved a small: "We'll get more into modules in Book x chapter y"

Have you read the rest of this book yet? Or did you feel you already knew enough of what was coming that you'd stop after chapter 2 to provide this feedback?

I ask because I kind of hope readers give me the chance to present what I think is necessary, by reading the whole book first, before judging that I had left out things they wanted/expected.

In Chapter 3, I dig down a bit deeper from the broad "patterns" (like modules or classes) identified in Chapter 2, to the underlying language mechanics that make them work. For modules, that underlying mechanic is closure, so we dig into that topic. Again, not complete coverage of closure for sure, but a fair bit of detail that, if anything, I worry might be too much for begjnners, not too little.

Then, in Chapter 4, the goal is to provide a roadmap to the reader on where and how these major topics are organized in the rest of the book series.

We again come back to closure, and explain why it's so important that it's actually (according to me) one of the 3 core pillars of the language. And indeed that's why it deserves its own dedicated book (of nearly 200 pages, with exquisite detail on all aspects of modules).

I end that section with:

"To dig further into scope, closures, and how modules work, read Book 2, Scope & Closures."

So I guess my response to your feedback/ask here is... I did have exactly such a mention, it's just that I hadn't finished connecting the dots on the topic yet, since there was more than half the book still yet to read.

"Way back" in Chapter 2, I didn't think the reader was ready for divergent forward references ("see xyz book for more"). I wanted to bring them further on the journey (thru chapters 3 and 4) to motivate and set proper context for exploring the next whole book.

---

Again, I hope my tone here isn't too harsh or taken negatively.

Perhaps I've missed some important aspects/nuances of your reader perspective... and if so I hope you'll elaborate, and that my detailed response here gives you enough raw material to use in clarifying that perspective.

While I was confused by your feedback, I don't necessarily take a stance that either you're right or wrong, but just that I'm not sure why the above reasoning I used in writing the book hadn't been sufficient to satisfy you as the reader.

Perhaps I'll be able to improve through any further clarifications you provide?

[DhiaAgrebi]

Thank you for taking the time to read my feedback and being mindful about it.
The thing that made me jump is that, in the specific section, you're introducing modules as a counterpart to classes, yet in the wild we (i.e I) encounter either the ES modules or the Node's flavor of common JS as a full fledged standalone scripts.
It never crossed my mind that modules are in fact units encapsulating data and behavior, the very same reason classes were invented. I know, in hindsight, it's crazy and I should've made the connection.

In any case, thank you for taking the time to be so clear about what you expect, what you expected, what you felt and what you're feeling. You're a great communicator ( :

[getify]

I should have explicitly mentioned the words: CommonJS, UMD and AMD instead of the nonsensical expression "word dropping".

Thanks, that feedback helps. I included those terms because I was assuming that at least some readers may have run across those before reading the book, and probably didn't even understand where they fit in to the landscape. But I maybe should have added a note like "Don't worry if these terms are unfamiliar, you'll learn about them more later."

Thanks again for engaging in the feedback. I get a lot of feedback on these books, on the whole spectrum from positive to negative... and plenty of it is stuff I straight up disagree with. But even in the midst of such reaction, I try to be mindful that there are times when I can learn from the feedback, even tiny things. It's far too easy for me, this far along, to jump to assuming I know everything about what someone's saying, and I have to continually try to remind myself to pause and explore. Always something to learn.