The variables are all `foo`, `bar`, `baz`, `a`, `obj`, etc. And the values are all just numbers. Sometimes they have a function that takes a value `a`, and they just do `this.a = a`. It requires a ton of cognitive strain to glean out what they're trying to show you in the examples because of this.
IMO the best books are those where they use silly (possibly contrived) "sample program" that the examples all build on. I mean, you could make your classes Cows and Animals, your functions moo's, your properties things like name and favoriteColor, and things can suddenly be a lot more readable when you want to do something like show lexical scoping rules. ("Oh no, that cow's name is steve, when you may have expected it to be bob because of the difference in what `this` refers to" is a lot easier in my mind than a big see of `foo`'s and `bar`'s.) Or maybe an example involving a bank and deposits and withdrawals.
It seems like a minor nitpick but it's things like these that I really use to judge whether a book is actually of good quality. I mean sure, any half-decent programming book exposes you the concepts that make you a better developer, but the good ones do so in a manner that makes it easy to understand.
There's a principle called "Cognitive Load Theory"  which I believe all teachers have to take seriously. Specifically, the "extraneous cognitive load". It's why I choose to introduce concepts with foo/bar style first.
I am concerned by the observations I've made over many years of teaching (JS) that many people tend to get distracted by problem domains and miss out on the underlying concepts. For example, if I am teaching about `this` but I use an example like a login system, it's far too easy for someone to get distracted by what they know -- or worse, what they don't know -- about how login systems work.
It's an overload on the cognitive side because the learner (reader) is having to juggle not only the new concepts but also their knowledge/opinions/baggage about the problem domain.
Cognitive overload is so "dangerous" not just because you might overflow someone's capacity and they stop getting anything out of the teaching, but because it has the tendency to become subtractive and actually cause them to lose what they already knew or had learned about the concept.
So... my approach in teaching, which is also reflected in the books, is to default to teaching a concept first without a problem domain, using generics like foo/bar, and THEN once I feel someone has the concepts, later, you can reinforce those with practical applications in problem domains.
IOW, I'd teach the abstract principles of `this` first, then the abstract principles of the Prototype system, then I'd start to show some examples like a login system that show how you can put those abstract concepts together into a real thing.
Anyway, I understand it doesn't meet your preference, but I just wanted to explain the reasoning behind it from my side.
When it comes to "foo bar" examples, as a learner, I think it causes MORE cognitive load not less.
I think this is because, it's hard to make connections between meaningless words like foo, bar and baz
Conversely, most of the "aha" moments come from your ELI5-like explanations of concepts
It's like -- 'a human without makeup is the most real'
Some parts of "understanding JS" is just understanding a (insert your swearword) designed language, unfortunately. You might just not fully understand those parts and call them the bad parts. I can't stand not understanding, though.
Now with ES6 and Babel Translator everybody can write ES6 code ( with out OLD JS BAD parts ) and enjoy JS as a true high level language like Ruby/Python .
And unfortunately, I think that because that complexity is there, programmers may feel they have to understand and use that complexity. Instead they should be actively preventing it from entering their brains and their codebase.
You have to get your mind oriented to concepts like closures and prototypes - there's a natural barrier there between the js dev and the real expert. People can get jobs without making the leap. I would think they can keep their job. But at some point having only the superficial understanding will have to be compensated for, maybe in technical debt.
Kyle's efforts to educate people are priceless and he's doing great job. I have watched two of his courses on Frontend Masters, I don't agree with everything he says, but I have great respect for the guy and for his work.
I still remember being at a conference about 6 years ago. We were on lunch and talking shop with several other front-end developers. Of course jQuery comes up and people start asking if they should learn "vanilla" JS first before using jQuery.
Still remember one developer blurting out, "Yeah, jQuery is so easy to use, you just cop/paste the code, you don't even really have to know JS. I don't see any reason to learn the basics of JS." The crazy thing is there were a lot of heads nodding in agreement at the table. That's how it used to be, if a developer needed to do something with jQuery, they'd just look for a plugin and use that.
Today? No way can get away without knowing the language. Too many frameworks, too many options to mix/match languages to get a really good workflow process. You can't just jump in and not know how Angular directives work or Backbone collections work without knowing exactly how these things work.
IT's a different world out there nowadays.
Maybe not in the word of startups and Silicon Valley, but there are tons of jobs for web developers across the world where simple jQuery knowledge will make you the best front end developer at your company.
That's not to say it's a good things. It's just a fact of life for many companies. Anyone better than that will leave before long for the greener pastures that you're referring to.
After reading these books I was kicking myself for not doing it sooner. All the JS mysteries just fade away as you go through it.
 From Ch. 3 "Into YDKJS" of the first book Up & Going: https://github.com/getify/You-Dont-Know-JS/blob/master/up%20...
