91–100 of 111 posts
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.
Earlier quoted context omitted.
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.
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'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 to…
Earlier quoted context omitted.
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!
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 to…
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/
Earlier quoted context omitted.
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 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.
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.
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.
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 foundatio…