In JavaScript, there’s many different ways of doing something. This is both a good thing and a bad thing. To the newcomer this is definitely a bad thing, as it means not only more things to learn, but more little caveats and more places to go wrong. And so it is with declaring functions!

The aim of this is just an accessible tour of the landscape, just so you know what’s out there and what the basic differences are. Do be sure to check out the “further reading” section as well! Much of this is based on Juriy “kangax” Zaytsev’s article, which goes into more depth. But I found that there wasn’t just one reference to show all the different variable declarations.

How about ways to execute functions? That opens up another can of worms, and incidentally opens up the possibility for a future post on that topic.

Overview: different ways of declaring functions

function A(){};             // function declaration
var B = function(){};       // function expression
var C = (function(){});     // function expression with grouping operators
var D = function foo(){};   // named function expression
var E = (function(){        // immediately-invoked function expression (IIFE) that returns a function
  return function(){}
})();
var F = new Function();     // Function constructor
var G = new function(){};   // special case: object constructor

Function declarations: function A(){};

Function declarations are probably the most familiar and oldest way of doing things in JavaScript land. This creates a variable A which is accessible in the current scope. Scope is a separate topic, so we’ll do everything in the global scope for all these examples (something you want to avoid usually).

1. Hoisting

The interesting thing about these is that they are “hoisted” to the top of their scope, which means this code:

A();
function A(){
  console.log('foo');
};

Gets executed as this code:

function A(){
  console.log('foo');
};
A();

Which practically means that, yes, you can call the functions before they’re written in your code. It won’t matter, because the entire function gets hoisted to the top of its containing scope. (This is contrasted with variables, which only have their declaration hoisted, not their contents, as we’ll see in the next section).

2. No function declarations in If statements (or loops, etc)

You can’t define functions this way in expressions, for example if statements, which is common if we want to define different versions of a function for different circumstances, usually to address browser inconsistencies. Well, you can in some implementations, but the way the code is processed is inconsistent (kangax has documented the inconsistencies here). If you want to use this pattern, use function expressions instead.

3. Functions declarations must have names

This method doesn’t allow you to create anonymous functions, meaning that you always have to give it an identifier (in this case we’ve used “A”).

Function expressions: var B = function(){};

A function expression looks similar to function declarations, except that the function is assigned to a variable name. Though functions are not primitive values in JavaScript, this is the way they can be utilized to their full effect in this functional language. Functions are “first class“:

“[JavaScript] supports passing functions as arguments to other functions, returning them as the values from other functions, and assigning them to variables or storing them in data structures”

1. Anonymous functions (they don’t need names)

The function name is optional in function expressions, and we call these anonymous. Here we’re setting the variable B equal to an anonymous function:

var B = function(){};

2. Variable declaration hoisting

Variable declarations are hoisted to the top of their scope, somewhat similarly to function hoisting except the contents of the variable are not hoisted as well. This happens with all variables, and it means it’s now happening with our functions, now that we’re assigning them to variables.

This code:

var A = function(){};
var B = function(){};
var C = function(){};

Will be executed as this:

var A, B, C;  // variable declarations are hoisted
A = function(){};
B = function(){};
C = function(){};

Therefore the order of setting and calling this type of function is important:

// this works
var B = function(){};
B();

// this doesn't work
B2();  // TypeError (B2 is undefined)
var B2 = function(){};

The second example gives us an error because only the variable B2′s declaration is hoisted, but not its definition, thus the “undefined” error.

Function expressions with grouping operators: var C = (function(){});

These really aren’t different from plain old function expressions and aren’t really seen in the wild (so maybe they’re just good for JavaScript quizzes?). Recently this way of declaring functions was brought up in this article and confused some folks including myself.

Here’s a good way to see what’s happening:

function(){};  // SyntaxError
(function(){});

Why does one work and the other doesn’t? The first example is a function declaration, and we learned above that we can’t declare them anonymously – that is, they must have a name. That’s why we’re getting the syntax error.

The second example is using parenthesis – grouping operators – and is therefore evaluated differently, as a function expression. The grouping operators are the things we use to help show what should be evaluated first, as in mathematical problems. We’re saying “evaluate this first, then take the result and do something with it”:

(1 + 2) * 3;  // 9
1 + (2 * 3);  // 7

In the first example we’re saying “first add 1 and 2, then take the result and multiply by 3″, whereas in the second example we’re saying “first multiply 2 and 3, then take the result and add 1″.

Because functions are first class, we can use similar grouping operators. Here’s a facetious example, but it shows how we can essentially drop in a function in the same way:

(function(){} + 1);  // function(){}1

The result is a string (because toString is being called on the function, then added/appended with 1), but you get the idea I hope.

When the JavaScript engine encounters the opening parenthesis here, we’re essentially saying “ok, start grouping this together with something else”. Using our technical terms, we’re telling the engine that we’re not making a function declaration, but instead a function expression. And then we can assign the result to a variable:

(function(){});           // resulting function not assigned
var foo = (function(){}); // resulting function assigned to foo
var bar = function(){};   // resulting function assigned to bar

Here we can see that foo and bar are really just the same, because in foo we’re not grouping the function together with anything but itself.

