Seriously Strict Script

I don’t know about you, but I grew up with some seriously strict parents, so my inclination to be open to restrictions was shattered at about 10 years old. Fortunately, with age comes wisdom (well… hopefully), or at least experience.

When reading about all the forbidden things in strict mode, you may feel like “why would I ever want to use this in my code?!?!?!” but lets suspend our judgements for a minute and look at how it actually benefits you in the long run (kinda like a curfew in high school)!

Why use Strict Mode?

Strict mode is called strict for good reason. It definitely restricts certain ways of writing code, but let’s look at what and why…

• Javascript, the “Wild West” of coding languages, allows you to write code in A LOT of ways. What makes it such a powerful language, also leaves a ton of room for errors, and errors you may not even know about and cause very unexpected behavior. Strict mode eliminates the possibility of some of these silent errors by alerting you when it happens (with an error!). It will also throw an error when ‘unsafe’ actions are taken (such as gaining access to the global object). We want errors! Huge incentive here!
• Another drawback of the unrestricted Wild West is that it can make it difficult for Javascript engines to perform optimizations. Reigning in your code with strict mode will point out mistakes that will prevent optimizations in your code. Also, strict mode code can be made to run faster than identical code that’s not strict mode.
• Strict mode thinks into the future for us. It doesn’t allow use of potential reserved words that are likely to be defined in future versions of ECMAScript. This means that when new versions come out, your code function won’t be jeopardized if they define a reserved word that you used in a different way.
• As compared to Ruby on Rails, there is little “magical” behavior in JavaScript. One area where there appears to be some magic is in the use of “eval” and “arguments.” “Eval” can add or remove bindings, or change binding values, and “arguments” has indexed properties that alias named arguments. Using these features can be confusing and poorly thought out. The future of ECMAScript holds making these words keywords, but for now, strict mode works toward this reality until that day comes. The word “eval” and “arguments” cannot be used as a variable and “eval()” is not allowed to create variables in the scope from which it was called. And POOF! The magic is gone!
• Strict mode makes it easier to write “secure” JavaScript. Nowadays, there are websites that provide ways for users to write Javascript that the website runs on behalf of other users! So what happens to private information? The JavaScript has to be transformed before it is run to protect and censor. The nature of the Wild West makes it almost impossible to do this without an excessive amount of runtime checks which then can take a toll on performance costs. BUT! If a user is required to use strict mode and invocations in a certain way, with a few tweaks, the need for the runtime checks is dramatically reduced.

How to use Strict Mode

• Very simply, to make a script use strict mode, you add the statement "use strict" or 'use strict' at the top of the script before any other statements which, then applies it to the entire script, including nested functions. You can also apply it to individual functions in the same way. Be careful! It is only recognized at the beginning of a function or script and it can only be applied to an individual function or an entire script. You can not apply strict mode to individual statements or blocks.
• While concatenation of scripts is not usually ideal, keep in mind that you are NOT able to concatenate a strict mode and non-strict mode script. If you do this is what happens: strict + non-strict = everything’s strict (or the inverse of non-strict + strict = nothing’s strict) The alternative to this is to enable strict on a function-by-function basis OR you can wrap the entirety of a script in a function and export the shared variables out of the functions scope.

So now what is prohibited?

I won’t go through every single example of what happens when you “use strict,” but there are some really important changes I will illustrate. (For the complete list of what changes, check out the link to the MDN docs at the bottom)

• Using a variable or object, without declaring it

• Deleting a variable, object, or function

• Writing to a read-only or get-only property

• Deleting an undeletable property

• Duplicating a parameter name

• Octal numeric literals and escape characters

• Setting properties on primitive values

• The with statement

• The this keyword in functions behaves differently in strict mode. The this keyword refers to the object that called the function. If the object is not specified, functions in strict mode will return undefined and functions in normal mode will return the global object (window).

• Keywords reserved for future JavaScript versions can NOT be used as variable names in strict mode. (i.e. implements, interface, let, package, private, protected, public, static, yield)

In Browsers…

All major browsers also now implement strict mode, but you still have to be careful and aware. There are some wild animals out there that may only have partial support or none at all (such as Internet Explorer below version 10). Back up your reliance on strict mode with tests for features to make sure the strict mode code is working properly. Furthermore, make sure you test in browsers that do and do not support strict mode so you know it will work everywhere.

In Modern JavaScript…

Years ago, you may have seen strict mode being invoked everywhere. In modern JavaScript, you may not see “use strict” very frequently at all. Wanna know why? Because if your organizing code into modules, its already there! Modern Javascript is applying the philosophy of “do it right the first time” which makes everyones lives easier when compiling components together to make an application.

If browser support is moving in the strict mode direction and if we want modular, reusable code that doesn’t behave weirdly, or break in the future, restrictions are necessary! And with all the work you put in, isn’t that what you want? I guess restrictions aren’t always a bad thing!

References

Can I use... Support tables for HTML5, CSS3, etc

Strict mode

JavaScript "use strict"