The benefits of strict mode far outweigh the costs, but old habits die hard and the inertia of existing (aka “legacy”) code bases is really hard to shift. So sadly, more than 10 years later, strict mode’s optionality means that it’s still not necessarily the default for JS programmers.

Why strict mode? Strict mode shouldn’t be thought of as a restriction on what you can’t do, but rather as a guide to the best way to do things so that the JS engine has the best chance of optimizing and efficiently running the code. Most JS code is worked on by teams of developers, so the strict-ness of strict mode (along with tooling like linters!) often helps collaboration on code by avoiding some of the more problematic mistakes that slip by in non-strict mode.

Most strict mode controls are in the form of early errors, meaning errors that aren’t strictly syntax errors but are still thrown at compile time (before the code is run). For example, strict mode disallows naming two function parameters the same, and results in an early error. Some other strict mode controls are only observable at runtime, such as how defaults to undefined instead of the global object.

Strict mode is switched on per file with a special pragma (nothing allowed before it except comments/whitespace):

Strict mode can alternatively be turned on per-function scope, with exactly the same rules about its surroundings:

    "use strict";
    // all this code will run in strict mode

Interestingly, if a file has strict mode turned on, the function-level strict mode pragmas are disallowed. So you have to pick one or the other.

Many have wondered if there would ever be a time when JS made strict mode the default? The answer is, almost certainly not. As we discussed earlier around backwards compatibility, if a JS engine update started assuming code was strict mode even if it’s not marked as such, it’s possible that this code would break as a result of strict mode’s controls.

However, there are a few factors that reduce the future impact of this non-default “obscurity” of strict mode.

For one, virtually all transpiled code ends up in strict mode even if the original source code isn’t written as such. Most JS code in production has been transpiled, so that means most JS is already adhering to strict mode. It’s possible to undo that assumption, but you really have to go out of your way to do so, so it’s highly unlikely.

Taken together, strict mode is largely the de facto default even though technically it’s not actually the default.