Named function expression: var D = function foo(){};

Here we have our same old friend, the function expression. But instead of assigning the variable to an anonymous function, we’re assigning it to a named function (with the name foo).

1. The function name is only accessible within the function

We haven’t exposed the function name (foo) to the enclosing scope (in this case the global scope):

var D = function foo(){
  console.log(typeof foo);
};
D();                       // function
console.log(typeof foo);   // undefined

2. Useful for recursion

Because the function’s name is accessible in the function itself, this turns out to be useful for recursive functions, much more useful than the plain old anonymous function.

Here’s a trivial recursive function to illustrate calling itself from within the named function expression:

var countdown = function a(count){
  if(count > 0) {
    count--;
    return a(count);  // we can also do this: a(--count), which is less clear
  }
  console.log('end of recursive function');
}
countdown(5);

3. Useful for debugging

As a few have pointed out, giving previously anonymous functions names helps in debugging, since the function name shows up on the call stack.

4. Quirks: JScript’s bad implementation

kangax points out that named function expressions are basically poison to JScript, Internet Explorer’s implementation of JavaScript.

The named function becomes a global variable, is hoisted like a function declaration, and actually ends up creating multiple instances of the same function.

Immediately-invoked function expressions (IIFE): var E = (function(){return function(){}})();

“Execute this function, whose return value is another function, and assign that to the variable E”. This may seem like magic, but it’s actually quite simple, and the pattern is powerful and has useful applications, the most famous of which is the module pattern.

First we’ll use an example that doesn’t look like magic:

var foo = function(){
  return 'bar';
};
var output = foo();
console.log(output);  // 'bar'

We already learned about grouping operators above, so you should feel comfortable with saying this is equivalent:

var foo = function(){
  return 'bar';
};
var output = (foo)(); // note the extra grouping operators
console.log(output);  // 'bar'

Since foo is pointing to our function expression, we know that we can simply refrain from using the variable “foo” and drop in the entire function as an anonymous function (since functions are first class, after all!):

var output = (function(){
  return 'bar';
})();
console.log(output);  // 'bar'

Hey wait, we just arrived at the magical resulting function! It turns out to be not so magical after all, once we break it down and see it for what it is. It’s simply shorthand for the code we wrote originally, where we defined a function, executed it, and defined output to be its return value.

I’ve included this method on the list of declaring functions because we can assign the return value to itself be a function:

var E = (function(){
  return function(){}
})();

Applications

There are good applications for this, including information hiding using in the module pattern, (partial application, for example), and other clever uses of it. It’s definitely not a trivial pattern.

Function constructor: var F = new Function();

This method is extremely old and it’s not recommended to be used. You pass in an unlimited number of arguments in the front, then the actual function body appears as a string in the last argument (because it’s a string, it’s effectively the equivalent of eval(), and isn’t recommended).

1. Defining the function

You can create a function like this:

var F = new Function('arg1', 'arg2', 'console.log(arg1 + ", " + arg2)');
F('foo', 'bar');  // 'foo, bar'

2. You don’t need the new operator

You can simply write var F = Function(); to get the same result.

3. Quirks

The MDN docs have some good examples of the quirks, including the fact that functions declared with the Function constructor don’t inherit their current scope properly (i.e. a closure isn’t formed).

What this means is that they don’t have access to variables in their enclosing scope, which isn’t particularly useful:

function foo(){
  var bar = 'blah';

  var first = new Function('console.log(typeof bar)');
  first();   // undefined

  var second = function(){
    console.log(typeof bar);
  }
  second();  // string
}
foo();

In the function “first”, we’re using the Function constructor, so it doesn’t have access to the variable bar. However, if we use the function “second”, which is a function expression, it does in fact have access to variables defined in its enclosing scope (via closure).

In other words, don’t use the Function constructor.

Special case – object constructor: var G = new function foo(){};

I saved this for last because we’re not really defining a function, though we are using the function keyword, so it’s worth noting at least.

new function(){}; creates a new object and invokes the anonymous function as its constructor. If an object is returned from the function, that becomes the resulting object, otherwise a new object is created from scratch and function is executed in the context of that new function (let’s save the details for another post!).

It’s a bit unusual to see it in this form. Let’s do it the proper way:

var Person = function(){
  console.log(this);  // Person
}
var joe = new Person();

So really with the new operator, we are giving it a new ‘this’ context and then executing the given function with that new context. Much different than the function definitions we’ve been dealing with above! This does into a whole new topic, and we’ll save that for later!

Further reading

Named function expressions demystified (kangax)

Immediately-Invoked Function Expression (IIFE) (Ben Alman)

Functions and function scope (Mozilla Developer Network – MDN)

How does an anonymous function in JavaScript work? (StackOverflow)

Function Declarations vs. Function Expressions (JavaScript, JavaScript by Angus Croll)

JavaScript: The Definitive Guide (classic book by David Flanagan)

foo0;             // existence level 0 (creates the error "not defined")
var foo1;         // existence level 1 ("undefined" - variable declared but not defined/initialized)
var foo2 = null;  // existence level 2 (variable initialized, but isn't an Object, Number, String, etc)
var foo3 = "";    // existence level 3 (variable initialized to an empty String)
var foo4 = "bar"; // existence level 4 (variable initialized to String "foo")

