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).

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!

But I’ve also had many people tell me that they quoted some topic/explanation from these books during a job interview, and the interviewer told the candidate they were wrong; indeed, people have reportedly lost out on job offers as a result.

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.

Facts about JS are not really up for debate. Either the specification says something, or it doesn’t. If you don’t like what the specification says, or my relaying of it, take that up with TC39! If you’re in an interview and they claim you’re wrong on the facts, ask them right then and there if you can look it up in the specification. If the interviewer won’t re-consider, then you shouldn’t want to work there anyway.

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.

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?

No, I don’t think you should. I think you should learn and embrace the JS way, and make your JS programs as JS’y as is practical. Some will think that means sloppy and informal programming, but I don’t mean that at all. I just mean that JS has a lot of patterns and idioms that are recognizably “JS,” and going with that grain is the general path to best success.

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.”

That’s the most important advice I can impart to help you learn JS. Always keep looking for better ways to use what JS gives us to author more readable code. Everyone who works on your code, including your future self, will thank you!