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.
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.
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..
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'
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.
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.
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.
Actually, Simpson in his "you don't know JS" series of books makes a statement against "Javascript: the good parts". The main argument is that it's actually "Javascript: the easy parts". So crockford basically says "Just don't use the things most people find confusing when starting with JS". Instead, Simpson argues it's better to understand the language thoroughly so you can use all of its features to your advantage.
I believe the truth lies somewhere in between. You will have a really rough time programming JS with the good parts only, but you will also have a rough time annoying your colleagues when you are the only one using "this" in a place where it's considered a bug by most people.
@davnn you said it well. Most of the Javascript "Bad Reputation all these years" comes from the Language designed 20 years ago and did not change much mainly due to the fact that it is linked to ALL Browser vendor support at the SAME TIME ( to make any webpage JS to work).
Assume a senario like where Ruby/Python could not change for last 20 years from their version 0.5
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 .
http://es6-features.org/#ClassInheritance
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.
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.
Sadly, I think JS is at its best with most of ES3, a little of ES5, and drop of ES6. There's still a tiny, good (Ok... adequate) language underneath all the cruft. But unfortunately there's a lot of extra unnecessary complexity in JS that makes it easy for us to write unneccesarily complex and unreliable code.
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.
Even if you do understand how things like prototypes work, you will also need to understand how efficiently a compiler can implement changes to them. And how consistent/predictable the resulting code will be in terms of speed.
It's understandable since it was designed to be a scripting language, easy to pick up and be productive with only a superficial understanding.
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.
I agree. Having interviewed many people for JS jobs I have realised they actually don't know the language. The pressure these days is on frameworks. Do you know React? Angular? The assumption being that if someone can find they way around a framework they know the language. Not true.
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.
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
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.
> Today? No way can get away without knowing the language.
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.
the way I experienced it was really the word Front End really just went through different meanings. There are a lot of UI jobs where javascript isn't a major focus, though some of it is there. Despite what is heard on hacker news, a lot of dev is happening without angular, react etc.
I used to answer to jobs for Front End developer, but now you see Front end jobs posted with no relationship to design arts. Those positions are now UI Web Designer. Front End now from my perspective at looking at job postings might as well be javascript only or javascript plus SASS.
The problem is that there are a lot of developers who have obtained an 'expert' level understanding of some corner of software development who then wrongly gain the perception that that understanding is both necessary and reasonably expected among the general population of developers. It's not far away from interviewing an English teacher in Japan and expecting them to understand Latin because "latin is the foundation of English".
I think the books would take you to a basic knowledge of JS rather than expert level. This is the problem - the amount you need to know to be an effevtive programmer is growing out of control, as we attempt to make more ambitious applications than 10 years ago, for a decreasing (in real terms, unless you are in SV) salary. That means more weekends studying (working for free) to keep your place in this industry.
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).
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]
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/ (disclosure: I'm the organiser)
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".
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.
As someone who interviewed a lot of engineers, for product engineers I prefer someone with this mindset. Not to say that deep knowledge in the language is bad, it's just the user and product-focused mindset makes them more effective. They will spend less time bikeshedding on semicolons on pull requests and generally view everything from the lens of "how is this good for the product/user?".
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 used to have that mindset and it felt like a strength at the time, but now I see it as something that held me back from being better. Obviously it's best to stick to a high quality subset of the language in your code. But the brain doesn't run out of storage space, and having a deeper knowledge of the whole language brings context and confidence that makes you better at developing. These books have a refreshing, academic willingness to deep-dive into obscure language quirks out of pure curiosity, and the result is a fascination with the language and an understanding of why things are how they are. This means my whole approach to writing JS is now positive and creative, not resistant and resentful. Honestly, buy all of these books and read them, they're short and manageable and geeky and fascinating.
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.)
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.
> 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.
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.
This may indeed be true, but I've found the performance penalty to be acceptable for my use cases.
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'.
What intricacies are you referring to? I feel like I wouldn't get very far without knowing at least certain things about "this". For example how to to use bind, call, apply. Or rather certain things would be more tedious.
Mostly all the thisness (including bind, call, apply—but especially bind) and anything prototype-related. There may be others, but I've succeeded in forgetting them!
> 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.
I agree with Perlis, but he was championing languages like APL, which offer truly different ways of thinking about programming. The arbitrary ins-and-outs of extrinsically complicated designs are another matter; learning those doesn't necessarily affect one's thinking about programming for the better. I realize that what I'm saying sounds trollish, but it's something it took me many years to figure out.
On the other hand, for JavaScript you might want to take a look (beyond technical merits) at its social context. Client side JavaScript is deeply related to the design and implementation of the DOM. Whether we like it or not, the social aspect of browser really makes JavaScript unique in the history of programming languages.
That is the context of "the way of thinking" I am looking at.
That's quite an interesting take, but I've imbibed too many Alan Kay talks to buy it except as a case study in bloat. The social contexts leading to extrinsic complexity are many; those leading to breakthroughs of simplicity are precious few. I'd rather study the latter—and even better than study, be part of one!
@dang now with ES6 and Babel translator , you do not have to worry about OLD JS quirks. Happily write code in ES6 and let the Babel Translator do the hard work .
Easy learn of ES6 https://t.co/w1YYARnEnO
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.
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.
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.
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.
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.
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.
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.
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).
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.
I prefer double quotes to single quotes to strings: When you write C and C++ a single quote generates a character 8 byte literal. A double quote is a string an array of characters.
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/. Sort of a linked data approach.
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).
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.
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.
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.)
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.