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