[_getify]

Just FTR: this is not accidental or lazy on my part. It's highly intentional. But I can certainly appreciate that it frustrates some learners.

There's a principle called "Cognitive Load Theory" [1] 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.

[1] https://en.wikipedia.org/wiki/Cognitive_load

[askRich]

First I'd like to thank you for your work. I've learned a lot from you and your teachings.

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

The concept of a "promise" made sense to me when you used buying a hamburger at a fast food store in your workshop on asynchronous javascript.

[dwltz]

I agree with this, foo/bar/baz stuff is abstract and means nothing. This means the learner need stop associate something they don't know with nothing which is really hard. An analogy of something the learner knows is way easier to grasp..

[abhisack]

Instead of getting lost in the jungle, 'foo', 'bar' style helps understand the concept. To the ones who say it's not an effective way; What if a learner is coming from non 'web-dev' background e.g. from a mathematical one who wishes to create complex alogorithms and geometries, interfaces etc. with JS, Won't he, on seeing 'login' code, wish that it were of his interest? After all JS is not only used to just create typical sites. What if learner was going to use JS on iot, robots etc.? So stereotyping the code with some particular 'web-dev' usecases is not useful (atleast not at the beginning). 'foo', 'bar' style helps focus on what it's really important to learn at first.

It's like -- 'a human without makeup is the most real'

[braythwayt]

TL;DR: When teaching nuclear physics, do not place a bike shed on the diagram.