"Kyle Simpson8 months ago Report Abuse
I can assure you, my goal of splitting up the content into a book series had ZERO to do with making more money. It's actually quite the opposite. One of the things I hate the most about tech books is that I spend $35-50 on a big book of which there's only a few chapters I actually care about. I almost never read a whole book.
I decided when I wrote this content that I'd make each logical chunk of content available separately, which means that you can buy only the stuff that you actually care about. This COULD quite likely mean that I make a lot less money in the overall picture, because there will be plenty of people who don't buy all the books, or even not enough of them that would have generated the same income as a single book would have.
This places you, the reader, more in control, not only of what you buy and own, but more deeply of what you spend your money on compared to the content you get. Rather than being about me greedily making more money, it rather downgrades my ability to make bigger chunks of money per copy for the majority of people who (like me) only want/need part of the content.
With regards to this content being "pointless", that seems quite a spurious and unsubstantiated claim. Pointless to you? Perhaps. But I feel quite certain there's a lot of content in there (like block scoping, etc) that most developers (and perhaps even you) aren't fully aware of. If you're already a JS expert (even on all the new ES6 stuff coming), then you probably do know JS and I'm not sure why you bought the book.
The spirit of the whole series (given the title) is to get us all (myself included) to admit how we don't fully know JS and how we need to dig deeper than we have before. If that's lost on you, I'm sorry.
One last comment: these books are all available fully for free to read here: http://YouDontKnowJS.com In addition, Amazon's site makes preview snippets of the book available to read for free so you can get an idea of what you're buying. It's a shame you apparently didn't read the content/previews before buying, you could have saved your $5-7 (at least it wasn't $35-50)."
Maybe splitting things up into very self-contained contexts makes a lot more sense than writing another tome.
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.
0.1 * 0.2 //0.020000000000000004
This title caught my attention, so first purpose, check.
Great title. I haven't read the book, so I don't have any opinion on it beyond that, but can we try and take things a -tad- less personally?
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 interested in the entire [and rapidly expanding] toolchain for modern js development - and learning the language's esoterica [and i am the sort of person who takes pleasure that stuff] as i become an all-around better js dev
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.
Well, depends how you define "master". To become a leading expert on it would mean taking time away from other skills, which probably wouldn't be wise. But if you're using JS quite a lot then learning it to an arbitrary level, let's say 80% of "master", well, that probably would be a good shout.
I suppose it depends on your skillset projection, do you see yourself spending a lot of the next five years with JS? If so, invest now in personal development. If not, maybe skim read it.
If you're going to make JS your primary language that you write on a daily basis, doesn't it make sense to invest more time into learning it than just whatever you might accidentally pick up through trial-and-error?
Most developers in most other languages do tend to take formal learning of the language, to a deep extent often, a more serious task, but with JS it seems many developers just kinda get whatever they get along the way.
I have found that approach to be good at getting and keeping yourself employed, but bad at giving you any confidence that you actually know what's going on. If you aren't really sure exactly why your code works, my theory is that you'll never know exactly why your code doesn't work either.
I'm just trying to provide resources for developers who want to take learning JS seriously, and challenge "all" of us to ask, "just how much DO I know JS?" The rest is up to you. :)
Does it need to be spread so thinly?
I'm trying to work with O'Reilly to bring down the prices on the books a little bit. I always wanted them to be priced so that price wasn't a barrier to entry. As you can imagine, there's lots of intricate details which restrict what I can do with pricing.
> none of them that big
Page counts on the titles (so far) are: 65, 98, 176, 189, 296. The last book isn't finished yet, but I'm projecting it to be somewhere around the 150-200 mark.
I can appreciate that $20 for a 100pg book may feel "excessive", but what about $26 for a 296 page book?
Moreover, I'm working (still) on getting O'Reilly to release a box set for a flat price that will be much more reasonable than buying each book individually, so that if you want the whole series you'll have an affordable option for that.
And you'll of course still have the option to buy just one or two of the books if that's your fancy.
I just looked at a couple, and it seemed like it was being split into small chunks (60 pages, 100 pages) as a way of selling more of them. Clearly I should have researched further!
You sound like middle management weighing lines of code instead of quality of work.
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:
but were afraid to ask."
By Woody Anybody
There are some edits and refinements that happen to the content during the publishing/production phase at O'Reilly that aren't necessarily appropriate to back-port to the repo. But I do try to get most of the main substance stuff sync'd.
The free GitHub repo versions of this content represents the drafts of the books in the mostly complete stage, whereas the published books (digital or print) are the final, final versions.
"10 things you didn't know about y."
"Everything you thought you knew about z is wrong."
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.
(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.
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 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.
These are what the covers of all the books in the series look like:
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. :)
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.
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 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.
In fact, I'd go as far as to say a lot of other books could learn a lot from the layout of the series. I've read many books and the dry books don't hold my attention for long. There is something to be said for books you just absorb.
E.g. "You don't know what callback hell means. You don't know the horror of refactoring a weakly typed dynamic language. You are truly blessed for you don't know JS."
Learning JS is very different from other languages in that there's greater amounts of misinformation (lots of people know it, but prefer to use it as little as possible), and it changes faster. For example, in 2015:
- you won't find any Python new articles that tell you to use Python 1's 'strings' module
- You'll still see things like <script> tag soup, 'JS isn't object oriented', globals and patchable-ES3-isms in new JS articles.
Kyle Simpson is a well known JS speaker and O Reilly author - his books are a great source of current best practice.
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.
I'm also assuming that this is a very early draft of the material, but it could certainly benefit from the input of a good editor before any final publication.
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 title, tone, and mission of the book series, I'd be appreciative of it.
> very early draft
Depends on which book(s) you looked at. The series is 18 months old by now, with 6 titles. 5 of them are already "complete".
3 of them have already been edited and published (though publisher edits didn't necessarily all make it back into the free repo versions).
2 of them are in final editing and production stages, so they're still being cleaned up. The sixth one is still a very early and partial draft, so it's quite rough.
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.
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.
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. :-)
My stronger reservation is that these books have a lot of loose writing and give so much space over to asides or describing bad practices that someone who wasn't so experienced might still not know JS by the end, having missed the wood for the trees.
Anyone who doesn't have imposter syndrome hasn't tried the exercises in TAoCP.
In fact it's so easy that you can make a snide comment criticizing someone else's criticism and it will do really well if you throw in some unnecessary and ridiculous "male dominated" comment.
My problem is (usually) ignorance, and I'm looking to correct that. If I'm an idiot, no book will fix that.
It's amusing if anything.