Legitimate uses of the Function constructor

As repeatedly said, it is considered bad practice to use the Function constructor (also see the ECMAScript Language Specification, 5^th edition, § 15.3.2.1):

new Function ([arg1[, arg2[, … argN]],] functionBody)

(where all arguments are strings containing argument names and the last (or only) string contains the function body).

To recapitulate, it is said to be slow, as explained by the Opera team:

Each time […] the Function constructor is called on a string representing source code, the script engine must start the machinery that converts the source code to executable code. This is usually expensive for performance – easily a hundred times more expensive than a simple function call, for example. (Mark ‘Tarquin’ Wilton-Jones)

Though it's not that bad, according to this post on MDC (I didn't test this myself using the current version of Firefox, though).

Crockford adds that

[t]he quoting conventions of the language make it very difficult to correctly express a function body as a string. In the string form, early error checking cannot be done. […] And it is wasteful of memory because each function requires its own independent implementation.

Another difference is that

a function defined by a Function constructor does not inherit any scope other than the global scope (which all functions inherit). (MDC)

Apart from this, you have to be attentive to avoid injection of malicious code, when you create a new Function using dynamic contents.

That said, T.J. Crowder says in an answer that

[t]here's almost never any need for the similar […] new Function(...), either, again except for some advanced edge cases.

So, now I am wondering: what are these “advanced edge cases”? Are there legitimate uses of the Function constructor?

NWMatcher — Javascript CSS selector and matcher, by Diego Perini — uses Function constructor (1, 2, 3, 4, etc.) to create ("compile") highly-efficient versions of selector matchers.

The benchmark (which I just ran on Chrome 5) speaks for itself:

Note the difference between NWMatcher and Sizzle, which is a very similar selector engine, only without function compilation :)

On a side note, ECMAScript 5 doesn't throw any errors on invocation of Function. Neither in strict, nor in "standard" modes. Strict mode, however, introduces few restrictions on presence of identifiers such as "eval" and "arguments":

• You can't have declare variables/functions/arguments with such names:

  function eval() { }
  var eval = { };
  function f(eval) { } 
  var o = { set f(eval){ } };
  

• You can't assign to such identifier:

  eval = { };
  

Also note that in strict mode, eval semantics is slightly different from that in ES3. Strict mode code can not instantiate variables or functions in the environment from which it was called:

 eval(' "use strict"; var x = 1; ');
 typeof x; // "undefined"

jQuery uses it to parse JSON strings when a JSON parser object is not available. Seems legit to me :)

        // Try to use the native JSON parser first
        return window.JSON && window.JSON.parse ?
            window.JSON.parse( data ) :
            (new Function("return " + data))();

I use the new Function() constructor as an in-line JS interpreter in one of the web apps I'm developing:

function interpret(s) {
  //eval(s); <-- even worse practice
  try {
      var f = new Function(s);
      f();
    }
  catch (err) {
      //graceful error handling in the case of malformed code
  }
}

As I get stuff streaming over AJAX (not an iframe), I continuously interpret() it on readyStateChange == 3. This works surprisingly well.

Edit: here's a clear case study that shows that new Function() is categorically faster than eval(). I.e. you should never (rarely?) use eval in lieu of new Function().

http://polyfx.com/stuff/bsort.html <- the 1000 iteration version, may crash your browser

http://polyfx.com/stuff/bsort10.html <- the shorter version

Eval is on average, almost 8 times slower than new Function().

John Resig used the Function constructor to create "compiled" versions of client-side templates written in an asp syntax. http://ejohn.org/blog/javascript-micro-templating/

This is a separate case from my other answer.

I used the Function constructor a while back to create custom string formatters that were being called repeatedly. The overhead of creating the function (which I take it is the performance issue you're talking about) was far outweighed by the improved performance of the custom-built functions, which were created at runtime specifically to process a particular format string, and therefore did not need to evaluate tons of irrelevant cases — or parse a format string, for that matter. It's a bit like compiling a regular expression, I suppose.