Javascript, JS, ECMAScript. Many love it, some hate it but we're all stuck with it.
Its dynamic nature and familiar syntax makes it fast, expressive and flexible to develop with but anything written in 10 days will certainly have issues. The fact that there's an excellent book titled "JavaScript: The Good Parts" highlights that there are many bad parts to be avoided.
With great power comes the responsibility to not shoot yourself (or your team) in the foot. Here are a few of the tricky things to be aware of or avoid.
Accidental Global variables
Any variable defined without var
is automatically a global variable. Often
the result of variables used in loops.
for (i; i < 100; i++) { ... } // `i` is a global!
for (prop in obj) { ... } // `p` is global!
These should pe properly prefixed with var
to keep the variables in the local
scope.
for (var i; i < 100; i++) {}
for (var prop in obj) {}
An easy way to catch errors like this is to use "strict mode". Strict mode enables a more strict javascript environment where errors are thrown when mistakes would've otherwise failed silently. It also slightly restricts syntax and names to prevent acciental errors.
Use strict mode by putting "use strict"
on the first line of the file or the
first line of the function. Placing it as the first line in a file can cause
problems with concatenation. A good pattern to prevent this is to wrap your
code in an IIFE.
(function() {
"use strict"
...
})();
parseInt, String to integer conversion.
Always use the second argument (radix) or weird things can happen since javascript implementations have different default values for the radix.
parseInt('018px', 10);
Responsible use of this
Understanding the this
context keyword can be really tricky considering it
can be used in places you wouldn't expect. Depending on the context the code
was called in, this
could be the window
object, an object "instance", a DOM
element, and many other things.
I advocate only using this
when dealing with objects that are instiantated,
such as classes or in prototype methods of a constructor function.
function DestinysChild(name) {
this.name = name;
}
DestinysChild.prototype.sayMyName = function() {
console.log(this.name);
}
var beyonce = new DestinysChild('beyonce');
beyonce.sayMyName();
// => logs 'beyonce';
Used in this way, this
works similarly to self
in many object-oriented
languages -- referencing the object instance that the method is being called
in.
In DOM event handler callbacks this
is assigned to the DOM element that
triggered the event. In that context, this
is ambiguous and poorly named.
It's more clear what you're referencing if you pull the DOM node from the event
object passed to the event handler.
var linkElement = event.currentTarget;
DOM Element IDs are part of the window
context
I've only bumped into this last one once but I was thoroughly confused until I realized what was happening. And it's actually a DOM quirk rather than an issue with Javascript.
Browsers automatically create variable references to DOM elements that have
id
attributes. If we have the following markup in the page:
<div id="header"></div>
The header
(or window.header
) variable will automatically be created and it
will reference the <div id="header"></div>
DOM element.
This can be really confusing if you forget to assign a variable correctly or are checking if a variable has been initialized and there's an element with the same ID on the page.