PHP was my first programming language, and my initial exposure to JavaScript was through libraries like jQuery. There were things about JavaScript that always seemed to trip me up in the beginning due to how they worked differently than PHP. Heck there are still some things today that are confusing. I want to share some of the things that I struggled when I started working with JavaScript. I am going to cover the global namespace, this, knowing the difference between ECMAScript 3 and ECMAScript 5, asynchronous operations, prototypes, and simple JavaScript inheritance.
The most common gotcha I encounter in Javascript has to do with callbacks. I see this problem all the time in my own code and that of my colleagues: callbacks that have been registered either more or less times than the author of the code expected. Usually more times.<p>This can manifest itself in many ways. Usually in the form of a UI element being displayed more than once, but often more subtly such as a HTTP request being sent more than once. Often the bugs only manifest themselves after a certain sequence of actions, for example: click this UI element, check this radio box, then hit submit and watch the net tab.<p>It's so often the root cause of Javascript bugs that if I or somebody else on my team has a Javascript problem, I often start by asking myself if it looks like it could be this. Lately I have begun to wonder if there isn't some slight truth to that inflammatory "Callbacks are the new goto" story that was on here a couple of months ago [1].<p>[1] <a href="http://elm-lang.org/learn/Escape-from-Callback-Hell.elm" rel="nofollow">http://elm-lang.org/learn/Escape-from-Callback-Hell.elm</a>
I would also add that variables can be re-declared. Many beginners probably think that writing this code would produce an error:<p><pre><code> var i = 0;
var i = [];
</code></pre>
No runtime error will be produced, and the script will continue normal execution.
<i>a basic explanation is that by preceding a variable declaration with var creates a property on the nearest containing function</i><p>This is not true, the var hoist the variable and scopes it to the function, but does not create it as a property of the function. A function is defined in its outer function scope, an it's properties will persist across calls.<p><pre><code> function foo() {
var bar = 1;
foo.baz = 2;
}
foo();
foo.bar; // is undefined
foo.baz; // is 2
</code></pre>
Adding properties to functions is useful for memoization, but is different than what the var statement does.<p>Your summary of that section is a better explanation:<p><i>all variables are scoped to a function (which is itself an object), and where you declare those variables with var determines the function they are scoped to.</i><p>You might add, if you never declare the variable with var it is implicitly declared global.
Using closures to encapsulate private variables is a good idea, but the way this article recommends doing it doesn't demonstrate any of the benefit as it doesn't really close over anything. I don't know if it's an example of good JS code, but something like the basic closure definition of a counter might have better demonstrated the ability to hide state:<p><pre><code> var counter = (function () {
var i = 0;
return function () {
i += 1;
return i;
}
}());
</code></pre>
Where the internal variable, i, is inaccessible to anything but the counter function itself.