Deep JavaScript Foundations Strict Mode

[00:00:00]
>> Kyle Simpson: Some thoughts about strict mode for just a moment. If you're not already using strict mode for all of your programs, what are you waiting for? Because there's a difference between I'm a late adopter and I just missed the train entirely. Now, I was a late adopter with strict mode.

[00:00:21] I did not adopt it when it first came around, but that was in 2008, 2009. It's 2017 as we record this. That's a really long time. Restrict mode is well-established. It is absolutely, without question, the future of the language. The inevitable future of the language. The more that they add to the language, the more surface area they're adding that requires or implies strict mode.

[00:00:48] So at this point, it is in your worst interest to continue to avoid or not adopt strict mode. Now [COUGH] I wanna address this for a moment and this is why I have this slide here to talk about strict mode, because it's really important to have the right frame of mind approach with strict mode is about.

[00:01:08] First off, many people think of strict mode. The opposite of strict mode, they will refer to this as sloppy mode and I disagree with that interpretation of the difference between lose, I mean, the difference between strict and whatever this non-strict is. In the same way that I would never talk about a code base that has a lot of lines of code to it, I would never call that a fat code base.

[00:01:42] Because to me, that terminology is unempathetic. It's insensitive. It can offend the people. So there's a sense among some people, many of the people that run the spec committee that you should never, ever write code in the non-strict mode. And so we should make you feel bad, if you're writing code that's still in non-strict mode and that is not at all the message that I wanna get across.

[00:02:08] That's like an insulting or a punitive way to look at it. And even the name sort of suggests like an overbearing parent that won't let you go out and stay out past 8 o'clock and you're like, come on. Why can't I stay out past 8 o'clock? Why you gotta restrict me?

[00:02:25] I need my freedom. Even the name of it suggests something of a negative connotation and I don't think that's helpful. So, I wanna reframe for you the right way to think about strict mode. First off, all the changes that strict mode brought about in ES5 are all listed, actually any changes.

[00:02:43] They're all listed in an appendix of the spec. I think it's appendix E. It's right there in the spec. There's just a list one after the other and they all start kinda like this. It is an error if and then dot, dot, dot. It just fills it in.

[00:02:57] Essentially, it's listing out a set of things that become errors which used to not be error. So, that feels like that's a restriction against you. As a matter of fact, there are some very prominent members of our community who have vocally said on many occasions that they are resisting strict mode.

[00:03:20] That they don't want to switch to it, because they don't wanna be restricted from doing stuff to the point that one of them went so far as to say, I'm gonna write all of my code such that it will break if somebody tries to run it in strict mode.

[00:03:34] Like not just I'm not gonna pay attention, I'm gonna literally try to make my code break in strict mode. That is an extreme deal. That is not something that we should wanna emulate.
>> Kyle Simpson: So, how should we think about strict mode? What's the proper mindset to have for strict mode?

[00:03:54] Let me try to help with that. If you go through and you read all those items in the appendix instead of reading them as restrictions, instead of reading those things where they're slapping you wrist and saying, stop doing that thing. I want you to think about it like this.

[00:04:07] Because virtually, all of those items that are listed there are things that you do in your code that make it harder for the JavaScript engine to optimize the performance of your code.
>> Kyle Simpson: If you go through and you say, why can't I do implicit global variables? Well, you know why?

[00:04:29] Most pragmatic reason means other than the fact that it's a mistake in a bad design, the most pragmatic reason why you shouldn't do it is because it's a lot slower to create a variable at runtime than have to modify an existing lexical scope as opposed to being able to figure it out at compile time.

[00:04:47] It's slower. It's going to slow down the execution of your code. So, if you go through each one of these and you reason through why would they have restricted that? Why would they have prevented that? Most of them are things where if you were doing that thing in your code, you're making your code harder to optimize.

