-
Notifications
You must be signed in to change notification settings - Fork 33.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Superficial explanation of Modules In Chapter 2 of Book 1 (2nd edition) #1854
Comments
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?
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? |
Your tone is spot on, consider me Getified. I am too much of a beginner to see closure as the underlying core of modules. I summarize your answer as:
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. |
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. |
Thank you for taking the time to read my feedback and being mindful about it. 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 ( : |
Please type "I already searched for this issue":
I already searched for this issue
Edition: (1st or 2nd)
2nd
Book Title:
You don't know JS Yet - Getting Started
Chapter:
2
Section Title:
How we organize in JS
Question:
When it comes to module, the section is too superficial to be of any help neither to the newbie (such as myself): word dropping and superficial comparison to classes in passing, nor to the intermediate to advanced user: they pretty much already know what's being taught.
I would've loved a small: "We'll get more into modules in Book x chapter y", or check these links to learn more about modules.
Thank you for all your work and for replying to this issue.
The text was updated successfully, but these errors were encountered: