​

Chapter 4: The Bigger Picture

This book surveys what you need to be aware of as you get started with JS. The goal is to fill in gaps that readers newer to JS might have tripped over in their early encounters with the language. I also hope that we’ve hinted at enough deeper detail throughout to pique your curiosity to want to dig more into the language. The rest of the books in this series are where we will unpack all of the rest of the language, in far greater detail than we could have done in a few brief chapters here. When you’re ready, this final chapter divides the organization of the JS language into three main pillars, then offers a brief roadmap of what to expect from the rest of the book series, and how I suggest you proceed. Also, don’t skip the appendices, especially Appendix B, “Practice, Practice, Practice!”.

​

Pillar 1: Scope and Closure

The organization of variables into units of scope (functions, blocks) is one of the most foundational characteristics of any language; perhaps no other characteristic has a greater impact on how programs behave. Scopes nest inside each other, and for any given expression or statement, only variables at that level of scope nesting, or in higher/outer scopes, are accessible; variables from lower/inner scopes are hidden and inaccessible. This is how scopes behave in most languages, which is called lexical scope. The scope unit boundaries, and how variables are organized in them, is determined at the time the program is parsed (compiled). In other words, it’s an author-time decision: where you locate a function/scope in the program determines what the scope structure of that part of the program will be.

​

Lexical Scope

JS is lexically scoped, though many claim it isn’t, because of two particular characteristics of its model that are not present in other lexically scoped languages. The first is commonly called hoisting: when all variables declared anywhere in a scope are treated as if they’re declared at the beginning of the scope. The other is that var-declared variables are function scoped, even if they appear inside a block.

​

Closure

Closure is a natural result of lexical scope when the language has functions as first-class values, as JS does. When a function makes reference to variables from an outer scope, and that function is passed around as a value and executed in other scopes, it maintains access to its original scope variables; this is closure. To dig further into scope, closures, and how modules work, read Book 2, Scope & Closures.

​

Pillar 2: Prototypes

The second pillar of the language is the prototypes system. We covered this topic in-depth in Chapter 3 (“Prototypes”), but I just want to make a few more comments about its importance. JS is one of very few languages where you have the option to create objects directly and explicitly, without first defining their structure in a class. For many years, people implemented the class design pattern on top of prototypes—so-called “prototypal inheritance” (see Appendix A, “Prototypal ‘Classes’”)—and then with the advent of ES6’s class keyword, the language doubled-down on its inclination toward OO/class-style programming. Classes are just one pattern you can build on top of such power. But another approach, in a very different direction, is to simply embrace objects as objects, forget classes altogether, and let objects cooperate through the prototype chain. This is called behavior delegation. I think delegation is more powerful than class inheritance, as a means for organizing behavior and data in our programs. But class inheritance gets almost all the attention. And the rest goes to functional programming (FP), as the sort of “anti-class” way of designing programs. This saddens me, because it snuffs out any chance for exploration of delegation as a viable alternative. Object delegation is, I would argue, far more with the grain of JS, than classes (more on grains in a bit).

​

Pillar 3: Types and Coercion

The third pillar of JS is by far the most overlooked part of JS’s nature. The vast majority of developers have strong misconceptions about how types work in programming languages, and especially how they work in JS. A tidal wave of interest in the broader JS community has begun to shift to “static typing” approaches, using type-aware tooling like TypeScript or Flow. But I don’t agree at all that the inevitable conclusion of this is to decide JS’s type mechanism is bad and that we need to cover up JS’s types with solutions outside the language. We don’t have to follow the “static typing” way to be smart and solid with types in our programs. There are other options, if you’re just willing to go against the grain of the crowd, and with the grain of JS (again, more on that to come). Even if you love TypeScript/Flow, you are not going to get the most out of those tools or coding approaches if you aren’t deeply familiar with how the language itself manages value types. Without learning this pillar, your foundation in JS is shaky and incomplete at best.

​

With the Grain

I have some advice to share on continuing your learning journey with JS, and your path through the rest of this book series: be aware of the grain (recall various references to grain earlier in this chapter).

​

Against the Crowd’s Grain

First, consider the grain (as in, wood) of how most people approach and use JS. You’ve probably already noticed that these books cut against that grain in many respects. In YDKJSY, I respect you the reader enough to explain all the parts of JS, not only some select popular parts. I believe you’re both capable and deserving of that knowledge. But that is not what you’ll find from a lot of other material out there. It also means that the more you follow and adhere to the guidance from these books—that you think carefully and analyze for yourself what’s best in your code—the more you will stand out. That can be a good and bad thing. If you ever want to break out from the crowd, you’re going to have to break from how the crowd does it! As much as possible, I endeavor in these books to provide completely accurate information about JS, informed generally from the specification itself. But I also dose out quite a bit of my opinions on how you can interpret and use JS to the best benefit in your programs. I don’t present opinion as fact, or vice versa. You’ll always know which is which in these books. But if you choose to align with my opinions, you have to be prepared to back up those choices with why you feel that way. Don’t just parrot what I say. Own your opinions. Defend them. And if someone you were hoping to work with disagrees, walk away with your head still held high. It’s a big JS, and there’s plenty of room for lots of different ways. In other words, don’t be afraid to go against the grain, as I have done with these books and all my teachings. Nobody can tell you how you will best make use of JS; that’s for you to decide. I’m merely trying to empower you in coming to your own conclusions, no matter what they are.

​

With JavaScript’s Grain

On the other hand, there’s a grain you really should pay attention to and follow: the grain of how JS works, at the language level. There are things that work well and naturally in JS, given the right practice and approach, and there are things you really shouldn’t try to do in the language. Can you make your JS program look like a Java, C#, or Perl program? What about Python or Ruby, or even PHP? To varying degrees, sure you can. But should you?

​

With Your Team’s Grain

Finally, maybe the most important grain to recognize is how the existing program(s) you’re working on, and developers you’re working with, do stuff. Don’t read these books and then try to change all that grain in your existing projects over night. That approach will always fail. You’ll have to shift these things little by little, over time. Work on building consensus with your fellow developers on why it’s important to re-visit and re-consider an approach. But do so with just one small topic at a time, and let before-and-after code comparisons do most of the talking. Bring everyone on the team together to discuss, and push for decisions that are based on analysis and evidence from the code rather than the inertia of “our senior devs have always done it this way.”

​

In Order

So now you’ve got a broader perspective on what’s left to explore in JS, and the right attitude to approach the rest of your journey. But one of the most common practical questions I get at this point is, “What order should I read the books?” There is a straightforward answer… but it also depends. My suggestion for most readers is to proceed through this series in this order: That’s the intended order to read this book series.

​

Alternative Reading Orders

However, Books 2, 3, and 4 can generally be read in any order, depending on which topic you feel most curious about and comfortable exploring first. But I don’t recommend you skip any of these three books—not even Types & Grammar, as some of you will be tempted to do!—even if you think you already have that topic down. Book 5 (Sync & Async) is crucial for deeply understanding JS, but if you start digging in and find it’s too intimidating, this book can be deferred until you’re more experienced with the language. The more JS you’ve written (and struggled with!), the more you’ll come to appreciate this book. So don’t be afraid to come back to it at a later time. The final book in the series, ES.Next & Beyond, in some respects stands alone. It can be read at the end, as I suggest, or right after Getting Started if you’re looking for a shortcut to broaden your radar of what JS is all about. This book will also be more likely to receive updates in the future, so you’ll probably want to re-visit it occasionally.