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.

Were it possible - in the 90s - to anticipate the recent surge in popularity of JS, maybe we would have had a totally different language.

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.

http://ejohn.org/apps/learn/

Any list of gotchas that omits discussion of falsiness, objects vs arrays, array-like things that aren't arrays, the array sort function...

And the throwaway comment about JavaScript being poorly designed is facile and annoying Every language anyone uses has warts.

Really, he should've used a different title, say "JavaScript Rant"

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).

Looks like "let's bake something in 5 minutes" and post it to HN to get 57 points for nothing.

No error:

  <script>

  myFunction();

  function myFunction() {};

  </script>

  <script>

  myFunction();

  var myFunction = function() {};

  </script>

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.

Also, I wish authors would be careful to distinguish js from jQuery. Yes it's standard now, but preferences change with time.

    function myFunction(arg1, arg2) {};       // This is OK, but...
    var myFunction = function(arg1, arg2) {}; // This is best!

What problems? How does assigning the function to a variable help avoid needing to make a closure for this?

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.

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).

Err.. since when did JavaScript become pure functional?

Every language has quirks. In the case if js, the things your complaining about like var and function declaration are features of the language.

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.

2) Each line in code may not simply execute in sequence. For example, asynchronous ajax calls require subsequent calls to be nested in callbacks.

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.

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.

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.

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.

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.

In the second, the var myFunction gets hoisted to the top but not the function definition, which is why calling it produces an error. In the first, the whole function gets hoisted to the top.

All variables are hoisted to the top of a function, where they are defined as 'undefined'. This is confusing, I know - there is actually a difference between an undefined variable (accessing it will cause a ReferenceError) and a variable defined as 'undefined', which is in many cases identical to null, except in object syntax.

An example you can run in your inspector:

  function foo(){
    console.log(a);
    var a = "string";
  }
  function bar(){
    console.log(a);
  }
  foo(); // logs 'undefined'
  bar(); // throws ReferenceError

Well, this is because of the variable hoisting. Before running a function, the interpreter scans for any var definitions and 'hoists' them to the top of the function, where they are set to undefined. This leads to the strange situation where defining a variable after it's been accessed (as in foo()) actually prevents an exception.

The same is true of functions defined with the 'function name(){}' syntax. As opposed to the 'var name = function(){}' syntax, the entire function (including the definition of the function!) is hoisted to the top of the containing function. So this will work:

  function foo(){
    bar();
    function bar(){
      console.log("works!");
    }
  }
  foo();

  // old version
  function longFunction(){
    // 50 lines of code
    // awful, messy
  }

  function refactoredLongFunction(){
    doFirstThing();
    doSecondThing();
    doThirdThing();

    function doFirstThing(){
      // ...
    }
    // other function definitions
  }

If you'd like to know more about function and variable hoisting, this is a good read: http://www.adequatelygood.com/2010/2/JavaScript-Scoping-and-...

EDIT: To clarify:

All variable declarations in Javascript do indeed get hoisted to the top of the scope, but with function declarations even the function value itself gets hoisted. So for instance, this returns 'two':

  function foo() {
    function one() { return 'one'; }
    return one();
    function one() { return 'two'; }
  }

  foo();

  function foo() {
    var one = function one() { return 'one'; }
    return one();
    var one = function one() { return 'two'; }
  }

  foo();

Some people think its better to ditch named functions completely rather than learn exactly when its problematic and when it's not... which I'm not sure I completely agree with, but its probably a good advice to give to a new JavaScript programmer, as it basically behaves the same minus those issues.

CoffeeScript ended up removing named functions [2] [3] (with the exception of being used for "class" declarations, where its known they're safe) for that reason.

[1] http://kangax.github.com/nfe/#jscript-memory-management

[2] https://github.com/jashkenas/coffee-script/issues/366#issuec...

[3] https://github.com/jashkenas/coffee-script/wiki/FAQ - "Q: Is there any way to name functions, for reflection and recursion?"

edit: formatting

If you discovered that the answer was one or the other, would it make you a better developer in any way? Would it help solve any problems the world has?

Perhaps you should look more into why the "Gresham's Law of Programming Languages" exists. Maybe the have better documentation, a more friendly user community. Maybe they fix more real-world problems and spend less time mentally masturbating over programmer porn.

Someone bringing up PHP when it's fairly unrelated? Check

Maybe focusing on the issue at hand would be something to keep in mind?

http://bonsaiden.github.com/JavaScript-Garden/

It's long but not THAT long. There is a strict set of JS with some of the gunk removed. I don't think they went far enough but such is life. I'm not expecting a replacement for JS in the browser. AFAICT the browser vendors aren't interested in getting a replacement language standardized. I do expect compile-to-js options becoming more popular.

There are a couple other problems that make building web applications hard but are not the fault of the language:

What I generally find is that people who think JS sucks don't actually know JS. They know Java or C# or something and can, without learning anything, put together something that runs and generally does what they want. Their success (no obvious failures) and comfort with the syntax (except for those damn unexplainable JS bugs) causes an overestimation of their capability.

Overestimation is a problem because their experience in programing allows them to write a complex chunk of code that has the wrong abstractions/organization. It's absolutely awful. The worst 20-150k sloc codebases I've run across were ALL written by Java programmers who tell me JS sucks. The problem was that they're doing it wrong. Applying the right patterns has led to a 50%+ line count reduction in all cases. JS is its own language. The architectural patterns that work come from functional languages and not classy languages. Classy patterns can work but you need to go all-in and add type checking a la Google Closure oriented code and that's rare in the wild. Finally, small modules as in the node.js community generally seem to be working.

On the other end, JS suffers (along with PHP) the part timers. This would be fine except that easy but wrong patterns become standard practice. I fought against the jQuery spaghetti pattern for years only to find people migrating to Backbone, which is better but also flawed–events don't provide state isolation and the simple idempotent view.render() falls apart in larger apps and the workarounds are nuanced or complex. Use Ember or Angular. They are NOT more complex than you'll need unless you're only making brochureware sites.

The third problem is that the DOM sucks. The API is bad and has cross browser issues but jQuery basically won that battle. The remaining and more subtle problem is that it's a mutable global variable that you must interact with. There are a variety of mitigation strategies with the most accessible being two way bindings.

> (I don't consider hoisting a benefit - I prefer to have my functions declared before they're used)

> As for call stacks and debug messages - that was true some time ago, but modern debugging tools can figure out the function name pretty good even if it isn't a named function.

All of these ignore the fact that functions are not simply declared once in Javascript and then used later, like in C. It's a dynamic language with first-class functions and function literals. You could assign to a variable in this case, but that's needlessly restricting:

  asyncFunc(function cb(result) { print(result); });