Generally it would be handy if we had some way to filter out everything but the very last line. We simply want to check for these cases without the script entirely blowing up, as it does with the first line:

foo;  // ReferenceError: foo is not defined

We’re not particularly doing anything useful with foo here, but notice that the script fails out anyway. At this point any code that follows will not be executed. Your first instinct might be “Oh! I know how to contain these errors! We’ll use a try-catch!”:

try {
  foo;
} catch(e) {
  e.message;  // "foo is not defined"
}

The script still fails, but not critically, so your script continues to execute. But this turns out to aversely affect performance. The basic lesson here is that try-catch can be useful in some situations, but shouldn’t be used where alternatives are available.

typeof foo

JavaScript has quite a useful remedy for this:

typeof foo; // "undefined"

Unlike everything else in JavaScript, typeof will deal with whatever you throw at it, including undefined variables. So you can use it as a simple check before using a variable that might not exist:

if(typeof foo !== "undefined") {
  // do something with foo
}

Note that this is easy to confuse with the undefined keyword, which in this case doesn’t help us one bit, as it gives us a fatal error:

if(foo !== undefined) {  // ReferenceError: foo is not defined

}

This filters out our first two cases, since they both evaluate to “undefined”:

typeof foo; // "undefined"

var bar;
typeof bar; // "undefined"

But this turns out not to work well for our other conditions, which evaluate differently:

typeof null;  // "object" (what?!)
typeof "";    // "string"

So we need to add other “if” conditions to check.. but there turns out to be a better way!

Exploiting loose typing

JavaScript is a loosely typed language, which means that it will “automagically” cast variables into other types when necessary (i.e. when adding a Number to a String), sometimes resulting in the unexpected. For instance, whenever we use the “if” statement, the expected input is a Boolean true/false value. If JavaScript gets anything other than a Boolean, such as a String or a Number, instead of blowing up completely (as in strictly typed languages such as C), it’ll cast the variable into a Boolean for you.

“How handy!” you might think. Except in the following unexpected cases:

if("0") {
  // this will run because "0" is true
}

if("false") {
  // this will run because "false" is true
}

To see what JavaScript will cast a value to without having to use an if statement, we could create a new Boolean value with the following:

Boolean(0);    // false
Boolean("0");  // true

Or we can use the less intuitive but quick way of using double exclamation marks (this will probably award you cleverness points in someone’s book.. hopefully those points actually matter):

!!0;    // false
!!"0";  // true

This works because !foo converts foo to a Boolean but negates its original value, turning it on its head. !!foo converts foo to a Boolean and flips it back to its expected value, which is the same value that’s evaluated by our if statement.

Using this ALMOST gives us the answer we’re looking for:

!!foo0; // ReferenceError: foo0 is not defined

var foo1;
!!foo1; // false

var foo2 = null;
!!foo2; // false (same as !!null)

var foo3 = "";
!!foo3; // false (same as !!"")

var foo4 = "bar";
!!foot4; // true (same as !!"bar")

Excluding the first example, now we can test for uninitialized variables (foo1), null variables (foo2), and empty strings (foo3) all with just an if statement:

if(foo1) {
  // do something with foo1
}

if(foo2) {
  // do something with foo2
}

if(foo3) {
  // do something with foo3
}

Dang… so close! But we can’t yet test the first case without an error:

if(foo0) {  // ReferenceError: foo0 is not defined

}

foo versus window.foo and this.foo

The secret to our solution lies in how JavaScript handles undefined variables versus undefined properties. Here’s a quick reminder on the difference between the two:

// variable foo
var foo;

// property bar (and object variable foo)
var foo = {};  // create an empty object to add bar too
foo.bar = "";

The difference between these makes all the difference whether a fatal error occurs:

foo;  // ReferenceError: foo is not defined

var foo = {};
foo.bar;  // undefined
foo.blah; // undefined

We can randomly invent and check any property of foo we want, and the code will keep chugging along:

var foo = {};
foo.something = "hello";

if(foo.bar) { // undefined, interpreted as false (same as !!foo.bar)
  // never runs
}

if(foo.something) {
  foo.something;  // "hello"
}

Now comes the magic. If you know anything about JavaScript running in the browser, you know that all global variables are part of the window object. This means foo and window.foo are equivalent:

var foo;

foo === window.foo;  // true

// "this" is another bag of worms, but note this anyway
this.foo === window.foo;

So technically our variable foo is a property of the window object. So we should be able to check for any arbitrary variable in the window scope now!

window.foo;  // undefined (not a fatal error!)

// even though we're checking for the same thing, we get a fatal error…
foo;  // ReferenceError: foo is not defined

Practical uses

Now as long as we have a global entry point for our code, we can write our code in such a way that it won’t ever give us a fatal error if our variables aren’t yet defined:

if(window.foo && foo.bar) {
  foo.bar();
}

Of course nothing happens, because we haven’t defined foo. But why doesn’t foo.bar give us a fatal error? Because the first test, window.foo failed out. It would be useless processing for the JavaScript engine to also evaluate the second statement, because the end result will still be the same (false && true results in false, false && false results in false). So it doesn’t get so far as foo.bar.

