I've anecdotally noticed that use strict appears to be more common like this:

(function() {
  'use strict';
  ...

Than this:

'use strict';
(function() {
  ...

The vanilla JS implementation of TodoMVC does this, for example.

Is there a reason for this?

Edit: I'm aware of the whole-file versus function-block distinction. TodoMVC is a good example to demonstrate why this placement is strange to me, because it doesn't rely on any external libraries, so the whole "play nice with non-strict third parties" doesn't apply here.

I've anecdotally noticed that use strict appears to be more common like this:

(function() {
  'use strict';
  ...

Than this:

'use strict';
(function() {
  ...

The vanilla JS implementation of TodoMVC does this, for example.

Is there a reason for this?

Edit: I'm aware of the whole-file versus function-block distinction. TodoMVC is a good example to demonstrate why this placement is strange to me, because it doesn't rely on any external libraries, so the whole "play nice with non-strict third parties" doesn't apply here.

• javascript

• 1 Javascript scripts are often concatenated and minified into a single file. The former approach makes sure you limit the scope of use strict. – vgru Commented Jul 30, 2016 at 6:17

4 Answers 4

Declaring it in local scope will enforce function block to be considered under strict-mode by browser.

You can have non-strict observation for other code outside of the IIFE

Inside IIFE:

(function() {
  "use strict";
  a = 100;
})();
b = 200;

For entire script:

"use strict";
(function() {
  try {
    a = 100;
  } catch (e) {
    console.log(e + '');
  }

})();
b = 200;

As highlighted in docs,

If you are using strict mode for entire script, it isn't possible to blindly concatenate non-conflicting scripts. Consider concatenating a strict mode script with a non-strict mode script: the entire concatenation looks strict! The inverse is also true: non-strict plus strict looks non-strict. Concatenation of strict mode scripts with each other is fine, and concatenation of non-strict mode scripts is fine. Only concatenating strict and non-strict scripts is problematic. It is thus recommended that you enable strict mode on a function-by-function basis (at least during the transition period).

You can also take the approach of wrapping the entire contents of a script in a function and having that outer function use strict mode. This eliminates the concatenation problem but it means that you have to explicitly export any global variables out of the function scope.

I’m guessing it’s because that placement is sure to enable strict mode even if multiple JS files are concatenated together as a build step (to allow organizing of code without the performance penalty of multiple HTTP requests). With placement of "use strict" at the beginning of the file, there could be a problem with these files:

function doThing() {
    console.log("done");
}

"use strict";

(function() {
    document.getElementById('thingy').addEventListener("click", doThing);
})();

If the above files were concatenated with foo.js first, the "use strict" inside main.js would have no effect. This possibility could be avoided by putting the "use strict" inside the function.

I don’t know how common concatenation of JS is any more, and I don’t know whether the newer require method or import keyword lets you place "use strict" anywhere you want, but maybe the placement of "use strict" inside the function caught on while simple concatenation was popular, and people saw no reason to change the convention after using it for so long.

If you using:

'use strict';
(function() {
  ...

It will apply use strict mode to all file.

Opposite, when you using use strict in function like this:

// Non-strict code...

(function(){
  "use strict";
   ...
  // Define your library strictly...
})();

// Non-strict code... 

That might be helpful if you have to mix old and new code.

Why Strict Mode At All

Strict mode eliminates certain permissive language parsing and execution characteristics deemed less desirable from a language design point of view. These non-strict mode language characteristics were deemed prudent as default behavior for backward compatibility. The synopsis and details appear here.

• ECMA-262 7.0 Strict Mode Code
• ECMA-262 7.0 Strict Mode in detail

It is not unambiguously defined when and if these older language characteristics from the early Netscape days will be deprecated or whether strict mode will become default behavior across browsers at some point, but the stricter model is likely to produce less ambiguous and risky source. If you wish to improving maintainability, portability, and extensibility in coding practice and code bases, then strict mode is a good option.

Syntax

"use strict";

Scope of Declaration

The scope of is dependent on whether you place the declaration inside or outside a function and applies to all statements following the declaration within the closure's scope.

Use of the declaration inside the function is the wrong way to do it if all of the file or stream is already compatible with the stricter mode or can be made so with ease. The redundancy is unnecessary, so placing the declaration on the top of the file or beginning of the stream is the recommended use.

Sometimes only some of the functions comply with the stricter rules. In such cases the less desirable function scope of the declaration can be used to encourage finer coding practices at least in the functions that already comply.

NOTE For those coming here from "What's the benefit of using "function() 'use strict'” in every file?"

You can place

"use strict";

on the top of the code sequence or inside the function, so it is only one line of code per file or per function.

The other lines of code have other purposes in the code here.

• Self-invoking function
• Factory invocation