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