The following functions handle several ways of URI encoding and decoding:

The following are deprecated:

The following methods help with categorizing and parsing numbers:

The function call:

eval(str)

evaluates the JavaScript code in str. For example:

> var a = 12;
> eval('a + 5')
17

Note that eval() parses in statement context (see Expressions Versus Statements):

> eval('{ foo: 123 }')  // code block
123
> eval('({ foo: 123 })')  // object literal
{ foo: 123 }

function sloppyFunc() {
    eval('var foo = 123');  // added to the scope of sloppyFunc
    console.log(foo);  // 123
}

function strictFunc() {
    'use strict';
    eval('var foo = 123');
    console.log(foo);  // ReferenceError: foo is not defined
}

var x = 'global';

function directEval() {
    'use strict';
    var x = 'local';

    console.log(eval('x')); // local
}

var x = 'global';

function indirectEval() {
    'use strict';
    var x = 'local';

    // Don’t call eval directly
    console.log(eval.call(null, 'x')); // global
    console.log(window.eval('x')); // global
    console.log((1, eval)('x')); // global (1)

    // Change the name of eval
    var xeval = eval;
    console.log(xeval('x')); // global

    // Turn eval into a method
    var obj = { eval: eval };
    console.log(obj.eval('x')); // global
}

function strictFunc() {
    'use strict';

    var code = '(function () { return this }())';
    var result = eval.call(null, code);
    console.log(result !== undefined); // true, sloppy mode
}

The constructor Function() has the signature:

new Function(param1, ..., paramN, funcBody)

It creates a function whose zero or more parameters have the names param1, parem2, and so on, and whose body is funcBody; that is, the created function looks like this:

function («param1», ..., «paramN») {
    «funcBody»
}

Let’s use new Function() to create a function f that returns the sum of its parameters:

> var f = new Function('x', 'y', 'return x+y');
> f(3, 4)
7

Similar to indirect eval(), new Function() creates functions whose scope is global:^[18]

var x = 'global';

function strictFunc() {
    'use strict';
    var x = 'local';

    var f = new Function('return x');
    console.log(f()); // global
}

Such functions are also sloppy by default:

function strictFunc() {
    'use strict';

    var sl = new Function('return this');
    console.log(sl() !== undefined); // true, sloppy mode

    var st = new Function('"use strict"; return this');
    console.log(st() === undefined); // true, strict mode
}

Normally, it is better to use new Function() than eval() in order to evaluate code: the function parameters provide a clear interface to the evaluated code and you don’t need the slightly awkward syntax of indirect eval() to ensure that the evaluated code can access only global variables (in addition to its own).

You should avoid eval() and new Function(). Dynamically evaluating code is slow and a potential security risk. It also prevents most tools (such as IDEs) that use static analysis from considering the code.

Often, there are better alternatives. For example, Brendan Eich recently tweeted an antipattern used by programmers who want to access a property whose name is stored in a variable propName:

var value = eval('obj.'+propName);

The idea makes sense: the dot operator only supports fixed, statically provided property keys. In this case, the property key is only known at runtime, which is why eval() is needed in order to use that operator. Luckily, JavaScript also has the bracket operator, which does accept dynamic property keys. Therefore, the following is a better version of the preceding code:

var value = obj[propName];

You also shouldn’t use eval() or new Function() to parse JSON data. That is unsafe. Either rely on ECMAScript 5’s built-in support for JSON (see Chapter 22) or use a library.

This was a relatively high-level overview of dynamically evaluating code in JavaScript. If you want to dig deeper, you can take a look at the article “Global eval. What are the options?” by kangax.

The implementations of the console API vary greatly and are constantly changing. If you want authoritative documentation, you have two options. First, you can look at standard-like overviews of the API:

Second, you can look at the documentation of various engines:

The console API includes the following logging methods:

Support on various platforms is indicated in the following table:

exception has been typeset in italics, because it is supported only on a single platform.

The console API includes the following checking and counting methods:

Support on various platforms is indicated in the following table:

The console API includes the following methods for formatted logging:

The resulting table is as follows:

Support on various platforms is indicated in the following table:

The console API includes the following methods for profiling and timing:

Support on various platforms is indicated in the following table:

markTimeline has been typeset in italics, because it is supported only on a single platform. The (devtools) designation means that the developer tools must be open in order for the method to work.^[19]