(When you disclose something, it's a disclosure.)
(Using 'i.e.' when meaning 'e.g.' is similarly frequent.)
Once every couple years or so something comes up that forces me to dip a toe back into 'this'. If Plan A (find a way to avoid it) fails, I go to Plan B: relearn the minimum necessary and forget it as quickly as I can. I'll never pass a JS job interview, but since another life goal is to never endure another job interview, that part's ok too.
Now for tooling, infrastructure, and PL-focused engineers I think caring about the intricacies is important. First, because they'll be doing a lot of meta-programming to build frameworks and libraries. Second, is because to design good languages and frameworks you need to understand the ergonomics of the language and to pick the most intuitive and easy to use features.
Finally -- and this may sound like a contradiction to everything I said before -- I think that the best engineers are people who are able to jump between these two mindsets. Be able to bikeshed on the intricacies of frameworks one day and the next day -- when working on product -- to be focused on shipping while ignoring details that they have strong opinions on. A big part of this is dealing with cognitive dissonance. I can have a strong opinion on semicolons in JS but I can jump into a codebase without them and start cranking.
I felt that way when I was younger but eventually lost my taste for poring over masses of "just-because" detail, and became more sensitive to the cognitive cost of doing so. It isn't merely that the time and energy could be spent on other things, but that the brain responds to learning by patterning on it. If I spend energy on that, my work gets more like that and my brain thinks more like that, and I don't want them to.
(By the way, I'm not criticizing those books at all. I don't know them, but if they're as good as you say I think that's great.)
I mean, I do know common pitfalls and I can use `this`, etc., it's just that I find it's easier to avoid them entirely and leads to more readable code IMHO. In a way my JS tends to just be very scheme-like.
Mine too! I've felt for many years that we were lucky that Eich happened to have read SICP not long before those fateful two weeks in 1995. For all that we all love to hate JS, the language of the web could have—and to judge by all historical precedents, should have—been much worse.
Crockford succeeded in popularizing JS, partly by stressing the Scheme-like features of the language, but I'm not convinced that's where the strengths of the language lay.
There ARE times where I had to optimize though (HTML5 game developer, and we target mobile so this is expected) but for the most part 'premature optimization is the root evil'.
> A language that doesn’t affect the way you think about programming is not worth knowing.
There are many different motivations behind studying a language. You can study it for a job interview, for a job requirement, or for personal enlightment.
That is the context of "the way of thinking" I am looking at.
It's also not just 'the stuff on the left side of the dot'.
using strict mode, call/apply, the new keyword and arrow functions have influence on what `this` is. And they are applied in a certain order of precedence you need to know.
"this" is just a reference to the function context. Function context has a strong definition in programming languages. Saying that it's the stuff to the "left-of-dot" modulo a bunch of exceptions is sort of missing the forest for the trees, in my opinion.
Left-of-dot is a great way to introduce the concept but function context is so much more than just that.
Note that this review not only is completely unhelpful with just the single word "meh", leaving me nothing as an author to do to improve... but also that this review was from the kindle edition, which is FREE. ChrisP got a free copy of my book -- intentionally offered that way at a loss of income to both me and my publisher -- and took the time to come here and give a one-word, one-star review.
Seems quite reasonable to me really (though perhaps he'd be better off just ignoring that sort of feedback). I didn't spend long searching this so perhaps he's reacted worse elsewhere.
You probably think I should just "ignore the trolls" and you probably also think that anyone's negative expression is "freedom of speech" and that it shouldn't be countered.
I don't see it that way. The public ratings on my books are how a lot of people figure out if the books are worth looking at. No matter how legitimate or crazy a negative review may be, the one star hurts my overall rating exactly the same.
Furthermore, if I let a negative review go unanswered, I've lost an opportunity to show other readers a different perspective, and I've also lost the opportunity to (perhaps) engage in productive discussion that helps either that reviewer, or myself, or both, get better. Yes, this has actually happened before on a couple of occasions.
I don't think I'm reacting poorly by trying to find useful stuff even in the negative reviews. And I also don't think it's wrong to point out that unhelpful reviews are unhelpful.
I'm sorry this comes across as off-putting. But it's because I care so deeply about improving JS education through these books.
Most of the style guides and linters recommend using single quotes, any idea on the advantage of each?
However, single quotes have two advantages (IMO, since this is obviously subjective):
1. can be typed without shift on US keyboard layout
2. I use double quotes inside string literals (e.g. for quoting bad input in error messages) more often than single quotes (mostly used for contractions) so not having to escape double quotes by default is convenient.
Standard (and I guess eslint?) support "single quotes unless a single quote appears in the string", which is ideal (for me).
One reason I can think of why people use double quotes is because JSON only supports double quotes and it's not uncommon to deal with JSON when you program in JS.
Off topic, the author implements more metadata in his html than I usually see. Check the source of his site http://getify.me/. Sort of a linked data approach.
I am jealous of all the scenes you follow, maam/sir!
As this metaclass / function VS Function / whatever dispatch business is much worse than recently discussed message-passing purism, in its worst forms.
The fact that these books need to be written to de-mystify JS is evidence that JS sucks. We should not need to know esoteric crap - NOR SHOULD WE BE SATISFIED with programming by rote as many above seem to be advocating. (!?)
Having said that, JS is improving and the future looks bright.
(Disclaimer: this coming from someone self-employed who has never worked on a team.)