Opting in to JavaScript strict mode is a way of restricting what can be done in one's code in order to ensure that one's code will be compliant with newer versions of the language when they become available.

When using strict mode, certain code practices that were be permitted with earlier versions of JavaScript, but that are proscribed by the upcoming versions, will cause JavaScript errors to be thrown. In a nutshell, you basically want to ensure now that your codebase is happy when using JavaScript strict mode in order to minimize the future pain of having to make potentially more serious and costly retrofits down the line. In this spirit, the entire codebase of the UIZE JavaScript Framework is written to use strict mode.

There are numerous impacts that arise from using JavaScript strict mode.

Rather than go into detail on these impacts here, please spend some time reviewing some of the articles available online on the subject...

Given the way that UIZE modules implement JavaScript strict mode, you don't have to worry about concatenating UIZE modules along with your own JavaScript code that may not use strict mode.

The well-conceived syntax for declaring modules in UIZE makes it easy to update a module to use strict mode without having to worry about possible interactions with other modules or code libraries that would be concatenated alongside it when packaging JavaScript code to be ready for a production environment. This is because JavaScript strict mode is implemented as an opt-in at a function level (lexically scoped), and because the implementation code for a UIZE module is always contained inside a builder function.

EXAMPLE

Uize.module ({
  name:'MyNamespace.MyModule',
  builder:function () {
    'use strict';

    // IMPLEMENTATION
  }
});

In the above example, the 'use strict' directive prologue is being used to indicate that the code inside the builder function of the MyNamespace.MyModule module must be interpreted and run using JavaScript strict mode. Now, the code from this module can be concatenated into the same JavaScript file alongside other code that does not use strict mode without any worries - the 'use strict' directive inside the builder function applies only to that function and not to the other code concatenated alongside. That other code can, itself, independently opt in to using strict mode.

While it is recommended that you update your own code to use strict mode as a way of preparing for the future of JavaScript, using strict mode is still entirely optional

Your own modules don't have to be implemented using strict mode in order to work with UIZE. You can use UIZE modules that use strict mode alongside your own modules that don't use strict mode. You can even create a subclass of a UIZE class where that class uses strict mode but where the code in your subclass does not (this is thanks to the lexically scoped nature of strict mode).

When you call the eval function from within strict mode code, the code that you evaluate is interpreted and executed using strict mode as well.

EXAMPLE

function foo () {
  'use strict';
  eval ('with (document) {}'); // produces a JavaScript error - you can't use "with" in strict mode
}
foo ();

In the above example, calling the foo function will result in a JavaScript error being thrown. That's because the function's implementation uses the 'strict mode' directive prologue and then tries to eval code that is not compliant with strict mode. In addition to imposing strict mode on code evaluated using the eval function, strict mode always enforces sandboxing of variables declared within the code being evaluated. For more details on this, consult one of the excellent online resources.

In cases where you wish to evaluate code that is not compliant with strict mode from within code that is using strict mode, you may be able to get by with using the Uize.laxEval method. So, the above example could be rewritten as follows...

THIS WORKS

function foo () {
  'use strict';
  Uize.laxEval ('with (document) {}'); // this works just fine
}
foo ();

One thing to consider when using the Uize.laxEval method is that, while it allows code to be evaluated in non-strict mode even from strict mode code, the code is evaluated in a quarantined fashion - it is not evaluated in the current local scope, but rather with only the global scope at the top of its scope chain. This means that the code being evaluated can't rely on variables or functions from the local scope, or any scope up the scope chain - it can only access identifiers from the global scope. This is generally ok and usually desirable, because it allows code to be evaluated from any scope without the evaluated code conflicting with identifiers defined in the local scope or elsewhere up the scope chain.

When you call the eval function from within non-strict mode code, the code that you evaluate is interpreted and executed using non-strict mode as well.

EXAMPLE

function foo () {
  eval ('with (document) {}'); // this is allowed, because eval is from within non-strict mode
}
foo ();

In the above example, calling the foo function will not produce any JavaScript errors. That's because the function's implementation does not use the 'strict mode' directive prologue, so the code being eval'd is evaluated also using non-strict mode. One way to impose strict mode on code being evaluated from within non-strict mode code is to explicitly place the 'use strict' directive prologue at the start of the code being evaluated, as follows...

STRICT EVAL

function foo () {
  eval ('"use strict"; with (document) {}'); // strict mode explicitly invoked, so we get an error
}
foo ();

Another way to enforce strict mode for code evaluated from within non-strict mode code is to use the Uize.eval method, as follows...

STRICT (AND QUARANTINED) EVAL

function foo () {
  Uize.eval ('with (document) {}'); // Uize.eval imposes strict mode, so we get an error
}
foo ();

Unlike the companion Uize.laxEval method, the Uize.eval method imposes strict mode. Like the Uize.laxEval method, however, the Uize.eval method also performs quarantined evaluation of code, so the code being evaluated can't access identifiers from the local scope or any scope up the scope chain - it can only access identifiers from the global scope.

Strict mode also has implications for the Uize.quarantine method that are a little subtle (and highly esoteric).

First off, most developers are unlikely to ever need to use the Uize.quarantine method. The Uize.quarantine method provides a way to define a function in some deeply nested scope but have the function be quarantined from that scope so that it only has access to the global scope when executed.

3.3.1. An Expected Consequence

(function () {
  'use strict';

  var quarantinedFunc = Uize.quarantine (
    function (person) {
      with (person) {
        alert (name);
      }
    }
  );
}) ();

3.3.2. An Unexpected Consequence

(function () {
  'use strict';

  var quarantinedFunc = Uize.quarantine (
    function () {
      accidentalGlobal = 'foo';
    }
  );

  quarantinedFunc ();
}) ();

(function () {
  'use strict';

  var quarantinedFunc = Uize.quarantine (
    function () {
      'use strict';

      accidentalGlobal = 'foo';
    }
  );

  quarantinedFunc ();
}) ();

3.3.3. Highly Esoteric, So Don't Worry