Check out a free preview of the full Deep JavaScript Foundations, v3 course

The "Strict Mode" Lesson is part of the full, Deep JavaScript Foundations, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Kyle gives various arguments for the usage of strict mode.


Transcript from the "Strict Mode" Lesson

>> Kyle Simpson: So now if we flip on strict mode, which you do by putting this strict mode fragment at the top of any scope, preferably at the top of your program, the top of your file, or at the top of any function. If you turn on strict mode, all the same processing is going to happen.

So since we've run through this, we don't have to keep belaboring this point. But when we arrive at this line and we say, hey, scope of other class, I have this target reference for topic ever heard of it. There's no blue marble, we go to the global scope and we say, global scope have you ever heard of topic, and the global scope kind of respond with

>> Speaker 1: No
>> Kyle Simpson: Reference error, never heard of it. That's a different kind of error than a type error. Type errors are when you found the variable and the value that it is currently holding is not legal to do whatever you're trying to do with it. Like execute a function, access a property on an undefined null, things like that, that's type error.

A reference error is, I couldn't find that variable, I can't give you a variable to use, okay? That's what we would like to happen all of the time. It now happens as the result of strict mode, you get a reference error. Sorry, no marble, tough luck. So one of the many, many reasons why it would be good for you to be using strict mode.

It will avoid mistakes like this, cuz it almost certainly a mistake, it should not be something you intentionally try to create global, yes?
>> Speaker 1: Is strict mode always pretty on ES6
>> Kyle Simpson: Strict mode is not always on. It's true that tools like Bubble and other transpilers basically always put the strict mode in there for you.

So if you're using transpired code, it was almost a virtual certainty that your code is running in strict mode. But JavaScript is not default the strict mode because then that would break a bunch of programs. So that were written 20 years ago or something. So because of backwards compatible, you will always have to opt into strict mode.

Another little caveat inside of certain kinds of mechanisms within ES6 and going forward, it is assumed to be in strict mode. So you don't even type it, so inside of a class to talk about later in the course, or inside of ES6 module, which we'll talk about later in this unit.

Inside of both of those, strict mode is assumed, you don't even have to put the strict mode, is just assume that, that code is running in strict mode. But as a general rule for JavaScript itself, it's not in strict mode unless you opt-in. What you should know about strict mode is, it's essentially the future of the language, more and more will be like classes and modules and assume the strict mode.

So you might as well just go ahead and bite that bullet. It's been around now for almost a decade basically a decade. So it's definitely time if you're not using strict mode, go ahead and take the pain and switch, yes?
>> Speaker 1: If you don't use strict are there newer features that won't work?

>> Kyle Simpson: They do sometimes talk about or discuss, this feature will only work a certain way in strict mode or not-strict mode. Because if they add a new feature, they don't have any chances of having broken somebody's code from 20 years ago. I'm not aware of any specific examples where this syntax is not even available, if you haven't switched on strict mode.

But it is certainly within the realm of possibility that things like that may occur, or that behaviors will be different. There can be nuanced different behaviors, like we're seeing here. One might be permissive and one might be not. Another example of strict mode having a difference and it has nothing to do with ES6.

Back in ES5, when strict mode was introduced, we had several different kinds of errors that if you were not in strict mode they were errors, but they were silent, they just nothing happened. So for example, trying to assign to a read only property, or a read only variable, it just would silently not do anything.

It wouldn't actually do the assignment. Once you turn on strict mode, now you start getting errors for those. So there are differences in observable behavior as a result of that, but I wouldn't necessarily say that there's a lot of ostensible features that you can't use without them
>> Speaker 1: Question, so the topic, in strict mode, they always have to be defined, right, pretty much?

My question is if topic was in a global scope, it's still the same error, right?
>> Kyle Simpson: I don't know.
>> Speaker 1: If the-
>> Kyle Simpson: If line 7 was in the global scope?
>> Speaker 1: Exactly.
>> Kyle Simpson: Yeah, yeah, yeah.
>> Speaker 1: It would still blow up?
>> Kyle Simpson: It still blows up.
>> Speaker 1: Okay, that's all.

>> Kyle Simpson: You cannot auto create variables, you have to declare them.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now