Function Smackdown: Function Statement vs. Function Expression

 

I’ve recently been reading ‘JavaScript: The Good Parts,’ by Douglas Crockford. This concise book defines a subset of core JavaScript that’s robust and powerful: The Good Parts. Appendix B identifies The Bad Parts, and sets our competitors - the function statement and the function expression - apart.

ROUND ONE - LOOKS (CAN BE DECEIVING)

Function Statement

Our competitors may look alike, but the function statement has two distinguishing characteristics: the declarative keyword function always comes first, and you must name it. Here’s what it looks like:

// What we see
function funcName(){}

　　

Pull back the curtain, though, and the function statement expands into a variable with a function value:

// Under the hood
var funcName = function funcName(){}

　　

Function Expression

Absent the mark of the function statement, you have the function expression. The function expression is optionally named (but normally anonymous), e.g.:

// Stores ref. to anonymous function in a variable 
var funcRef = function(){};

// Stores ref. to named function in a variable 
var funcRef = function funcName(){};

　　

WINNER: Function Expression. Crockford’s manual argues the case for clear code. The function expression is clearly recognisable as what it really is (a variable with a function value).

ROUND TWO - (UNPREDICTABLE) BEHAVIOUR

Function Expression

Variables are subject to a thing called hoisting. Irrespective of their apparent place in the flow of things, their var part is removed and hauled to the top of a containing (whether function or global) scope, and initalised with undefined:

// What we see
var funcRef = function(){};

// Under the hood
var funcRef = undefined;
funcRef = function(){};

　　

Function Statement

The function statement - while just shorthand for a var statement with a function value - is treated differently: the whole lot is hoisted. For this reason, you can call a function statement before you have declared it in your code:

console.log(statement()); // I am a function statement.
console.log(expression()); // TypeError...

function statement(){  
  return "I am a function statement.";
}

var expression = function(){
  return "I am a function expression.";
}

　　

WINNER: Function Expression. Hoisting is already a behind-the-scenes behaviour that can cause head scratching. The particular behaviour of the function statement can lead to more furious head scratching.

ROUND THREE - SUPER POWERS

Function Statement

The function statement is widely used and performs just fine, but it has an obvious limitation: You can’t immediately invoke it.

Function Expression

The function expression is more flexible, e.g.:

// Executed immediately
(function() {
   alert("I am not a function statement.");
}());

　　

Parentheses are required to nudge function out of statement position (can’t immediately invoke), and into expression position (can immediately invoke). Crockford recommends grouping the entire invocation inside parentheses for clarity - what’s important here is the product of the invoked function - otherwise, Crockford argues, “you’ve got these things hanging outside of it looking like dog balls.”

WINNER: Function Expression.

FINAL SCORE: Function Expression Wins 3 - 0

CONCLUSION - I HEART A GOOD MANUAL

It turns out the function statement came first; the function expression was added to JavaScript later. The result is two very similar ways of defining JavaScript functions. Logically, the addition was intended to improve the language, and, in this case, it would seem this end was achieved.

If you haven’t already seen it, here’s a particularly entertaining speech (2011) Crockford gave on his approach to JavaScript: