11 ms·

A book series on JavaScript

479 points by hitr 10y ago

616c 10y ago
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!
distrill 10y ago
come on
franciscop 10y ago
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 10y ago
  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_game_series) https://en.wikipedia.org/wiki/You_Don%27t_Know_Jack_(video_g...
  - ZeroGravitas 10y ago
    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 10y ago
  It's just a catchy, challenging title, a la "Learn X The Hard Way" or "X For Dummies".
- doomtop 10y ago
  I do think it is meant to be a catchy marketing play on "You Don't Know X" but the author also describes it as a reference to the fact that "knowing" JavaScript can only ever be temporal: No matter how much you feel you've mastered JavaScript to this point, the truth is that JavaScript is never going to stop evolving, and moreover, the rate of evolution is increasing rapidly. This fact is almost a metaphor for the spirit of this series, to embrace that we'll never fully know every part of JS, because as soon as you master it all, there's going to be new stuff coming down the line that you'll need to learn.[1] [1] From Ch. 3 "Into YDKJS" of the first book Up & Going: https://github.com/getify/You-Dont-Know-JS/blob/master/up%20&%20going/ch3.md#es6--beyond https://github.com/getify/You-Dont-Know-JS/blob/master/up%20...
kabes 10y ago
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.
- willempienaar 10y ago
  Agreed. 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.
- Secretmapper 10y ago
  This is too true. I've had a software engineer complain to me at how unfair his last interview was because they asked "esoteric javascript" questions in a front-end javascript development position. I asked him what questions he found tricky and a lot of them are really simple javascript 'things' (scopes, closure, iife, etc) that would come up sooner or later when you're working with the language
  - sethetter 10y ago
    I think there is still a lingering mentality that you don't have to be an expert with JS to do front end work, and that's just not the case anymore.
    - Klathmon 10y ago
      People treat js as a toy language then get upset when people use it to build actual applications.
    - at-fates-hands 10y ago
      This is such a true statement. 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.
131hn 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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.
- grwgreg 10y ago
  not if you invoke it like this (1,someobj.somefn)()
mlvljr 10y ago
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 10y ago
  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.)
mlvljr 10y ago
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
- nunyabuizness 10y ago
  Ya, he's one of the co-founders of Hack Reactor [1] and is a pretty brilliant lecturer. [1] http://www.hackreactor.com/ http://www.hackreactor.com/
- 0xmohit 10y ago
  Link to the entire playlist: https://www.youtube.com/playlist?list=PL37ZVnwpeshHVd9Zf92zW4UJGWzPHU3o4 https://www.youtube.com/playlist?list=PL37ZVnwpeshHVd9Zf92zW...
bengale 10y ago
Seriously good books. I recommend them to anyone working in JavaScript.
fapjacks 10y ago
If you search Amazon for these titles, you'll see the author reacting poorly to bad reviews.
- bshimmin 10y ago
  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.
  - galfarragem 10y ago
    Bad reviews are a contemporary version of book burning.
  - fapjacks 10y ago
    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.
- _getify 10y ago
  First, I think it's disingenuous for an author to revel only in the positive reviews and "just ignore" the negative. An author should take all feedback and do the best with it he/she can. I read all reviews, and try to find anything I can in there to get better. That's why I'm sending this reply. 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.
