Strict Mode

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Douglas Crockford: We added a strict mode to the language because there are a lot of things in the language that were clearly wrong that we wanted to repair. But they would be breaking changes. And so we needed to have some kind of opt in, so you'd say yes, I'm prepared for the breakage this might cause.

[00:00:21]
Because I want to be using the better language. The difficulty we had in specifying this was, how do you say I want strict mode without introducing new syntax? Because we wanted older browsers to simply ignore the fact that we're in strict mode and work the way they always have.

[00:00:40]
So we spent a lot of time trying to figure out how to do that, and eventually, we came up with a terrible hack. We used the useless expression statement that I was complaining about earlier to specify the pragma. So if the first statement of a function or a file is the string, use strict ;, that puts that file or that function into strict mode.

[00:01:07]
And on older browsers, it's simply ignored and does nothing, so that works out. We've got the file form, which is good if you're on Node. If you're on a browser, I recommend you only use the function form.
>> Douglas Crockford: The reason for that is Steve Souders will tell you to concatenate all of your files together.

[00:01:29]
And that means that all of your files will have the same strictness as the first file, and that could be bad in any number of ways. So in browsers, we recommend you only use the function form. Strict mode adds a number of new reserved words. So far, I'm only aware of let and yield being used in the next edition of the language.

[00:01:55]
The others may or may not be used in other editions. This is the list of things that are provided by strict mode. Unfortunately, it's a boring list. So I'm just gonna read the boring list. There are no more implied global variables within functions. This was a huge design error in JavaScript.

[00:02:13]
So now if you forget to declare a variable in a function, it's gonna be a syntax error. It's not going to default to global variables. So that's good. This is no longer bound to the global object by the function form. So if you call a method as a function, this will get bound to undefined and not the global object.

[00:02:35]
That turned out to be really important for security. The call and apply methods no longer default to the global object. So it used to be if you called the apply method and passed in null or undefined, meaning you don't want this to get bound to anything, JavaScript will go, you can't mean that, you probably mean the global object and would do that substitution.

[00:02:57]
It doesn't do that anymore. We got rid of the with statement. If you try to assign to something which is not writeable, you will now throw an exception. It used to fail silently, which is really bad for integrity. Because the code may have made a change, assuming that it succeeded in making the change, and if the change failed and it isn't notified, then it could become inconsistent.

[00:03:22]
We did a similar thing with deleting non-configurable properties. We put restrictions on eval. I haven't talked at all this week about eval, and I'm not going to. Eval is the most misused feature of the language, and I don't recommend using it. And the implementation of it in the old language was really quite horrible, that it gave extreme powers to whoever provided a string to it.

[00:03:48]
And so we put some limits on eval. The thing I complained about with arguments getting bound strangely to the parameters, that's been fixed. We got rid of arguments.caller and arguments.callee. And getting rid of those was surprisingly difficult because arguments.caller had never been in the standard. So we couldn't simply go to a line of the standard and delete it.

[00:04:12]
Instead, we had to add caller to the language and then poison it. We got rid of octal literals because we found that they are confusing to humans. Most people in school learned that a leading zero in front of a number is not significant. But JavaScript said it was and turned you into base eight.

[00:04:32]
So we fixed that, and that got us a lot of complaints from the Node community. Apparently that the Node guys are still using octal literals for setting file permissions. I didn't know anybody was still doing that, but they are. So yes, 6 added octal back in, but in a slightly less awful way.

[00:04:51]
And then duplicate names in an object literal or function parameters are now syntax error. So, if you say function food a comma a, it will now recognize that the second a is an error. We fixed the new operator, so forgetting to use the new prefix in strict mode will now throw an exception and not silently clobber global variables.

[00:05:15]
So that's good. There are a few things that we know did break because of strict mode. For example, if you call addEventListener in a browser intending to add an event to the window object, that accidentally worked in the old language. And the reason it accidentally worked was in the browser, the window object is the global object.

[00:05:42]
They just happen to be the same thing. And when you call a function as a function, this gets bound to the global object, which happens to be the window object, so it worked. It was never intended to work, it just accidentally worked. So now in strict mode, you have to be explicit.

[00:05:58]
If you want to add an event listener to the window, you have to say window dot. There is nothing in the language that will tell you if you are in strict mode or if strict mode is available, but you can write either of these little functions, and they will tell you exactly what you need to know.

[00:06:19]
The design of strict mode was informed by JSLint, they're not entirely the same because JSLint has forced to do a static analysis and strict mode can do some things dynamically. But if you're using JSLint, and you should, then you should be very happy with strict mode. A lot of the work that we did was motivated by the problems of mashups.

[00:06:40]
A mashup is where you've got code representing two parties that wants to work together in the same page for the benefit of the user without one being able to corrupt the other, and that turns out to be a very difficult problem. So we don't have a complete solution to that, but we are on the road to solving that.

[00:07:01]
So the design of the mashup solutions that we put into the language were derived from Google's Caja project and my own ADsafe project. And by fixing things, like the binding of this and some of the other problems, we can now get security solutions, which provide all the benefits of both of these, which should be a good thing.

[00:07:29]
So any questions about any of the stuff about ES5? Or anything about anything today, or anything at all?
>> Douglas Crockford: Just in the discussion, we're all talking about ES6 and stuff like that, but. We'll get to ES6 on the third day.
>> Speaker 2: Yeah, that's what the, yeah. You had that in the schedule, so.

[00:07:49]
>> Douglas Crockford: Okay, anybody else?
>> Speaker 3: When you talked about how pervasive certain constructs are out in the web and figure out how much it break and stuff like that, how did you gather those metrics?
>> Douglas Crockford: It's really hard, some of it was just, I think somebody did something. I heard about a guy who did something.

[00:08:09]
A lot of it was that, some of it was mining Google code. Microsoft also had an extensive database of code, and we would mine against that. I'm not confident how effective our tools were in all cases because some of the patterns we're looking for are really complex. And some code is so badly written that you might not necessarily be able to recognize the patterns.

[00:08:30]
But we tried as much as was possible, given the technology available to match stuff against what the web was doing.