Javascript is probably an excellent example of something written without any consideration of how it would work at scale (which is exactly what we tend to promote). The idea of it suddenly being used for writing single page applications and entire UIs, and now servers and god knows what else, was probably unthinkable at the time.<p>It wasn't that long ago when all JS did was put snowflakes on a page, or trails of fire behind your cursor, or annoying sequences of alerts and prompts. And it was called DHTML.<p>Were it possible - in the 90s - to anticipate the recent surge in popularity of JS, maybe we would have had a totally different language.<p>That said, these 'gotchas' are just part of learning the language. Same with PHP really. With a sufficient level of experience you tend to forget they actually exist.
Replace article with link to Crockford and John Resig's advanced JavaScript tutorial.<p><a href="http://ejohn.org/apps/learn/" rel="nofollow">http://ejohn.org/apps/learn/</a><p>Any list of gotchas that omits discussion of falsiness, objects vs arrays, array-like things that aren't arrays, the array sort function...<p>And the throwaway comment about JavaScript being poorly designed is facile and annoying Every language anyone uses has warts.
TL;DR: Poorly written shallow analysis.<p>Really, he should've used a different title, say "JavaScript Rant"<p>The author complains about the was language is designed, and says "might", "in some cases", "this is wrong" etc. without showing real examples. And he's also dead wrong on a few facts (like JS being a pure functional language).<p>Looks like "let's bake something in 5 minutes" and post it to HN to get 57 points for nothing.
The answer to "Why are there so many different ways to declare a function? What are the differences?" doesn't really answer the question.<p>No error:<p><pre><code> <script>
myFunction();
function myFunction() {};
</script>
</code></pre>
Error:<p><pre><code> <script>
myFunction();
var myFunction = function() {};
</script>
</code></pre>
A correct answer should explain why this happens in order to understand what the difference really is about.
The gotchas are fine, but the explanations are very poor. I'd like justifications or references.<p>I would prefer Ben Alman, Douglas Crockford, John Resig, Paul Irish, or one of the many talented people writing about javascript if you were actually interested in understanding the gotcha's on this list.<p>Also, I wish authors would be careful to distinguish js from jQuery. Yes it's standard now, but preferences change with time.
<p><pre><code> function myFunction(arg1, arg2) {}; // This is OK, but...
var myFunction = function(arg1, arg2) {}; // This is best!
</code></pre>
<i>The second option is better, and is properly scoped, but it leads to certain syntax problems once you get into closures.</i><p>What problems? How does assigning the function to a variable help avoid needing to make a closure for <i>this</i>?
Cannot decide which is a worse language, Javascript or PHP.<p>It is quite amazing how much effort people putting in to designing the "perfect" language, and yet we continue to see highly flawed languages get popular.<p>I wonder if we'll ever see a replacement for JS in the browser? Maybe just a JS-strict with all the gunk and strangeness removed (and maybe the libraries cleaned up a LOT).
The tone of this article does absolutely nothing to help a new learner. While mostly factually correct, constantly complaining, whining, and saying what a stupid design decision this or that was helps in no way.<p>Every language has quirks. In the case if js, the things your complaining about like var and function declaration are features of the language.
There have been a lot of articles re-hashing Crockford's analysis floating around recently. These have been valuable, but they tend to focus on the same topics in the core language (largely concerned with scope, use of closures, behavior of basic data types, and functional programming). In web development, the DOM and events end up being a more common area where I and other devs are tripped up. A few things I wish I knew before a deep dive into an large scale JavaScript project:<p>1) Newly added elements will not respond unless events are bound to them. One solution (thinking in jQuery here) is to bind events higher up the DOM.<p>2) Each line in code may not simply execute in sequence. For example, asynchronous ajax calls require subsequent calls to be nested in callbacks.
Wow, glad to see this is stirring up a lot of discussion. Thanks for all your contributions guys.<p>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:<p>#1: The list is missing a lot of very well-known JavaScript gotchas.<p>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.<p>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.<p>#2: The list seems very negative and biased against JavaScript.<p>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. :)<p>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.<p>#3: This seems full of preferences, not hard-and fast rules.<p>That's definitely by design as well. I circulate this list out to my team and so it has my fingerprints all over it.<p>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.<p>#4: The author comes across as snarky and unhelpful.<p>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.
Because of semicolon insertion, Allman-style braces are frowned upon.
<a href="https://www.google.com/search?q=javascript+brace+style" rel="nofollow">https://www.google.com/search?q=javascript+brace+style</a>
Thanks for this, bookmarked.<p>I actually find little quick explanations like this extremely pragmatic and useful. I don't do a whole lot of JS, but I certainly need to dive in occasionally. Having quick references like this one readily available is preferable to finding my Crockford book and flipping through the pages. If you need to develop a client-side app or do heavy JS coding, maybe read the Crockford book...but if all you need to do is get some shit working real quick links like this one are invaluable.
This list isn't even well thought out at all and is more just a rant about some random stuff. I'm not a big fan of the javascript type system in any case but this isn't a real critique of it.<p>At some point just like Monads you just get the javascript type system and don't worry about it anymore. It is what is. No amount of gotchas will get you over the hump; you have to actually understand it. At least it isn't syntax like C++ where you find out in a WTF moment that the parser is doing something insane.
Some Gotchas should be cached by the ECMAScript 5's "strict mode", see <a href="https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Functions_and_function_scope/Strict_mode" rel="nofollow">https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...</a>
You should jsperf your function definition advice. The standard "function foo() { ... }" way is over 10x faster than the "var foo = function foo() { ... }" way or any other variant.
gotta be honest.. not loving the tone of this post.<p>40% of it just keeps droning on about how noobs will fall for these traps, and saying things like "If you are new to JavaScript, I suggest avoiding the this keyword".. as if these concepts are so mind blowing noobs minds will melt.<p>it does bring up a few good points but it could have been a lot shorter.. and how is closure a common js gotcha? the list includes 4 javascript constructs veiled into a rant.