JavaScript is a very forgiving language. It’s easy to write code that runs but has mistakes in it.
In this article, we’ll look at the benefits of using the strict mode directive.
Add Use Strict Mode Directive in Our Scripts
If we’re using old-school JavaScript script files, then we should add the 'use strict'
directive into the top of our script.
Strict mode eliminates lots of silent errors by changing them to throw errors.
It also fixes mistakes that make optimizing our JavaScript code hard to increase their performance.
Also, it bans syntax that may be used in future JavaScript versions. Keywords like class
can’t be used to declare variables, for example.
Strict mode can be applied to the whole script by putting the directive at the top or just in the function level by putting it in functions.
However, we should just apply it everywhere since it brings lots of benefits.
For instance, we can’t declare variables accidentally with 'use strict'
on:
'use strict';
x = 1;
Since we have the 'use strict'
directive on top of our script, we’ll get an error with the x = 1
expression since we haven’t declared x
yet.
Without strict mode, this would create a global variable called x
and assign 1 to it and pollute the global scope.
That isn’t good because it may overwrite another global variable with the same name.
Also, we can assign values to another global value like undefined
or Infinity
:
With strict mode on, code like the following will throw a TypeError:
var undefined = 1;
var Infinity = 1;
Assigning values to a non-writable property will also fail with a TypeError thrown:
var obj = {};
Object.defineProperty(obj, 'foo', { value: 42, writable: false });
obj.foo = 9;
We also wouldn’t be able to add properties that has preventExtensions
called on it to prevent that:
var obj = {};
Object.preventExtensions(obj);
obj.foo = 'a';
The code above would throw a TypeError.
Attempting to delete undeletable properties will also throw an error. If we write something like:
'use strict';
delete Object.prototype;
Then we’ll get a TypeError.
Strict mode also requires function parameters to be unique. For instance, if we write:
'use strict';
function add(a, a, c) {
return a + a + c;
}
Then we’ll get an ‘Uncaught SyntaxError: Duplicate parameter name not allowed in this context’ error since we have JavaScript strict mode on.
Also, it prevents numbers with a leading 0 from being used. The leading zero for octal numbers is rarely used and developers often assume that it’s still a decimal number.
Therefore if we have the following the strict mode throws an error:
'use strict';
var sum = 015 + 222;
If we run that, we get ‘Uncaught SyntaxError: Octal literals are not allowed in strict mode.’
The with
statement is prohibited in strict mode. With strict mode, confusing code like this is prohibited:
'use strict';
var x = 17;
with(obj) {
console.log(x);
}
The code above is confusing because x
can either be obj.x
or just x
. It’s hard to tell what it’s referring to.
With strict mode on as we have above, we get ’Uncaught SyntaxError: Strict mode code may not include a with statement’.
Doing anything to arguments
or eval
will also return syntax errors, so code like the following:
'use strict';
eval = 'foo';
arguments++;
Then we get ‘Uncaught SyntaxError: Unexpected eval or arguments in strict mode’ when we run the code above since we have JavaScript strict mode on.
We shouldn’t use these entities regardless of whether JavaScript strict mode is on, so it’s good that strict mode prevents expressions like these from running at least.
With strict mode on, the this
value passed into call
, apply
, or bind
aren’t boxed into an object.
Therefore, the original value is preserved if we pass in a primitive value. For instance, if we have:
'use strict';
function fn() {
return this;
}
console.log(fn.call(1) === 1);
Then we get 1
returned from fn
instead of new Number(1)
, so we get that the console log output returns true
.
Strict mode is enabled automatically for modules so we don’t need the directive on top of our code.
Conclusion
With so many benefits to strict mode, we should always enable it in old-school scripts.
If we use JavaScript modules, then it’s enabled by default, so we don’t have to worry about it.
We just have to put 'use strict'
on top of all our scripts.