· Evaluating the key aspects of day-to-day coding: objects, functions, code, and data
· Comparing prototype-based and delegation-based object models
· Composability of functions and types
· Achieving clear separation of concerns through modularity and meta-programming
· Using promises and streams programming to create unidirectional data pipelines
· Introducing the sample blockchain application
· Stage 0 (Strawman): this stage is informal and the proposal can have any form; it allows anyone to contribute into the further development of the language. To add your input, you must be either a member of TC39 or registered with ECMA International. If you’re interested, feel free to register at https://tc39.github.io/agreements/contributor. Once registered you can propose your idea via the es-discuss mailing list. You can also follow the discussions at https://esdiscuss.org/.
· Stage 1 (Proposal): after a strawman has been made, a member of TC39 must champion your addition to advance it to the next stage. This means the TC39 member must explain why the addition is useful and describe how it will behave and look once implemented.
· Stage 2 (Draft): then the proposal gets fully spec’d out and is considered experimental. If it reaches this stage, it means the committee expects the feature to eventually make it into the language.
· Stage 3 (Candidate): at this stage, the solution is considered complete and is signed-off. Changes after this stage are rare, and are generally only for critical discoveries after implementation and significant usage. You can feel comfortable using features in this stage. After a suitable period of deployment, the addition is safely bumped to stage 4.
· Stage 4 (Finished): this is the final stage; if a proposal reaches this stage it is ready to be included in the formal ECMAScript standard specification.
For most of the remainder if this chapter, I’ll introduce you to the book’s four major themes, so you can have an understanding of the big picture, and how the themes build up relate to each other, starting with objects.
With this book, you will:
Learn new ES6 syntax that eases the pain points of common programming idioms
Organize code with iterators, generators, modules, and classes
Express async flow control with Promises combined with generators
Use collections to work more efficiently with data in structured ways
Leverage new API helpers, including Array, Object, Math, Number, and String
Extend your program’s capabilities through meta programming
With this book you will:
Understand how callbacks let third parties control your program’s execution
Use generators to express async flow in a sequential, synchronous-looking fashion
Tackle program-level performance with Web Workers, SIMD, and asm.js
Learn valuable resources and techniques for benchmarking and tuning your expressions and statements
With this book you will:
Learn how natives provide object wrappers around primitive values
Dive into the coercion controversy—and learn why this feature is useful in many cases
With this book you will:
Explore how the this binding points to objects based on how the function is called
Look into the nature of JS objects and why you’d need to point to them
Learn how developers use the mixin pattern to fake classes in JS
Examine how JS’s prototype mechanism forms links between objects
Learn how to move from class/inheritance design to behavior delegation
Understand how the OLOO (objects-linked-to-other-objects) coding style naturally implements behavior delegation
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
Chapter 5: The (Not So) Secret Lifecycle of Variables
When Can I Use a Variable?
Hoisting: Yet Another Metaphor
Uninitialized Variables (aka, TDZ)
Chapter 6: Limiting Scope Exposure
Hiding in Plain (Function) Scope
Scoping with Blocks
Function Declarations in Blocks (FiB)
Chapter 7: Using Closures
See the Closure
The Closure Lifecycle and Garbage Collection (GC)
An Alternative Perspective
Closer to Closure
Chapter 8: The Module Pattern
Encapsulation and Least Exposure (POLE)
What Is a Module?
Node CommonJS Modules
Modern ES Modules (ESM)
Appendix A: Exploring Further
Anonymous vs. Named Functions
Hoisting: Functions and Variables
The Case for var
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)
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.