You Don't Know JavaScript Book Series
61–70 of 84 posts
Re: You Don't Know JavaScript Book Series
#62Earlier quoted context omitted.
Nope, it still doesn't work for me, personally. I never played "You Don't Know Jack", and so I tend to interpret your title literally. And your title implies that no matter how much somebody knows about JavaScript, it's not enough. Two decades ago, I was really into learning all the disgusting corners of badly-designed programming languages. I got really excited about C++ implicit conversions and clever template hack…
This. "Technical arcana" is exactly right. Your code should rarely be clever or rely on the the weird dark corner-case cruft of a language. Too often I see JS code written like an entry in the Obfuscated C contest. Yes, that code can work, but don't do that.
Rather than most books which gloss over the "bad parts", which prevents people from fuller learning and leaves them to their own devices when they run across that stuff in the real world, YDKJS covers all the parts, and tries to use the deeper understanding as a tool and guide to making better-informed decisions about how to effectively write JS.
I think it's entirely unfair to suggest that covering "technical arcana" is the same thing as endorsing it.
Re: You Don't Know JavaScript Book Series
#63I take the title to mean that someone has taken time to do some research and share it with me. reading the material will help me fill in some gaps and hopefully dispell or validate assumptions I never took the time to test.
Re: You Don't Know JavaScript Book Series
#64Six books, each $20, none of them that big? That seems excessive to me. Does it need to be spread so thinly?
You sound like middle management weighing lines of code instead of quality of work.
Re: You Don't Know JavaScript Book Series
#65"You don't know x." "10 things you didn't know about y." "Everything you thought you knew about z is wrong." Am I the only one that finds titles like this completely offputting? If you think you have insight that's useful to people, try not talking down to them. As it is, hell, I may not know Javascript, but I'm certainly not clicking through.
My problem is (usually) ignorance, and I'm looking to correct that. If I'm an idiot, no book will fix that.
Re: You Don't Know JavaScript Book Series
#66Re: You Don't Know JavaScript Book Series
#67I think it could be great to give an order for reading the series for someone that's learning JavaScript. I often recommend this series but everyone asks me where should they start reading.
https://github.com/getify/You-Dont-Know-JS/blob/master/READM...
Also, the "Up & Going" title, Chapter 3, has descriptions about the titles and the narrative/story arc being told across them, which helps understand the intended order as well:
https://github.com/getify/You-Dont-Know-JS/blob/master/up%20...
Re: You Don't Know JavaScript Book Series
#68Earlier quoted context omitted.
Am I the only one that finds titles like this completely offputting? No, you aren't, though FWIW I try to force myself to at least look at what's been submitted before commenting, in the spirit of not judging books by covers and all that. In this case, I found very little to suggest that I do not, in fact, know JavaScript. I'm also assuming that this is a very early draft of the material, but it could certainly benef…
> I found very little to suggest Just curious what parts you looked at? Did you glance at the table of contents, or did you read full chapters? I certainly tried to reveal in every chapter several different things that, in my professional experience teaching JS to teams of developers, are commonly misunderstood or under-understood. If you had any specific feedback on what I could have done better to live up to the ti…
I skimmed through pretty much all of "Scope & Closures". I also looked through the first few chapters of "this & Object Prototypes" to see whether they were any better.
If you had any specific feedback on what I could have done better to live up to the title, tone, and mission of the book series, I'd be appreciative of it.
Sadly, with that title and your chosen goals, I think you left yourself no chance of meeting expectations right from the start. If you're going to tell me I don't know a language I've been using for 20 years, you'd better mean it in the sense that there is something significant and new in your book, perhaps some cutting edge developments in the language itself, or maybe an original application or new perspective on how to use what was already there. In this case, the closest you get in the books I looked at is touching on a few basics of ES6 -- nothing wrong with that, but hardly earth-shattering news to a professional who runs 6to5 (ahem sorry, Babel) every day.
Leaving aside the title, though, the material is often surprisingly narrow and imprecise if your intention is to teach the subtle details of JavaScript more thoroughly than many programmers might know them already.
Your opening paragraph of chapter 1 makes several debatable claims. For example, your characterisation of mutable variables as fundamental to nearly all programming languages immediately ignores alternatives such as purely functional or logic languages. That is perhaps an unfortunate choice given the current trends in JS libraries and frameworks, which in many cases are moving in that more declarative direction.
You then seem to conflate various concepts of scope, storage and lifetime throughout the book, and similarly do not seem to distinguish clearly and consistently between the concepts of identifiers, variables and values. In a language where closures and references to functions are used routinely and where you have some types passed by value but others effectively passed by reference, these kinds of distinctions matter, particularly to someone who has learned by osmosis or perhaps come from a background working with other programming languages, which seems to be a lot of your target audience here.
More generally, your terminology tends to drift away from the ECMAScript spec quite a lot, again making it less precise. Another example would be the opening paragraph of chapter 1 of "this & Object Prototypes", where you describe this as being a "special identifier keyword". By definition (in the spec) an identifier can't be a keyword, because an identifier is precisely an identifier name that is not a reserved word.
The most vague section of those I read was probably when you discuss closures in the final chapter, where I'm sorry to say you come across as rather unfamiliar with the concept yourself. Your usage is somewhat casual, unidiomatic even, not least in your definition of the term itself. Your explanation for where closures come from ("Closures happen as a result of writing code that relies on lexical scope. They just happen.") is just plain wrong, as evidenced by the fact that numerous languages with lexical scope do not provide closures as a language feature at all.
Sorry if this all seems a bit nit-picky, but you did just write a book about the importance of understanding the details and telling me I didn't know the language. :-)
Re: You Don't Know JavaScript Book Series
#69Here's the thing, I do know Javascript pretty well after reading Crockford [1], Braithwaite [2], and Javascript Garden [3]. Much of the behavior of the language is simply too subtle and failure-prone to bother with, especially when working on projects that aren't composed entirely of world-class JS devs (e.g. every project ever). In its full expressiveness, Javascript yields code that simply does not do what you thin…
It's true that crockford, javascript-allonge and JS Garden are all good resources but they are simply not as up to date as YDRNJS and they're not as covering.
This book doesn't cover 'with' in depth or anything like it. It explains idioms that have formed since "The Good Parts" came out - that was a long time ago and a lot happened since.
Re: You Don't Know JavaScript Book Series
#70i'd be curious to hear others' opinions, but it seems to me JS isn't the sort of language that one wants to master in itself. it's very much a language defined by its use cases. then again, i'm just trying to become an all-around better fullstack developer for my current employment situation - so i'm mostly using (and pull-requesting) frameworks rather than writing my own given this perspective, i'm much more interes…
This book isn't about the edge cases of how `==` works or how `>` works when comparing objects of different types. It's about the fundamentals of the language and the idioms and how to write effective code using them.
If you already know JS very well you can skip it or skim it - but if you're a 'framework developer' as a reader I guarantee that it will be worth your time. If your JS is already very good - you might want to consider spending your time learning another language or technology rather than being "more great" at JS unless you want to get involved in the specification process.