And now the code will work properly when we hook up our code to our foo global namespace:

var foo = {
  bar: function() {
    alert("hello world");
  }
}

if(window.foo && foo.bar) {
  foo.bar();  // "hello world"
}

Shorthand

It’s becoming common to see an abbreviation for the above code. Check out the following two methods, which accomplish the same thing:

// Method 1
if(window.foo && foo.bar) {
  foo.bar();  // "hello world"
}

// Method 2
window.foo && foo.bar && (foo.bar());

Don’t get too scared.. these blocks of code are equivalent. Method 2 is shorter, but it simply goes something like this: if window.foo isn’t set, stop evaluating this line (just as above in the if statement). Otherwise, if foo.bar exists then execute the code in parentheses, which gives us an alert (“hello world”);

Just a word of caution about using Method 2: it’s obviously less clear what’s going on here. Your own cleverness might actually result in unnecessary confusion, especially of other people work in the same code base and they’re at different levels of understanding. In these cases we should first strive to be clear, and then only clever if it’s not at the expense of being clear.

It’s also likely that a code minifier would take care of this cleverness for us at build time, giving us the best of both worlds.

Twitter

This merits a category of its own. This has replaced the RSS reader for a lot of folks, or at the very least supplemented it.

I’ve consistently recommended Nathan Smith’s list of JavaScript folks. When I’m diligent, I keep up with this several times a week and favorite items from the feed to be considered for inclusion in that week’s JSMag Blog update.

Aggregators and communities

Delicious
Github
Reddit: web_design and javascript
JSMentors

Blogs

JavaScript Google Reader bundle
JavaScript People Blogs – Google Reader bundle

Mozilla articles on hacks.mozilla.org
Script Junkie
DailyJS – very frequently updated news by Alex Young
QuirksBlog (ppk) – focus on mobile
JavaScript, JavaScript (Angus Croll)
John Resig’s blog – unfortunately not too active lately (check out his Twitter for more updated info)
Ajaxian – used to be THE source for news, but it isn’t updated too much anymore

…and many more. Check out Rey Bango’s “What to Read to Get Up to Speed in JavaScript” for more.

Browser blogs

It’s important to know what’s going down in the browser world. These have mixed content, so it’s not just JavaScript.

Surfin’ Safari
The Chromium Blog
The Mozilla Blog

Weekly news

These sources attempt to do the legwork for you and round up the most important articles each week. (Disclaimer: I currently write for JSMag!)

JavaScript Weekly: a weekly email newsletter
Badass JS
JSMag blog

Podcasts and Videos

A Minute With Brendan
node.minutewith
YUI Theatre
Node Up

Am I missing anything (I’m very sure)? Post a link below in the comments. Thanks!

Here’s an example of what happens when your interface completely relies on JavaScript. There’s code with translated mojibake of some sort which caused the JavaScript to break. The code wasn’t in a try-catch block, so it caused all of the code on the page to fail, thus presenting me with the only part of the screen that wasn’t generated by JavaScript: the completely useless header.

Where’s the tweets!?

Those that are just setting out to learn JavaScript are typically overwhelmed by the amount of online resources to be found about learning JavaScript. Not only this, but every webpage visited presents a potential learning opportunity just by inspecting the source.

However, not all resources are guaranteed to be up-to-date. JavaScript has been around for over a decade, and coding standards have changed drastically over time. While a code snippet may still work in today’s browsers, you may unknowingly be using an outdated practice that might eventually lead to a bit of embarrassment.

You may sometimes find these old practices mixed in with good and modern code. It seems that folks might learn new code styles without necessarily casting away all their old habits. So keep in mind not to throw out the baby with the bathwater!

Here’s some old practices that should help you spot old outdated code.

Global variables

function foo() {  // global function
  greeting = 'Hello' + name;  // global function
};
name = 'James';  // global variable
foo();

Tons of global variables is a sure sign of outdated code. Ideally you want to aim to have at most one global variable, which is a namespace for all your code to be written under. All variables in your functions should be defined with the ‘var’ keyword to ensure they don’t break out of their scope.

Here’s an example where we defined one global variable entry point (myNamespace) for our code:

var myNamespace = (function() {
  // declare all variables with var
  var greeting, name;

  name = 'James';

  greeting = function() {
    return 'Hello ' + name;
  };

  return {
    greeting: greeting
  }
})();

greeting();              // ERROR: not defined
myNameSpace.greeting();  // 'Hello James'

Commented CDATA blocks

/* <![CDATA[ */
// code here
/* ]]> */

This appears in old scripts that are presented inline (instead of externally in a separate file). The original purpose of those was to get around HTML validator errors (and to conform to XHTML), but that appears to no longer be an issue with validators today. Also, the usage of HTML validators itself seems to be waning, although they may sometimes be helpful in the development of websites.

document.write()

document.write('foo');

The W3C, along with most everyone else, warns against using this, as it may result in overwriting (blanking) the entire page and other unwanted behavior.

It’s now used mostly by ads, and developers have for years been trying to control them. So don’t use it, unless you’re trying to prevent ads from using them. In other words, don’t use it unless you know what you’re doing.