[00:05:04] When viewed from that perspective, strict mode is really like a set of suggestions that you really ought to follow, so that your code will run faster. And I don't know about you, but I need all the help I can get writing optimal code. So, sign me up. If there's a mode that I can adhere to that helps me from making the dumb mistakes that accidentally make my code go slower, I'm on board.

[00:05:31] But I didn't have the right mindset, which why I was kind of a late adopter and there was also a set of myths about strict mode and I wanna clear those myths up for you. One of those myths was well, we don't use strict mode yet. Because some of the libraries we use don't use strict code.

[00:05:49] We load in jQuery and it doesn't use it or whatever. I mean, they all use it now. But like you used to say, well, I don't know. I use some like third party ad code and they haven't updated their code in like 15 years and they don't use strict mode, so we don't use strict mode.

[00:06:04] This is a fundamental misunderstanding of how the mechanism works. As a matter of fact, it's a fundamental misunderstanding of how JavaScript itself works. JavaScript programs are file based. You have an application you ship in production. Most of you probably work on web apps. Most of you have probably built an application that has anywhere from a few to a dozen, maybe a couple hundred JavaScript files in it and you think of that as one program.

[00:06:33] That's not how JavaScript thinks of it. Every single file is in a completely separate program. Now, what they do share is they all share the global scope. So, that's good. That makes it easy for us to combine multiple programs into one application. But from the perspective of JavaScript and rules that it applies, if I put use strict at the top of this file and then I load in a whole separate file with a whole separate set of code and that file does not have a use strict directive in it, that code is not subject to strict mode regulations.

[00:07:07] Only the code that I actually put the use strict in. So if your application has some files that can be strict mode and some that can't, stop worrying about the ones that can't. Just focus on the ones that can. The only time this is really a problem is when you do something silly like take somebody else's code arbitrarily and concatenate it with your code.

[00:07:31] That is a terrible idea for a whole bunch of reasons not the least of which is, you're now asking that code to run in the strict mode of your file and that may not work. So, do not under any circumstances. And if you're doing it now, go home and change it tonight.

[00:07:48] Do not bundle somebody else's untrusted code with your trusted code. That is never a good idea for security reasons, for caching reasons, for performance reasons. That is just never a good idea. At a minimum, you should have a bundle of untrusted stuff that comes from other people and a bundle of trusted stuff that you wrote.

[00:08:07] Keep those two separate. And the stuff that you wrote, you should be fully in control with whether or not that's strict mode. If you have stuff that is not strict mode yet, don't concatenate into that bundle. Come up with a third bundle, for example. The other thing to know about strict mode is that it's not all or nothing.

[00:08:28] I've put it at the top of this file, which means apply it to the entire contents of the file. But if for some reason there was some functions in this code which could not do that and others could, I could do the use strict on a function by function basis.

[00:08:44] So, I could start out by going and putting that you strict in every single function in my file. And then if there was a problem if I exposed an error or a bug or I broke something, I could either go fix it, which is what I ought to do.

[00:08:57] Or at a minimum, just take out that used strict for that one offending functions, leaving it in all the other places where it works fine. Preventing me from doing stupid stuff like implicitly creating globals or repeating parameter names, or other things like that. So you can go on a function by function basis and you should fix those problems rather than cover them up or ignore them, but you can do that little by little.

[00:09:21] And eventually, someday every function in your file will have the use strict in it and there won't be any bugs and then guess what? Just go take all the use stricts out of the functions and put it up at the top. Problem solved. So the second myth is that you don't have to adopt strict mode all or nothing, but I repeat my earlier admonition.

[00:09:42] What are you waiting for? This is the future of the langue and this is the way we should be writing code. Get into that habit of starting every file and I still have to force myself to remember, but they use strict at the top of every file. There is maybe some day in the future and I'm really hoping for it where we don't have to opt into strict mode.

[00:10:00] We have to opt out of strict mode. I hope that day comes. But right now, you're gonna have to get into that habit. If you're already using a trans filer like babble or something, it's already putting your code into strict mode. So, you're good. But if you're not doing that, go and put strict mode into all your programs.