I did not put that there because it was the best syntax. :) I put it there because I felt it was most likely to be understood by someone new to the language. I assume you're implying I should have used {}?
Yes, not for the syntax itself, but for a mere "smell" of code quality. The use of "new Object" is found only in two kind of JS code incredibly old or incredibly badly written.
I hear you completely. But understand that my intent here was not to write idiomatic code, it was to write code that an outsider to JavaScript would understand. I worry that the {} syntax, while simple/elegant/preferred, may be somewhat less obvious to a new person who is unfamiliar with JavaScript's object literals. In any event, I've updated the article to include both ways.
Regarding variable hoisting, I am trying to keep this article short, concise, and focused on the big offenders when it comes to gotchas. The only reason I didn't discuss hoisting is because I felt it would introduce too many concepts at once. To me, hoisting is kind of "level 2," whereas understanding why var is required is "level 1."
And on a side note, I appreciate all the feedback you're providing here - I really do. That's why it's on GitHub and not some blog somewhere. But I would suggest that we separate personal attacks from code criticisms. If you don't like my approach with this article or you find something that's flat-out incorrect, by all means tell me. As a human I am prone to make mistakes - maybe moreso than others. :)
But please avoid making value judgments about a person you don't even know, such as calling them an ignorant. It's bad enough when people behave this way on the internet, but if that kind of mentality starts to seep into your "real world" life too, it'll start having serious effects on team relations and employability.
I'm sorry for my personal stakes at you. And honestly I have to say I'm biased against javascript articles, because I'm so used to find a strong lack of experience and knowledge in them. I appreciate your answer, and please pardon my rudeness.
At the same time you could make a "level 1" article a lot more adherent to reality. For example, you could completely jump over that "function creation" section entirely, and simply do a clear explanation of what an expression is in JavaScript, and how to spot them.
Again, thank you for your personal advices, and thank you for your politeness (as opposed to my manners).
I tried not to get too deep into the explanations because I really, really wanted to keep this to a short list that could be scanned and grokked.
Truth be told, if someone wants an explanation of some of JS's weirdness, there are far better articles out there they can Google to meet that need. :)
I really didn't want to write that. Ignorance is never really a good solution. :)
But from my experience, someone who is coming into JS for the first time is probably not setting up a complicated object hierarchy - they're probably just trying to figure out how to bind some events to a DOM element and get some basic UI functionality. And they probably don't need to use the this keyword as much as they think they have to.
I completely agree that this could be a bad decision on my part, or at least a very controversial one. But I'd rather have truly new JavaScript developers focus on things like encapsulation and closures before they get too far into the this keyword and constructor/prototype.
My apologies if I came across this way. The intent was not to whine about var or function declaration, but rather to provide clear direction about a standardized "okay" way of doing these things without causing yourself undue headaches.
So please don't interpret my calling these issues out as whining. Just trying to make new people aware that they are there. :)
If, on the other hand, I am legitimately WHINING and not realizing it, also feel free to tell me where so I can fix it. Thanks!
Fair enough. Definitely not a personal attack or anything. I used to have the very same thoughts until I really learned how powerful many of those confusing things are.
I've gone through and removed some of the bristly "flavour" language. If you want to scan through it again and look for more offenders I'd be greatly appreciative.
My only worry is how long it'll take for ES6 to get adopted. It's one thing to write a spec and implement it into the compiler yourself...it's another thing to write a spec and wait for several key browsers to implement it.
Wow, glad to see this is stirring up a lot of discussion. Thanks for all your contributions guys.
There are a ton of comments down below with a ton of criticisms and suggestions. I will attempt to summarize and respond to the key ones here:
#1: The list is missing a lot of very well-known JavaScript gotchas.
That's intended. My goal here is not to provide a complete, comprehensive list of all known quirks with the language - those exist in far better fashion on the web already. Rather, my goal is to create a simple list of issues that I KNOW will trip up newbies out of the gate.
Oddness with truthiness, undefined and arrays is definitely irksome, but from my experience people tend not to run into those problems until they've already written a good chunk of JS. On the other hand, issues like var, confusion over closures, and the this keyword come up very quickly - almost immediately.
#2: The list seems very negative and biased against JavaScript.
My apologies, as that was not the intent at all. JS is great. But it is also extremely flawed and there are some things flat-out wrong with the language. I'm definitely not the only person who says this, either. :)
It's a great language to work in and you can do some wonderful things with it once you grok it, but if we're going to be completely objective, we have to admit that it has some definite problems that make it hard to learn.
#3: This seems full of preferences, not hard-and fast rules.
That's definitely by design as well. I circulate this list out to my team and so it has my fingerprints all over it.
If this is a real sticking point with you guys and you feel it would be better having that stuff removed, please send me some pull requests and I'll be happy to review.
#4: The author comes across as snarky and unhelpful.
That's just a personality flaw and I apologize for it. :) I didn't want this piece to be dry and I injected a bit of voice. If you feel it's actually detracting from the article, please feel free to shoot me some examples and I'll clean it up.
Oh, and one more thing. If you see anything in there that's flat-out WRONG - not just a preference or stylistic choice, but actually WRONG - by all means, shoot me a pull request! That's what it's there for.
