
A book series on JavaScript - hitr
https://github.com/getify/You-Dont-Know-JS
======
ninkendo
Just reading through the first few chapters of the book on the `this` keyword
(which, as an aside, is shocking to see that the feature is so confusing that
it merits its own entire book), the code snippets could use some _serious_
attention.

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.

~~~
_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](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..

------
kabes
I can highly recommend these books. They're one of the only books that do a
real deep-dive into the language. I often have to interview people for
javascript jobs. It's astonishing how few of them actually get how the `this`
keyword, closures, prototypes etc work. So the title of the series may be
arrogant, but not wrong.

~~~
davnn
I fully agree, those books are awesome if you want to truly understand JS. I
would, however, not say that understanding JS will help you become a better
programmer and the time invested in fully understanding JS might be better
invested somewhere else.

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.

~~~
frik
That's why I would recommend to read also "JavaScript: The Good Parts" (book,
2008) by Douglas Crockford. It covers (what is nowadays known as Javascript
1.5) and highlights the good parts of the language.

~~~
lacker
I think "JavaScript: The Good Parts" is outdated now, in particular the way it
advocates handling object-oriented programming and inheritance with a "roll
your own" method. It was great for its time, but especially with the advent of
ES2015, modern JavaScript is going in a different direction.

~~~
frik
My point was, it's not outdated. Javascript 2016 just got new featured that
oviously aren't covered. The class syntax is just a syntactic sugar and it's
important to understand how it's working under the hood. JS has prototype
based inheritance, which is more powerful and flexible than class based
inheritance. JS is therefor different to grasp than Java and C#. There are
still many coding JS and don't get it.

~~~
cwarrior
I don't recommend using the class syntax and I would even advise to favour
composition over inheritance.

------
franciscop
I really don't get the arrogant "You don't know X". Maybe I know it, maybe I
don't know it. But if I know it already, then I am wasting my time since I
think I don't know it (not really). However if I don't know it, then the
condescending tone doesn't really motivate me to want to know (while I _love_
to learn about Javascript).

~~~
rankam
I always assumed it was a play on the game You Don't Know Jack, but I could be
wrong.

