About This Book:
The foundation of all programs is the organization of its variables and functions into different nested scopes. Yet, most developers haven’t deeply contemplated how and why these decisions are made and the impacts on code maintainability.
The worldwide best selling “You Don’t Know JS” book series is back for a 2nd edition: “You Don’t Know JS Yet”. All 6 books are brand new, rewritten to cover all sides of JS for 2020 and beyond.
“Scope & Closures” examines all aspects of lexical scope, then builds on these principles to leverage the power of closure, and finally digs into the module pattern for better program structure.
In Scope & Closures, you’ll dig into:
- Nesting lexical scopes with functions and blocks, to limit scope exposure of variables
- Functions remembering variables through closure
- Modules, one of the most important code organization patterns in programming
About the Author:
- ASIN: B08634PZ3N and B086GD45ZG
- ISBN: 978-1-64786-226-8
- Publisher: GetiPub & Leanpub; 2nd edition (March 17, 2020) – Published by GetiPub (http://getipub.com), a division of Getify Solutions, Inc., and produced by Leanpub (https://leanpub.com/p/getipub).
- Publication date: March 17, 2020
- Print length: 246 pages
Table of Contents:
- The Parts
- The Title?
- The Mission
- The Path
- Chapter 1: What’s the Scope?
- About This Book
- Compiled vs. Interpreted
- Compiling Code
- Compiler Speak
- Cheating: Runtime Scope Modifications
- Lexical Scope
- Chapter 2: Illustrating Lexical Scope
- Marbles, and Buckets, and Bubbles… Oh My!
- A Conversation Among Friends
- Nested Scope
- Continue the Conversation
- Chapter 3: The Scope Chain
- “Lookup” Is (Mostly) Conceptual
- Function Name Scope
- Arrow Functions
- Backing Out
- Chapter 4: Around the Global Scope
- Why Global Scope?
- Where Exactly is this Global Scope?
- Global This
- Globally Aware
- Chapter 5: The (Not So) Secret Lifecycle of Variables
- When Can I Use a Variable?
- Hoisting: Yet Another Metaphor
- Uninitialized Variables (aka, TDZ)
- Finally Initialized
- Chapter 6: Limiting Scope Exposure
- Least Exposure
- Hiding in Plain (Function) Scope
- Scoping with Blocks
- Function Declarations in Blocks (FiB)
- Blocked Over
- Chapter 7: Using Closures
- See the Closure
- The Closure Lifecycle and Garbage Collection (GC)
- An Alternative Perspective
- Why Closure?
- Closer to Closure
- Chapter 8: The Module Pattern
- Encapsulation and Least Exposure (POLE)
- What Is a Module?
- Node CommonJS Modules
- Modern ES Modules (ESM)
- Exit Scope
- Appendix A: Exploring Further
- Implied Scopes
- Anonymous vs. Named Functions
- Hoisting: Functions and Variables
- The Case for
- What’s the Deal with TDZ?
- Are Synchronous Callbacks Still Closures?
- Classic Module Variations
- Appendix B: Practice
- Buckets of Marbles
- Closure (PART 1)
- Closure (PART 2)
- Closure (PART 3)
- Suggested Solutions
I must first thank my wife and kids, whose constant support is what allows me to keep going. I also want to thank the 500 original backers of the Kickstarter for “You Don’t Know JS” (1st ed), as well as the hundreds of thousands of folks who bought and read those books since. Without your financial support, this second edition wouldn’t be happening. Thanks also to the interviewer at a certain avian social media company who said I didn’t “know enough about JS”… you helped me name the series.
Next, I owe much of my current career path to Marc Grabanski and Frontend Masters. Marc took a chance on me and gave me my first shot at teaching years ago, and I wouldn’t have then become a writer had it not been for that! Frontend Masters is the Premier Sponsor of YDKJSY 2nd Edition. Thank you, Frontend Masters (and Marc).
Lastly, my editor, Simon St.Laurent, who helped me conceive the original YDKJS and was my first book editor. Simon’s support and guidance have profoundly impacted me and been an integral part of shaping me into the writer I am today. From those drinks we enjoyed at the Driskill all those years back, where YDKJS was born, through today, thank you so much Simon for shepherding and improving these books!
If I look over the books on my bookshelf, I can clearly see which of these titles are well loved. Well loved in this sense meaning they are a little worn. Their binding is broken, their pages are tattered, there might even be a spilled drink smear or two. What’s ironic to me is that the most loved of my books often look the least cared for, though honestly the opposite is true.
Scope and Closures (1st ed.) is one of my most loved books. It’s small, but the binding is coming undone. The pages are worn and dog-eared. It’s a bit rumpled. It’s not a book I’ve read once. I’ve picked it up again and again in the many years since it was originally published.
Over the years, even though I wasn’t necessarily feeling my own improvement on a day-to-day basis, each one of the concepts became more approachable. I’d smile to myself, realizing how far I’d come with the help of these guides. It became apparent there was an inverse correlation between how well I treated the book and how much I loved it.
When Kyle asked me to write the Foreword for the 2nd edition, I was floored. It’s not often you’re asked to write about a book that’s been so formative for your own understanding and career, Scope and Closures in particular. I remember the day I first understood closures, the first time I used one well. The satisfaction was great, in part because the symmetry of the idea was compelling to me. Before I even picked this book up, I was already enamoured with closures. And yet, there’s a difference between being able to execute code successfully and fully explore the concepts with any depth. This book took my base understanding and drew it out, helped me master it.
This book is deceptively short. It’s helpful that it’s small because it’s dense with useful knowledge. Since it is compact, I’d suggest you give yourself time to absorb each page. Take your time with it. Treat the book with care, and by that I mean, wear it down.
Head of Developer Experience
Welcome to the 2nd edition of the widely acclaimed You Don’t Know JS (YDKJS) book series: You Don’t Know JS Yet (YDKJSY).
If you’ve read any of the 1st edition books, you can expect a refreshed approach in these new ones, with plenty of updated coverage of what’s changed in JS over the last five years. But what I hope and believe you’ll still get is the same commitment to respecting JS and digging into what really makes it tick.
You may have been told, or felt yourself, that JS is a deeply flawed language that was poorly designed and inconsistently implemented. Many have asserted that it’s the worst most popular language in the world; that nobody writes JS because they want to, only because they have to given its place at the center of the web. That’s a ridiculous, unhealthy, and wholly condescending claim.
Don’t buy the lie that you should only learn and use a small collection of good parts while avoiding all the bad stuff. Don’t buy the “X is the new Y” snake oil, that some new feature of the language instantly relegates all usage of a previous feature as obsolete and ignorant. Don’t listen when someone says your code isn’t “modern” because it isn’t yet using a stage-0 feature that was only proposed a few weeks ago!
Every part of JS is useful. Some parts are more useful than others. Some parts require you to be more careful and intentional.
So what’s the title of the series all about?
Seriously, all those were real reactions to the original series title before folks even read the books. And they’re baseless.
The primary point of the title “You Don’t Know JS Yet” is to point out that most JS developers don’t take the time to really understand how the code that they write works. They know that it works—that it produces a desired outcome. But they either don’t understand exactly how, or worse, they have an inaccurate mental model for the how that falters on closer scrutiny.
I’m presenting a gentle but earnest challenge to you the reader, to set aside the assumptions you have about JS, and approach it with fresh eyes and an invigorated curiosity that leads you to ask why for every line of code you write. Why does it do what it does? Why is one way better or more appropriate than the other half-dozen ways you could have accomplished it? Why do all the “popular kids” say to do X with your code, but it turns out that Y might be a better choice?
I added “Yet” to the title, not only because it’s the second edition, but because ultimately I want these books to challenge you in a hopeful rather than discouraging way.
But let me be clear: I don’t think it’s possible to ever fully know JS. That’s not an achievement to be obtained, but a goal to strive after. You don’t finish knowing everything about JS, you just keep learning more and more as you spend more time with the language. And the deeper you go, the more you revisit what you knew before, and you re-learn it from that more experienced perspective.
You can always know JS better than you currently do. That’s what I hope these YDKJSY books represent.
The case doesn’t really need to be made for why developers should take JS seriously—I think it’s already more than proven worthy of first-class status among the world’s programming languages.
But a different, more important case still needs to be made, and these books rise to that challenge.
I’ve taught more than 5,000 developers from teams and companies all over the world, in more than 25 countries on six continents. And what I’ve seen is that far too often, what counts is generally just the result of the program, not how the program is written or how/why it works.
My experience not only as a developer but in teaching many other developers tells me: you will always be more effective in your development work if you more completely understand how your code works than you are solely just getting it to produce a desired outcome.
In other words, good enough to work is not, and should not be, good enough.
All developers regularly struggle with some piece of code not working correctly, and they can’t figure out why. But far too often, JS developers will blame this on the language rather than admitting it’s their own understanding that is falling short. These books serve as both the question and answer: why did it do this, and here’s how to get it to do that instead.
My mission with YDKJSY is to empower every single JS developer to fully own the code they write, to understand it and to write with intention and clarity.
Some of you have started reading this book with the goal of completing all six books, back to back.
I would like to caution you to consider changing that plan.
My suggestion is you take your time going through YDKJSY. Take one chapter, read it completely through start to finish, and then go back and re-read it section by section. Stop in between each section, and practice the code or ideas from that section. For larger concepts, it probably is a good idea to expect to spend several days digesting, re-reading, practicing, then digesting some more.
You could spend a week or two on each chapter, and a month or two on each book, and a year or more on the whole series, and you would still not be squeezing every ounce of YDKJSY out.
Don’t binge these books; be patient and spread out your reading. Interleave reading with lots of practice on real code in your job or on projects you participate in. Wrestle with the opinions I’ve presented along the way, debate with others, and most of all, disagree with me! Run a study group or book club. Teach mini-workshops at your office. Write blog posts on what you’ve learned. Speak about these topics at local JS meetups.
It’s never my goal to convince you to agree with my opinion, but to encourage you to own and be able to defend your opinions. You can’t get there with an expedient read-through of these books. That’s something that takes a long while to emerge, little by little, as you study and ponder and re-visit.
I’m so glad you’re embarking on this journey, and I am so honored you would consider and consult these books along the way. It’s time to start getting to know JS.
License & Copyright:
© 2013-2019 Kyle Simpson. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 4.0 Unported License.