petercooper 10y ago
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 10y ago
  /disclaimer/disclosure/ (When you disclose something, it's a disclosure.)
  - petercooper 10y ago
    You're correct - thanks! I've fixed it, for anyone else wondering what this is about.
    - scoot 10y ago
      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 10y ago
        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 10y ago
        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".
- himlion 10y ago
  I was at one of his classes in the Netherlands this week. I would definitely recommend it.
paradite 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      HTML supports both single-quotes and double-quotes.
      - paulddraper 10y ago
        True, and XML as well. But double-quotes are by far the norm. (Why? I don't know... :)
- renke1 10y ago
  I do use double quotes in my JS projects, mostly out of habit though. 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.
dildo_fingers 10y ago
He has a couple of courses on Frontendmasters.com that are amazing.
peterashford 10y ago
Are the opening words, "The horror... the horror"?
komali2 10y ago
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.
nbvehrfr 10y ago
It's just a programming language :)
dang 10y ago
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 10y ago
  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.
  - dang 10y ago
    > 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.
  - trgn 10y ago
    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.
parrish 10y ago
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 10y ago
  Thanks!
reality_czech 10y ago
This sounds like JavaScipt: The Bad Parts.
bgnm2000 10y ago
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 10y ago
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.
brianzelip 10y ago
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.
sklogic 10y ago
You know the language is screwed beyond any hope when you need an entire book on semantics of 'this'.
ninkendo 10y ago
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 10y ago
  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

479 points by hitr 10y ago

616c 10y ago

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!

distrill 10y ago

come on

franciscop 10y ago

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 10y ago
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_game_series) https://en.wikipedia.org/wiki/You_Don%27t_Know_Jack_(video_g...
- ZeroGravitas 10y ago
  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 10y ago
It's just a catchy, challenging title, a la "Learn X The Hard Way" or "X For Dummies".
doomtop 10y ago
I do think it is meant to be a catchy marketing play on "You Don't Know X" but the author also describes it as a reference to the fact that "knowing" JavaScript can only ever be temporal: No matter how much you feel you've mastered JavaScript to this point, the truth is that JavaScript is never going to stop evolving, and moreover, the rate of evolution is increasing rapidly. This fact is almost a metaphor for the spirit of this series, to embrace that we'll never fully know every part of JS, because as soon as you master it all, there's going to be new stuff coming down the line that you'll need to learn.[1] [1] From Ch. 3 "Into YDKJS" of the first book Up & Going: https://github.com/getify/You-Dont-Know-JS/blob/master/up%20&%20going/ch3.md#es6--beyond https://github.com/getify/You-Dont-Know-JS/blob/master/up%20...

kabes 10y ago

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.

willempienaar 10y ago
Agreed. 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.
Secretmapper 10y ago
This is too true. I've had a software engineer complain to me at how unfair his last interview was because they asked "esoteric javascript" questions in a front-end javascript development position. I asked him what questions he found tricky and a lot of them are really simple javascript 'things' (scopes, closure, iife, etc) that would come up sooner or later when you're working with the language
- sethetter 10y ago
  I think there is still a lingering mentality that you don't have to be an expert with JS to do front end work, and that's just not the case anymore.
  - Klathmon 10y ago
    People treat js as a toy language then get upset when people use it to build actual applications.
  - at-fates-hands 10y ago
    This is such a true statement. 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.

131hn 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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.
grwgreg 10y ago
not if you invoke it like this (1,someobj.somefn)()

mlvljr 10y ago

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 10y ago
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.)

mlvljr 10y ago

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

nunyabuizness 10y ago
Ya, he's one of the co-founders of Hack Reactor [1] and is a pretty brilliant lecturer. [1] http://www.hackreactor.com/ http://www.hackreactor.com/
0xmohit 10y ago
Link to the entire playlist: https://www.youtube.com/playlist?list=PL37ZVnwpeshHVd9Zf92zW4UJGWzPHU3o4 https://www.youtube.com/playlist?list=PL37ZVnwpeshHVd9Zf92zW...

bengale 10y ago

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

fapjacks 10y ago

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

bshimmin 10y ago
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.
- galfarragem 10y ago
  Bad reviews are a contemporary version of book burning.
- fapjacks 10y ago
  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.
_getify 10y ago
First, I think it's disingenuous for an author to revel only in the positive reviews and "just ignore" the negative. An author should take all feedback and do the best with it he/she can. I read all reviews, and try to find anything I can in there to get better. That's why I'm sending this reply. 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.

petercooper 10y ago

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 10y ago
/disclaimer/disclosure/ (When you disclose something, it's a disclosure.)
- petercooper 10y ago
  You're correct - thanks! I've fixed it, for anyone else wondering what this is about.
  - scoot 10y ago
    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 10y ago
      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 10y ago
        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".
himlion 10y ago
I was at one of his classes in the Netherlands this week. I would definitely recommend it.

paradite 10y ago

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 10y ago
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 10y ago
  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 10y ago
    HTML supports both single-quotes and double-quotes.
    - paulddraper 10y ago
      True, and XML as well. But double-quotes are by far the norm. (Why? I don't know... :)
renke1 10y ago
I do use double quotes in my JS projects, mostly out of habit though. 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.

dildo_fingers 10y ago

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

peterashford 10y ago

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

komali2 10y ago

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.

nbvehrfr 10y ago

It's just a programming language :)

dang 10y ago

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 10y ago
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.
- dang 10y ago
  > 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.
- trgn 10y ago
  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.

parrish 10y ago

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 10y ago
Thanks!

reality_czech 10y ago

This sounds like JavaScipt: The Bad Parts.

bgnm2000 10y ago

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 10y ago

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.

brianzelip 10y ago

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.

sklogic 10y ago

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

ninkendo 10y ago

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 10y ago
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