[https://en.wikipedia.org/wiki/You_Don%27t_Know_Jack_(video_g...](https://en.wikipedia.org/wiki/You_Don%27t_Know_Jack_\(video_game_series\))

~~~
ZeroGravitas
I had assumed it was a play on the slightly ruder version "You don't know
jack-shit" as JS works as an abbreviation for both.

------
petercooper
I wouldn't normally do this, but since his books have popped up on here at
this exact moment.. Kyle's teaching some short JS classes in London this
coming week if you wanna come: [https://ti.to/cooperpress/kyle-simpson-quick-
workshops/](https://ti.to/cooperpress/kyle-simpson-quick-workshops/)
(disclosure: I'm the organiser)

~~~
scoot
/disclaimer/disclosure/

(When you disclose something, it's a disclosure.)

~~~
petercooper
You're correct - thanks! I've fixed it, for anyone else wondering what this is
about.

~~~
scoot
NP, it's so common an occurrence on HN, I think it's self reinforcing. :)

(Using 'i.e.' when meaning 'e.g.' is similarly frequent.)

~~~
petercooper
Ah, I'm alright with those as I know the Latin! It's only everyday English
words I seem to have a problem with ;-)

~~~
gummiruessel
You and me should be friends, for I also don't have any problems knowing when
to use "i.e." and when to use "e.g." but if I were to post what you did, I too
would have incorrectly said "disclaimer".

------
dang
I've been writing JS a long long time and my strategy has been to never learn
the intricacies of 'this', or the other bad neighborhoods of that language
(but especially 'this'). I just avoid those neighborhoods. I write functions
at the top level, keep all the signatures explicit, and enjoy the things in
the language that are straightforward.

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.

~~~
Secretmapper
Funny. JS is my main language, and I personally also don't know most of the
intricacies of JS, and we seem to share the same mindset.

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.

~~~
trgn
I find JS works well as an OO-language, and falls short as a functional one.
Not only when writing it, but also when it's executing. Dumb-as-rocks object
oriented JS-code tends to have a smaller memory footprint, is less crufty, and
is easier to debug. Functional JS-code tends to spam the heap, difficult for
the JIT to optimize, and when writing it you have none of the compile-time
safety of a true functional language.

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.

~~~
spraak
This is surprising.. do you have any examples of memory footprint, crufty-
ness, and debug-ability for OO vs functional style JS?

------
131hn
An entire book is dedicated to "this", when it's only "the stuff on the left
side of the dot" (it changed my life when i understood that)

~~~
kabes
It's just one chapter and the rest of the book is about prototypes and
inheritance.

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.

~~~
Udik
I found it pedantic as well. 'This' really is just the object to the left of
the dot, unless 'new' is used to invoke the function with a brand new 'this'
object. Functions called without a 'left-of-the-dot' argument, not having a
'this' injected, just see that of the global scope (Window). Call and apply
allow to explicitly inject the 'this' object. That pretty much sums up at
least 80% of the chapter.

~~~
rashkov
As kabes pointed out above, there are more exceptions than the ones you
mention. Don't forget bind, call/apply, strict mode, and arrow functions.

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

------
bengale
Seriously good books. I recommend them to anyone working in JavaScript.

------
komali2
I've met with Kyle Simpson a couple of times. He develops a lot of our
coursework at Makersquare/Hack Reactor. Definitely a sharp guy and very down
to earth. His code can be above my head but he's really good at bringing it
back down to a level the students can understand, which as a former teacher I
think is even more difficult that getting to an expert level in the first
place.

------
parrish
If anyone is interested Kyle was interviewed on Software Engineering Daily[0].
It was an interesting conversation.

[0]
[http://softwareengineeringdaily.com/2016/06/12/2610/](http://softwareengineeringdaily.com/2016/06/12/2610/)

~~~
pipu
Thanks!

------
reality_czech
This sounds like JavaScipt: The Bad Parts.

------
fapjacks
If you search Amazon for these titles, you'll see the author reacting poorly
to bad reviews.

~~~
bshimmin
Someone commented on his free e-book by saying "meh", and he replied:

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

~~~
fapjacks
Yes, he does react poorly elsewhere to comments he should have ignored. For
example in response to reviews calling him pedantic, it's almost like someone
wrote him hate mail or called his child a name. I think it's in poor taste to
take to Amazon to fight bad reviews that are mostly just someone's opinion.

------
paradite
From what I read, the author uses double quotes for string literals, "some
string".

Most of the style guides and linters recommend using single quotes, any idea
on the advantage of each?

~~~
grncdr
There is no difference in JavaScript, they have the same semantics & meaning.

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

~~~
paulddraper
Also, double quotes are in HTML attributes, and JS can be embedded in HTML
attributes and vice versa (though it's less common nowadays)

~~~
TheAceOfHearts
HTML supports both single-quotes and double-quotes.

~~~
paulddraper
True, and XML as well. But double-quotes are by far the norm. (Why? I don't
know... :)

------
brianzelip
Glad this was posted and especially glad for the feedback in the comments.
Lately I've been learning by working through hands-on challenges with
FreeCodeCamp.com. I'm ready for a deeper look and these books seem to fit the
bill.

Off topic, the author implements more metadata in his html than I usually see.
Check the source of his site [http://getify.me/](http://getify.me/). Sort of a
linked data approach.

------
bgnm2000
I love these books, and I've also been in corporate JS trainings with the
author. I can't express how much more clear Kyle was able to make every aspect
of Javascript for me. Javascript has actually become my language of choice
thanks to these books (and in-person sessions).

------
GroSacASacs
It is good stuff but I think it would be even better if there was a precise
opinion on what parts to use, JavaScript the good parts + Jslint not only
teaches you Js, but also how to write good quality js (avoid the bad parts)
which is something that is more beginner friendly.

------
616c
This and your Windows debugging comments make me think you and your friends
must be one very geeky crew.

I am jealous of all the scenes you follow, maam/sir!

------
nbvehrfr
It's just a programming language :)

------
mlvljr
This fella has some nice vids on the more advanced JS (speaking of):
[https://www.youtube.com/watch?v=Konu9sHl-
nk](https://www.youtube.com/watch?v=Konu9sHl-nk)

~~~
0xmohit
Link to the entire playlist:
[https://www.youtube.com/playlist?list=PL37ZVnwpeshHVd9Zf92zW...](https://www.youtube.com/playlist?list=PL37ZVnwpeshHVd9Zf92zW4UJGWzPHU3o4)

------
mlvljr
Can the web use a language, simple enough to not need multiple books to allow
to understand its mechanics?

As this metaclass / function VS Function / whatever dispatch business is much
worse than recently discussed message-passing purism, in its worst forms.

~~~
IIJamesII
Yes. Kyle Simpson rocks. He is smart and he looks deeply into things. He is
opinionated and I like that too. I learn more when I see smart opinionated
people disagree with each other.

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

------
sklogic
You know the language is screwed beyond any hope when you need an entire book
on semantics of 'this'.

------
dildo_fingers
He has a couple of courses on Frontendmasters.com that are amazing.

------
distrill
come on

------
peterashford
Are the opening words, "The horror... the horror"?

