JS has been my main language for the last decade and Axel (the author of the book) is my go to source when it comes to understanding upcoming features. I frequent proposal repositories, read the standard, and still find myself learning something new when I read an article from Axel on the subject. I have not read the book, but I'm sure it's written with the same rigor and clarity as all Axel's writings.
Clicked through to <a href="https://exploringjs.com/deep-js/ch_type-coercion.html" rel="nofollow">https://exploringjs.com/deep-js/ch_type-coercion.html</a> and I have to say that's already a bit questionable. The idea is there, but the writing around it is shaky (if you want to explain coercion, showing JS code without coercion without explaining that's what you're doing is not the best way to explain things to folks looking for answers).<p>Same for <a href="https://exploringjs.com/deep-js/ch_copying-objects-and-arrays.html#shallow-copying-vs.-deep-copying" rel="nofollow">https://exploringjs.com/deep-js/ch_copying-objects-and-array...</a>, the idea is there, but the text isn't great (is it only for objects and arrays? if I'm new to JS but someone taught me about Set and Map, can I assume those always deep copy?).<p>It's a great start, but it can definitely do with a few QA (rather than editorial) passes.
This is a bit off-topic<p>But I never understood prototypes and prototype inheritance, and how does that "map" to "classic" inheritance, from Java or C++. And I worked in FE for about 10 years...<p>It seems you can <i>model</i> "classic" inheritance using prototypes, but... there is something more there that I don't understand. I started using ES6 "class" as quickly as I could, but I still wish I understood what .prototype and .__proto__ is and how to use it. I feel like I "miss" a lot of JS when misunderstanding prototypes.<p>But none of my colleagues know either, so I guess I at least know what I don't know.
This looks like a good book but boy, is JavaScript convoluted. Not bashing it. Just read the chapters about shallow and deep copies.<p><a href="https://exploringjs.com/deep-js/ch_copying-objects-and-arrays.html" rel="nofollow">https://exploringjs.com/deep-js/ch_copying-objects-and-array...</a>
It is appreciable that he offers a discount for those for whom USD is ridiculously expensive in their own currency or have previously bought his books. Though I wish he would rather send the discount code via email rather than ask for a mobile number, which is rather invasive.
This is very useful right now because I'm about to embark on learning js to be able to write aws-cdk infrastructure code, after finding Terraform to be annoying in some ways. (mostly its declarative nature means any logic can be difficult to shoehorn in).
Decided to buy the javascript for impatient persons book and start reading it on my tablet.<p>(more offtopic, but we'll be using TypeScript, so I'm going to need to find some good guides for that too - any suggestions?)
I have been using and advocating Javascript for over 10 years.<p>I believe language evolution like ES6 are more than welcome. However, I have the impression that the path taken by the committee and the new proposals do not bring great gains (whether in UX, code reading, performance, etc.) but bringing unnecessary complexity.<p>On the other hand, other serious problems such as the mathematical and numerical part of the language are being left aside.
The URL should go the the front page of the book (<a href="https://exploringjs.com/deep-js/" rel="nofollow">https://exploringjs.com/deep-js/</a>) rather than the table of contents.
This looks really good and I'll probably read a little here and there when I get the urge. But I don't think deep knowledge of JavaScript will pay off in today's web development world.<p>I deep dived JavaScript many years ago so I could move away from C#. It was only useful in interviews so I could answer all the esoteric trivia. On the job it was using JS frameworks and libraries like Lodash. And then TypeScript came along and eclipsed it all together.<p>You're better off learning just enough JavaScript and then deep diving TypeScript and Angular, React, or another framework.
I'm finding the serif font, whitespacing & line width, and inline code style quite hard to parse.<p>The whole thing reads (visually) as a bit of an indiscriminate jumble.<p>The following changes help (me). I'd also look at colouring some other sections to clarify the visual flow of document,<p>```<p>pre {
background-color: #EEE;
font-size: 1.2em;
line-height: 1.4;
margin-left: 1em;
padding: 1em;
}<p>body {
font-family: sans-serif;
font-size: 1.2em;
}<p>#page-content {
margin: 2em auto 2em auto;
max-width: 40em;
font-size: 1.1em;
line-height: 1.7;
}<p>```
Not sure why author uses the phrase "pattern matching algorithm". There is nothing algorithmical about it. This is just a pattern matching language feature similiar to Haskell's. And since JS is dynmatically typed, I believe this is really just sytnax sugar at the interpreter level.<p>Unless there is something time/space-specific about it, invoking "algorithm" feels to me an abuse of terminology. Of course will love to be enlightened otherwise.
I've always found Raganwald Braithwaite's JavaScript Allongé to be a wonderful demonstration and application of the kind of idiomatic classless JavaScript you get when you understand the language's OO properties.
I haven't read the book yet, but the topics themselves are quite intriguing and looks useful. Definitely a good hammer to break out of the "advanced beginner" chamber.