Inlined event handlers

<a onclick="myClickFunction()" href="http://foo.com"></a>
<a onmouseover="myMouseoverFunction()" href="http://foo.com"></a>
<form onsubmit="mySubmitFunction()" href="http://foo.com"></form>

This mixes behavior with the actual content, which means when it’s time to make changes to the code, you likely have to change both the HTML and the JavaScript, instead of simply just the JavaScript. It also means that you may be serving useless content to users with JavaScript disabled (they’re still out there, believe it or not). This also might have an affect on search engines, that might not be able to access this JavaScript-only content (although crawlers are getting more sophisticated and this may be less of an issue as time progresses).

Instead, the very least you can do is add IDs to each element (or better, use a JavaScript selector engine) and hook into them in your JavaScript, which makes the code much easier to maintain:

<a id="link1" href="http://foo.com"></a>
<a id="link2" href="http://foo.com"></a>
<form id="myForm" href="http://foo.com"></form>

(function() {  // sandbox everything
  // variable declarations
  var link1, link2, myForm;

  window.onload = function() {  // or onDOMContentLoaded (wait for DOM to be ready)
    // simple DOM selectors
    link1 = document.getElementById('link1');
    link2 = document.getElementById('link2');
    myForm = document.getElementById('myForm');

    // well-supported older event handler
    link1.onclick = function(){
      // code
    };

    // better (DOM2)
    link1.addEventListener('click', function(){ // or attachEvent for IE
      // code
    },false);

    // etc...
  }

})();

link1.onclick is widely supported, but there’s a few downsides, including the fact you can only add ONE event listener on the element (it will be overwritten if you try to add another). Use addEventListener (attachEvent in IE) instead, or the method of your favorite JavaScript engine.

In any case, the point here is to get the JavaScript out of the HTML and into the rest of your JavaScript.

Inline JavaScript in link hrefs

<a href="javascript:doSomething()"></a>
<a href="javascript:void(0)"></a>

Both of these examples commit the same error as above – mixing JavaScript behavior with the HTML content. And the solution is similar: find these links with JavaScript (most simply by adding an id on them) and hook into them there.

The second example brings up a good issue, and a point of contention. Ideally this would be a link to fallback content for users that have JavaScript disabled (and for search engines!), which would be a link to a new page (Flickr is an example of a modern site that uses this approach). For better or worse, however, you might be building a web app that only works with JavaScript, and you might want a link that only exists to kick off a JavaScript event.

