I explain the title, and the intended tone and purpose of the book series, in the preface. If you wouldn't mind taking the 3 minutes to read it, I'd be curious if it changes anything about your opinion of the title:
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 hacks. But that always proved to be a mistake, because nobody wants to read or maintain any of that crap.
These days, I try to focus on the essentials of a language: What works well and portably? What offers unique expressive capabilities that I haven't seen before? What's idiomatic? If I learn any nasty corner-cases, I only do it solve a specific problem, or to avoid pitfalls.
I really can't get excited about the implicit conversion semantics of JavaScript's "==" operator or the weirder points of how "this" get bound in callbacks. It's all just pointless technical arcana. If something neither expands my brain nor solves an immediate commercial problem, I'm happy ignoring it until it becomes obsolete. And my clients are usually a lot happier, too.
(That said, the actual books are nicely written. But you asked about the titles.)
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.
The books point all the arcane points of the language so that the reader can understand them. They're also full of commentary like "never do this".
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.
I never once mentioned your books Kyle. I actually enjoy the parts that I've read. I was making a broader point that I have witnessed with the JS community: using technical arcana in production code as if it was a good thing. Just one example: https://github.com/twbs/bootstrap/issues/3057
Having played the "You Don't Know Jack" PC game from 1995 I found the title playful. From your preface I see you'll be doing exactly what I wanted from a book with this title. Going into all the areas I never would in a programming language. Not just how but why.
I agree with the GP though, on feeling some fatigue around people telling me I'm doing something wrong. Eating food, reading a book, tying my shoes, putting on a shirt. Anyhow it seems like you've just touched on that area a bit for this person. Experts don't like for Dummies books, not because they are rubbish, which they might be, but because owning or reading them visibly puts into question their knowledge and challenges their self image. In the same way someone might find your title a challenge to their knowledge, instead of seeing that you're interested in highlighting often overlooked things about JS.
For the love of God please don't put a giant headed person on your cover though. I've come to terms with every other book series having a positive quality with the exception of "Head First" and their distorted human cover photos. /rant
We all have our ticks when it comes to books and advertising around things we love.
side note: my kickstarter for the books, 2 years ago, playfully used the bald head image to catch people's attention (never the intended branding). I soon afer got a friendly lawyer takedown notice from the folks who own the game. We worked it out, and the new branding was born. :)
I'd suggest, "The Tough Parts", as you mention in the preface.
Not sure who your target market is but as a professional developer who writes javascript daily, "The Tough Parts", piques my curiosity and sounds like an interesting challenge. "You Don't Know JS" evokes a more negative reaction.
Honestly, I don't care what the title is, the books are great. I've recommended them a number of times as newer resources than "the good parts" and raganwald's, and not one person has asked if I thought I was implying that they were dumb. If anything, the title serves as a compliment, since anything I do not know is something that I can learn. If you know everything already, then why are you looking at books which serve to teach?
That said, from a marketing perspective, they've got a great unique cover and a solid series title. If more than the original 5 come around in the future, they'll be easy to identify.
Sorry, but I think it should be clear from my comment that your title is indeed putting people off of reading your work at all. I don't doubt that it's worth reading, but I think you should consider that the title itself, accuracy aside, is dissuading more people than just me from reading your work.
The point isn't the quality of your work. It's your hook that's failing at least some of us to the point that you are potentially missing out on part of your target audience by default.
I understand and appreciate your feedback. Unfortunately, given that most of the series is done and half of them are already in print, it's too late to change.
I did have lengthy discussions with my book editor about the title and its potential to be off-putting to some. We wrangled with the decision awhile, but ultimately came to the conclusion that most would find it a mix/balance of playful, attention grabbing (in a sea of "JS: The Handy Guide" type titles), and challenging.
The title itself is supposed to be equal parts a joke and a serious commentary on what I consider to be a disturbing trend in JS specifically, which is either a false sense of confidence or (worse) an apathy to not care about what is not known.
Again, thank you for your thoughtful response and your feedback. I do regret that it's hit you the way it has. Perhaps at some point you may give it another shot.
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 hacks. But that always proved to be a mistake, because nobody wants to read or maintain any of that crap.
These days, I try to focus on the essentials of a language: What works well and portably? What offers unique expressive capabilities that I haven't seen before? What's idiomatic? If I learn any nasty corner-cases, I only do it solve a specific problem, or to avoid pitfalls.
I really can't get excited about the implicit conversion semantics of JavaScript's "==" operator or the weirder points of how "this" get bound in callbacks. It's all just pointless technical arcana. If something neither expands my brain nor solves an immediate commercial problem, I'm happy ignoring it until it becomes obsolete. And my clients are usually a lot happier, too.
(That said, the actual books are nicely written. But you asked about the titles.)