Name: This & object prototypes
ISBN: 9781491904152

What Hacker News says

ciw1973Jun 2017

"Eloquent Javascript" (http://eloquentjavascript.net/) definitely gets my vote, as it starts with concepts that someone new to programming would need to understand before diving into the specifics of the language. Available to read online for free, although well worth spending money on a physical copy to thumb through, but it may be a little too slow to get going for someone who already has experience with other languages.

For developers, I'd recommend Kyle Simpson's "You Don't Know JS" books, in particular "This & Object Prototypes", followed by "Scopes & Closures". Well written, with plenty of example code, these are deep dives into specific areas which make Javascript different/weird. They're available to read in his Github repo (https://github.com/getify/You-Dont-Know-JS), but consider buying them, as he deserves to get paid.

thread

ksmithbaylorMar 2015

I have been reading through this awesome book series called You Don't Know JS (youdontknowjs.com), and it's helped me SO MUCH to understand JS at the next level.

I had the immense pleasure of taking a workshop with Kyle Simpson, the author, at a conference last year and it covered much of the material from his books. In particular I found the book on 'this' and object prototypes to be fantastic.

thread

sentientforestDec 2019

Data Intensive Applications

This and Object Prototypes (You Don't Know JS Series)

Fall: Or Dodge in Hell

Fortress Marin

Count Zero

Become What You Are (Alan Watts)

Swords and Circuitry

Operating Manual for Spaceship Earth

The High Sierra of California

Trees of Power

I highly recommend Data Intensive Applications, as have many others on HN.

If you live around San Francisco, and don't know the history of the shore batteries across the Bay, Fortress Marin is a nice, short, illustrated history of California's coastal defenses. There are good places to go hiking / camping in that area around the old fortifications.

I'm into planting trees and gardening, so I thoroughly enjoyed Trees of Power by Akiva Silver.

thread

SilhouetteFeb 2015

Just curious what parts you looked at? Did you glance at the table of contents, or did you read full chapters?

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

thread

_getifyMar 2014

Huge fan of this article. Makes some really great points! Wish I could share and vote it up a thousand times. :)

I have been writing about exactly this topic, of why classes don't make sense (specifically for JS), in my second title of the "You Don't Know JS" book series, "this & Object Prototypes".

In particular, Chapter 6 makes the case for an alternate pattern to class-orientation design, which I call OLOO (objects-linked-to-other-objects) style code. OLOO implements the "behavior delegation" design pattern, and embraces simply peer objects linked together, instead of the awkwardness of parent-child abstract class semantics.

https://github.com/getify/You-Dont-Know-JS/blob/master/this%...

thread