You’ll find that removing the href value or making it blank (href=”") might remove the styling from the link and no longer makes it clickable. An easy fix is to set the href equal to a hash tag (href=”#”). A side effect might be a “jump” to the top of the page after clicking the link, which requires and requires e.preventDefault() within the attached event. Href=”#” may soon become an antipattern (or maybe it is already), since you can also fix this with CSS styling:

a { cursor: pointer; }

This gives the cursor a pointer when the user hovers over the link, even if it’s missing the href value.

But again, this isn’t generally recommended. It’s better to make a non-JavaScript fallback by linking to an actual page, then overriding it with e.preventDefault() for JavaScript-enabled users!

Slow arrays

var arr = [1, 2, 3, 4, 5];

for(var x in arr) {
  /* code */
}

for(var i=0; i < arr.length; i++) {
  /* code */
}

For-in loops turn out to be quite slow while going through arrays, so only use them when iterating through properties of an object. The second for loop is much faster, but can be made faster still when we realize what's being evaluated on each iteration:

for(1; n; n) {}

The first statement is evaluated once (1 time) as the loop is initialized, and the second and third parts are evaluated on each run through the loop (n times). Because of this, just as removing fluff from the main body of the loop itself, we would also do well to remove fluff from these statements themselves. As it turns out, it's quite slow finding the length of the array (arr.length) on each pass, and it's not necessary to do it more than once since it's not changing. So we can "cache" the length in a variable in the initializer:

for(var i=0, len=arr.length; i < len; i++) {
  // code
}

And faster yet is a while loop (keep in mind that it will run backwards), which stops when the counter hits 0, which is falsy, causing the loop to stop:

var i = arr.length;
while(i--) {
  // code
}

new Object(), new Array(), new Function(), etc

var obj  = new Object();
var arr  = new Array();
var func = new Function("param1", "param2", "return true;");

While these work, no one really uses them, as there exist less verbose and more common alternatives. Use these instead, which are exactly equal to the above code:

var obj  = {};
var arr  = [];
var func = function(param1, param1) {return true;}

alert()

Ok, alert can sometimes still be useful for debugging, but generally you want to use console.log for that anyway. Generally you don't want to ever prompt the user with alert() however. Its use on the desktop for mainstream use has long been discouraged.

I'm still on the fence about using alert() however, as I think it's pretty useful and not necessarily ugly in mobile browsers. I'll spare you and save that for another post.

Missing semicolons

var name='Bill'
alert('Hi ' + name)

The above code works fine because of a controversial feature of JavaScript called semicolon insertion. But doesn't it make you feel dirty? It should, especially if you've read JavaScript: The Good Parts. Use semicolons for your own good and to prevent major headaches. Leave it to your JavaScript minifier to be clever in deciding when to remove them:

var name='Bill';
alert('Hi ' + name);

Code for particular user agents

This is also a bit controversial, since unfortunately user agent sniffing is still sometimes necessary. However, in the past it was really abused with code such as this:

isIE  = document.all;
isNS4 = document.layers;
isNS6 = document.getElementById;
if(isIE) {
  // code for IE
} else if(isNS4) {
  // code for Netscape 4
} else if(isNS6) {
  // code for Netscape 6
}

(did I mention that any references to ancient browsers like Netscape is also a surefire sign of old code? But that's probably too obvious...)

This example detects browsers by features that only exist in each of these old browsers, but the same sin is committed by "sniffing" for words in the user agent string. The unfortunate result is fragmented code targeting each predetermined browser. Not to mention that it's not future-proof, as it can't properly anticipate newer browsers.

The better method? If there's a question about the availability of a method, simply check for it first before using it:

if(document.addEventListener) {  // detect addEventListener
  // Try the standard first
  document.addEventListener('click', function(){}, false);
} else if(document.attachEvent) {  // detect attachEvent
  // Typically IE
  document.attachEvent('onclick', function(){});
}

This code is considered feature detection, which is much more acceptable. It also anticipates newer browsers such as IE9, which support addEventListener. This makes sure the code you write doesn't condemn Internet Explorer to forever use attachEvent.

Related links

Christian Heilmann and PPK's old posts inspired me to write this brief post. You can read much better rationale against using some of the things above at these links:

Six JavaScript features we do not need any longer (Christian Heilmann, 2005)

From DHTML to DOM scripting (Christian Heilmann, 2006)

Three JavaScript articles and one best practice (PPK 2005)

There have been many attempts to answer this question in a succinct way, but I haven’t really been satisfied by them. Here’s my attempt at a (relatively) concise explanation.

This is adapted from a reply I posted on reddit which people seemed to have found useful.

Broad definition

Normally when people talk about closures in JavaScript, they’re talking about methods and properties that outlive the scope of their original function (more on that in a second), but actually the definition is a bit broader. A closure is how a function “closes over” (Crockford) its variables and creates a different scope for them out of the way of the global [window] scope. So an understanding of closures will require some understanding of scope, which is definitely a common stumbling block in first learning JavaScript.

Essentially, closures make this possible:

var a = 1;
function(){
  var a = 2;
  a; // 2 (functional scope)
};
a;  // 1 (global scope)

Variables that survive after function execution

But when people get excited about closures, they’re not really talking about the example above, but about the ability for functional variables to outlive their original functional scope:

var b = function() {
  var myPrivateVar = 'Foo';
  var myPublicVar = 'Bar';

  return myPublicVar;
};

b();  // 'Bar'
myPrivateVar;  // ERROR (not defined, because it was only defined in functional scope and is trying to be accessed from the global [window] scope)
myPublicVar;   // ERROR (not defined)

But note that the original method name (myPublicVar) isn’t available – but the value IS available from what we exposed to the global scope through the variable ‘b’.

Closures and the Module Pattern

How is this useful? This turns out to be the foundation for the Module Pattern in JavaScript – the building block of modern JavaScript applications. They’re in essence a glorified version of the block of code above, with the purpose of hiding the function’s private variables (this comes by default when declaring variables with the ‘var’ keyword in functions), and exposing public variables. And note that because functions are first class in JavaScript, those variables can even be references to functions themselves!

So in essence this is the module pattern, with both private and public properties and methods:

var myAPI = (function() {
  var privateProperty = 'Foo';
  var publicProperty = 'Bar';

  var privateMethod = function() {
    alert('I can only be executed from the scope of myAPI');
  };

  var publicMethod = function() {
    alert('I am publicly accessible (through the global scope) because a reference to publicMethod is returned by myAPI');
  };

  // set up an object whose own property names (on the left) match the references to the internal, functionally-scoped methods (on the right)
  var publicStuff = {
    publicProperty: publicProperty,
    publicMethod: publicMethod
  };

  // return our public object (myAPI is now equal to this object)
  return publicStuff;
})();   // immediately execute myAPI as a function, which returns an object that contains pointers to stuff in myAPI, which is exposed through myAPI.x, myAPI.y, etc

By the time we reach the last line of the above script, the function has stopped executing, but some original pieces of the function still live on! Because some references to functional variables were returned by the function, we can now access these through the “namespace” myAPI:

myAPI.publicProperty;  // 'Bar'
myAPI.publicMethod(); // (alert: 'I am publicly accessible'...)

But those variables that were not exposed are of course not accessible:

myAPI.privateProperty;  // error (not defined)
myAPI.privateMethod(); // error (not defined)

Access to unexposed variables

Exposed public methods still have the context of the original function, meaning that they have access to all the function’s variables, public and private:

var myAPI = (function(){
  var privateProperty = 'Foo';

  var publicFunction = function() {
    // this function has access to privateProperty because it's in the same scope, even after the main function stops executing!
    return privateProperty;
  };

  // create a new object and return it
  return {
    publicFunction: publicFunction
  };
})();

privateProperty;         // ERROR (not defined)
myAPI.publicFunction();  // 'Foo'

There’s definitely more to be said here, but hopefully this helps!

When people started to learn about the HTML5 doctype, they kind of freaked out a little, not knowing how older browsers would handle it. A post by Dustin Diaz prompted me to test out how pages rendered (in QuirksMode or Standards Mode) with a little help from document.compatMode, and I found that surprisingly every browser rendered in Standards Mode with the new doctype. In other words, no need to worry!

There’s another welcome simplification (along with others): the “type” attribute is no longer necessary on script tags:

The type attribute gives the language of the script or format of the data. If the attribute is present, its value must be a valid MIME type. The charset parameter must not be specified. The default, which is used if the attribute is absent, is “text/javascript”. -W3C HTML5 spec

Which means that this is all that’s required now:

<script src="script.js"></script>

But how do older browsers handle this? Also, what if we send some crazy Content-Type back in the response header? To make matters more confusing, I noticed that different CDNs send back different Content-Types: YUI and jQuery‘s CDNs send back “application/x-javascript” whereas Google’s CDN serving jQuery sends back “text/javascript; charset=UTF-8″.

So does it really matter what the Content-Type is? Let’s find out!

Setting up the tests

The test is fairly simple: I have six JavaScript files that all write to the DOM when they’re executed successfully. Each of these files has a different file extension (js.one, js.two, js.three, etc) and each is served with an extension determined by the .htaccess file, which is in the same directory, and contains this bit of magic:

AddType text/javascript .one
AddType application/x-javascript .two
AddType application/javascript .three
AddType text/ecmascript .four
AddType text/jscript .five
AddType text/foo .six

My index.html contains a little helper utility for each of these scripts to use:

var TEST = {
  node: document.body,
  addMessage: function(message) {
    var p = document.createElement('p');
    p.innerHTML = message;
    this.node.appendChild(p);
  }
}

TEST.addMessage() is simply a glorified document.write. As each of the six scripts is run, they’ll write out a message to the page essentially saying “I’m here! It worked!”.

Results

All the browsers I tested worked better than expected. It turns out that Content-Type doesn’t even matter. I made up my own content type “text/foo”, served the file successfully, and it still executed as JavaScript!

I tried all the major A-grade browsers (yes, including IE6-8), plus other random browsers through Browsershots.org.

One thing I still need to try is IE9, which Paul Irish said may not work. I’ll give it a test… soon.

Additional test #1: playing with the “type” attribute

Instead of messing around with the MIME type sent back in the response header, what happens when we mess around with the “type” attribute on the script tag? For instance:

<script type="text/foo"></script>

Using the same testing technique as above, I found these results to be more pronounced. Browsers were more picky. For instance, Chrome and Safari ran all the content types successfully except my made-up “text/foo”. Firefox was even more picky, choosing not to recognize the type “text/jscript”. I’d imagine there’s similar results with other browsers such as IE.

…But none of that really matters now! Simply omit the type attribute and everything seems to work fine (except possibly not in IE9?).

Additional test #2: content type and caching

Philip Tellis wanted to know if Content-Type had any bearing on how the browser caches data. For instance, if something previously requested has the same filename but a different content type, is there a cache hit (304 code returned) or miss?

In the first test I made a page that requested a file. Then in a not-too-fancy way I changed the content type through .htaccess on the fly and made another request. A 304 code was returned even with the new content type, so it was clear that this traditional caching method wasn’t affected.

In my second test I instead changed the “type” attribute on the script tag itself (in the HTML). The file was still cached normally, even after the type changed.

I only tested in Chrome, Safari, and Firefox, so the story might be different in IE. Anyhow, this is an edge case anyway and more of a test out of curiosity! It seems the way browsers handle caching in these instances is truly RESTful, that is, the current state of the file is determined entirely by the filename.

JS1k contest – and the winner

PromoteJS – Google bombing with a good intent. Better links to JavaScript documentation!

Async and defer attributes for Script tags added to WebKit

Evercookie – uses devious ways to try to track users. Hmm, this one is questionable. Please use it for good, not evil.. :/

JSPerf.com – not really new news, but a nice quick way to test algorithm performance in JavaScript

yepnope.js – a wrapper around LABjs Script Loader to save bandwidth by only loading needed components. Think of JSON – there’s no reason to send this down the wire if the browser supports this natively.

Classlist in Firefox 3.6 – for easier manipulation of classes on elements. And it just landed a patch in WebKit!

QuirksBlog: Click event delegation on the iPhone and an update

Chrome Speak To Site; Give any input the power to listen to you – support for input type=speech (supported by WebKit)

embedJS – selective JS for embedded devices (mobile, TV, etc.) based on capabilities.

JS Console for iOS – native JS console built by Remy Sharp.

Joyent Node SmartMachine – API for node.js?

Slides: Pushing browsers to the limit (Ben Firshman) – by the creator of Virtual NES – all in JavaScript!

Release the Kraken – Mozilla releases its Kraken JavaScript benchmark, analogue to WebKit’s SunSpider

On the desktop we’re quite privileged to have nice debugging tools such as Firebug and Web Inspector in Webkit-based browsers. But when it comes to mobile, debugging JavaScript with console.log isn’t quite as easy.

Probably the best available tool on mobile at the moment is mobile Safari’s console, which looks like the following when enabled (Settings -> Safari -> Developer -> Debug Console):

Mobile Safari's debug console

On the left you can see the debug console displayed above the document itself, and on the right is an example of what you might see after outputting an object or a string of text to console.log. It’s the best debugging tool on mobile, but it’s not without its issues.

The first issue is that the debug console is taking up space in the screen and interfering with how an actual user would view the website. I could image this could become particularly annoying when trying to develop a web app in the style of the new YouTube mobile, which doesn’t function like a traditional webpage at all, and relies on the screen being a certain height in order to display its content.

The second issue is that you can’t see the contents of JavaScript Objects. We’re a bit spoiled being able to see a tree view of objects on the latest browsers with the latest debugging tools, and therefore it makes the experience on mobile Safari less than adequate. When we type console.log(navigator) all we can see on mobile Safari is [object Navigator], which leaves something to be desired.

So what about Android? Google offers something called Android Debug Bridge, which is a client-server debugging solution that can be used either for web or application development. As such, when you view the messages the devices sends to the server, the vast majority of messages will be messages about low-level operations, stuff we usually don’t care much about when developing with JavaScript. The workaround for this is to grep for “console” on the command line, which will only display the messages we’re interested in.

The solution: server side console.log!

Why not just send the contents of your console message to a server, and have it log it? The concept is pretty simple:

1. Create a log function that sends an XHR to a server.
2. Have the server process the request and log the message to a file.
3. Tail the end of the file on the command line to see the latest messages.

The implementation is pretty simple. In JavaScript we have this code:

(function(){

// define console if not already defined
console || (console = {});

// new toFile method
console.toFile = function(log) {
  // variable declarations
  var http, url, params;

  // might as well use the traditional console.log() as well
  console.log(log);

  // ajax request
  http = new XMLHttpRequest();
  url = "//example.com/log.php";
  params = "log=" + Date.now() + ' ' + escape(sanitize(log));
  http.open("POST", url, true);
  http.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
  http.send(params);
}

// do something special if txt is an object
var sanitize = function(txt) {
  var output, x;

  if(typeof txt == 'object') {
    // create a new object to get around circular references
    output = {};
    for(x in txt) {
        // type conversion of each element to a string
        output[x] = txt[x] + '';
    }
    output = JSON.stringify(output, null, 2);
  } else {
    output = txt;
  }

  return output;
}

})();

In summary, the above code adds a new method to the console object called toFile, which simply takes the inputted data and sends it to the specified URL. The only bit of trickery here is the function sanitize, which detects if the message being passed in is an object. If it is, it copies it to a new object containing only strings (which gets around JSON “circular reference” errors) and runs JSON.stringify() on it, which lets us peek into its contents one level deep.

The server side PHP code to make this work is even simpler:

// log.php
<?php

// take advantage of error_log to log the message to the file console.log
@error_log($_POST['log'] . "\n", 3, 'console.log');

?>

On the server, we log in with terminal, navigate to the directory containing the file console.log, and simply tail the end of the file, which shows live updates as new messages are added to the end of the file:

tail -f console.log

Example

Once we have the above code in place, using the console is very simple:

console.toFile('hello world!');
console.toFile(navigator);

After running this code, you should see this pop up on your terminal:

1284574866900 hello world!
1284575008914 {
  "geolocation": "[object Geolocation]",
  "standalone": "false",
  "cookieEnabled": "true",
  "language": "en-us",
  "productSub": "20030107",
  "product": "Gecko",
  "appCodeName": "Mozilla",
  "mimeTypes": "[object MimeTypeArray]",
  "vendorSub": "",
  "vendor": "Apple Computer, Inc.",
  "platform": "iPhone",
  "appName": "Netscape",
  "appVersion": "5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7",
  "userAgent": "Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7",
  "plugins": "[object PluginArray]",
  "onLine": "true",
  "javaEnabled": "function javaEnabled() {\n    [native code]\n}",
  "getStorageUpdates": "function getStorageUpdates() {\n    [native code]\n}",
  "registerProtocolHandler": "function registerProtocolHandler() {\n    [native code]\n}",
  "registerContentHandler": "function registerContentHandler() {\n    [native code]\n}"
}

Sweet! Now we can easily see console messages from actual devices. You can potentially use this code to log Events as they occur (on click or touch interactions) and view the actual x/y coordinate values as they’re being detected on the device!

Related

Alex Kessinger implemented a similar concept with node.js running locally

Update

It turns out that Joe Hewitt did this before me with his “Firebug for iPhone”. I have no idea why it took me so long to find this!

Usually developers are more interested in just getting the dang code to work, and as a result actual the testing and maintenance of JavaScript isn’t talked about too much, so I’m sure this will be new territory for many developers. And since it’s John Resig speaking, there was of course a bit about using TestSwarm, a testing distributed framework-agnostic automated testing tool (that’s a mouthful!).

Included in the talk are good things to note while testing, such as the fact unless you’re running Firefox or Chrome on Windows, all test times have a margin of error of up to 15ms (not to be confused with PPK’s observation of the delay between JavaScript computation and browser rendering).

(via YUIBlog)