tl;dr: It’s a 150 page essay on auto-boxing, full of dangerous code examples and anti-patterns and soft warnings to “not do what I just did”, and some of the wording is not-wrong-but-not-quite-right, but hey there are some decent parts, I guess.
This is an admirable goal, and one that I fully support. But when I got to the end, I scratched my head and wondered aloud: “Did I just finish a 150 page essay on auto-(un)boxing?”
But… My biggest issue comes from what I perceive to be a… almost reckless or dangerous approach to presenting the material. What I mean by this is that while many of the code examples are technically correct, they are not idiomatic — in other words, you wouldn’t see code like that “in the wild.”2 Sure, you can use the
String constructor to create strings–but this almost never offers you any advantage over simply creating a string with literals.3 Granted, to Lindley’s credit, he states in numerous places in the text that “no one really does this” or “you should just use the primitive/literal form of this” — but after also asserting (right at the very beginning) that the reader should pay more attention to the code… Well, I’m fearful that those same readers will pick up hard-to-break bad habits.
And I think that’s why my reaction was to think: “This is a dangerous book.”4 As an author, you’re in a powerful position as a teacher and role model–so if you’re demonstrating “weird” code or error-prone techniques or calling things by the wrong name,5 then you might wind up influencing a bunch of developers into those bad habits–even if you didn’t mean to, even if you warned them against those exact methods.
Perhaps I’m over-reacting a little bit, but believe strongly that these things matter.
“Comma-first” or abusing ASI is one thing… But using
Number where you should be using
parseInt is quite another.
I had other criticisms as well (e.g., talking about “associative arrays” is always a sketchy proposition when your target audience is JS novices; e.g., making no mention of strict mode whatsoever6) but they’re really just pale variations on “the big one” above.
Disclosure: I received an electronic copy of this book from the publisher in exchange for writing this review.
- At the time that I wrote this review, most of the ratings on Goodreads are 5 stars. [↩]
- Or shouldn’t, anyway. [↩]
- Most of the time it will hurt you, or confuse the
- I had a similar reaction when I reviewed Eric Sarrion’s jQuery UI. [↩]
- For example: not calling “auto-boxing” by name. For example: calling it a “self-invoking anonymous function” instead of an “immediately-invoked function expression”. [↩]
- The omission of strict mode seems like a major oversight to me. I realize that Lindley’s discussion was germane to ES3 and not ES5–but
'use strict'is out there in the wild, and it can dramatically alter some of the behaviors described in this book. If the target audience really is people that are diving into the plumbing of their essential libraries, then some of them are going to see this and not realize the significant implications it might have w/r/t/ some bug they’re trying to trace. [↩]
About Rob FrieselSoftware engineer by day, science fiction writer by night. Author of The PhantomJS Cookbook and a short story in Please Do Not Remove. View all posts by Rob Friesel →
Nobody would ever write a book if the value/quality of the book is based on what someone might or might not do with the information. Knowledge is dangerous, but as an author I’ve given the reader the benefit of the doubt and treat them as a mature thinker. Treating them otherwise is more dangerous.
Its obvious the book was not written with you as it’s targeted reader. This review is short-side and contradicts itself (you don’t recommend the book then at the end you do with qualifications). Its obvious you have a very good grip on what the elitist should think, but fail to grasp how someone besides yourself might think about a topic. This book was never meant to be a replacement for Zakas book. In fact I recommend that book over this material all the time. However these two books are different and have different readers in mind. The low view you have of a book of this nature leaves little room for people who are not as knowledgeable as you. This is the form of elitism that made me write a book like this. I think your own words are correct, your “skepticism” is unfounded, especially given that you are not willing to consider the state of certain types of readers outside of yourself. Which is exactly what an author should do.
I’m trying to give my honest assessment. There is plenty to like about the book, and I admire the intent behind it — those are difficult waters to navigate. It isn’t so much that I have a low view of a book like this, just that I think it’s extremely difficult to get this right; I don’t know if this would have helped me back when I needed it, but I do hope that it’s helpful for others. That I did not go into detail on each of the redeeming parts is perhaps a failing on my part. Nevertheless, I stand by my review (as you stand by your book) and appreciate your chiming in here.
I felt the same way when reading the material. I think it is very telling that the author does not have a strong background in programming/computer science, and was given that opportunity to write a book about JS, unprepared. Things like this should be left to folks like the Resigs, Zakas, Braithwaite, etc. Also, I’m noticing that the author does not take criticism well…part of being an author is to accept the outcome and not deter people’s opinions, even if you don’t always agree.
@Scott: I don’t think that’s totally fair. Lindley has a pretty long and successful career in the field, and I don’t think he went into the book unprepared — it’s mostly that I don’t agree with how he presented the subject matter.