This course has been updated! We now recommend you take the The Good Parts of JavaScript and the Web course.

Check out a free preview of the full JavaScript the Good Parts course:
The "Objects" Lesson is part of the full, JavaScript the Good Parts course featured in this preview video. Here's what you'd learn in this lesson:

Arrays and Object are often interchangeable. It’s best to use Objects when the names are arbitrary strings. Arrays are often more efficient when the names are sequential numbers. All values are objects except for null and undefined. The type of prefix operator will return a string identifying the type of a value. Use Array.isArray for Array validation.

Get Unlimited Access Now

Transcript from the "Objects" Lesson

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

[00:00:04]
>> Douglas Crockford: So because arrays and objects are actually made of the same thing in this language, there's confusion, because, in some ways, they're interchangeable, in others, they're not. So most of the time, you can use one for the other, and get away with it. But eventually, it'll catch up with you.

[00:00:23] So I recommend, use objects when the names of the properties are arbitrary strings, and use arrays when the names are sequential integers. Don't be confused by the term associative array. In JavaScript, the associative array is object, not array.
>> Douglas Crockford: JavaScript has a Date function which was modeled after Java's Date class, which was not Y2K ready.

[00:00:50] Java was published in 1995. I guess they didn't see the millennium coming. Fortunately, we survived it. Hooray. We have regular expressions, which are a pattern-matching mechanism. That is a regular expression that matches regular expressions. At least I claim it is. I hate regular expressions. This notation is so appallingly hard to read.

[00:01:16] And we use it for input validation. And how can you have any confidence that it matches what we think it matches? Cuz it's such a horrible notation. There are other languages that have pattern matching languages which are really quite elegant, and expressive, and nice. We don't have one of those.

[00:01:35] We have the industry standard. This is another thing that Ken Thompson did. Not Thompson's best idea. He had some other things that were truly brilliant. Regular expressions work really well if they're an inch or two long. If they get longer than that, they're horrible. And I have to confess, I've written regular expressions that are a couple of feet long.

[00:01:56] And I'm not proud of that. Yeah, so we have functions. Most of today, the rest of the day is gonna be about functions, but we'll get to them later. So all the values we talked about up until now are objects. There are only two values in JavaScript that are not objects, and they are null and undefined.

[00:02:21] Null is the value that isn't anything, so if you want put something in a variable just indicating that there is nothing there, you can say null. And then undefined is the value that isn't even that. Undefined is the value for variables and parameters. If you declare a variable, but don't initialize it, its default value will be undefined.

[00:02:43] Which is a little confusing, because you define it, but it's undefined at the same time. Undefined wasn't the best name for this. If you ask for a property from an object, and the object doesn't have one and does not inherit one, then it returns undefined. One thing that's confusing is that you can store undefined in an object.

[00:03:06] So if you retrieve the value undefined from an object, you don't know if it meant that property was missing, or if it meant that property had the value of undefined. So for that reason, I recommend, don't store undefined into things, because it's confusing. I think it should have caused the element to be deleted, but it doesn't do that.

[00:03:30] JavaScript has a typeof operator, which allows you to take a value and determine what type it is, and returns the string with the name of the type. So if you ask, is this an object, it returns object, and so on, which is good. If you pass an array, it returns object, which is maybe technically right, because everything is an object, but it's not helpful.

[00:03:50] It doesn't tell you that this is an array, which has different properties. But the worst one is null. The typeof null is object, which is just wrong. And the way that happened was, Brendan used typed pointers in his first implementation. So, the first few bits of a pointer would indicate what the thing was pointing to.

[00:04:15] And he used zero in that bit pattern to represent object, zero for object. But he also used zero, all zero as null, because he does that, for good or bad. And he didn't notice that that zero conflicted with that one, and so typeof was producing the wrong result, but Microsoft did.

[00:04:39] So when they reverse engineering to create JScript, they said, okay, that's it, and when they had a chance to fix it at ECMA, they said no damn it, cuz that would break programs, Microsoft is opposed to ever breaking programs, yeah, right. [LAUGH] You sound like a Microsoft developer.

[00:04:56] Yeah, so it's wrong. So it turns out it's not hard to test for null. You can just say, if null triple equal null. That does a null check. But typing for object is surprisingly hard, because you get this false positive. ES5 added Array.isArray, so we can now reliably tell if something's an array.

[00:05:21] That's good. And it turned out we also discovered a polyfill, so that we can get definition of that on ES6, and everything before ES9. JavaScript has values that are called the falsy values. These are false null, undefined, the empty string, the number zero, and NaN. Any of these values in the condition part of an if statement will cause you to take the false branch.

[00:05:48] Any other value is considered truthy, and would take the true branch. So an empty object, an empty array is truthy, the string zero is truthy, the string false is truthy. The only falsy values are false, null, undefined, empty string, zero, and NaN, okay. JavaScript is a loosely typed language, meaning that you can take any value of any type and stick it in any variable, or pass it in any position, or put it anywhere in any object.

[00:06:24] The language is not untyped. As you've seen, we have a lot of types in this language. But it's just very loose in how you can use them. Objects in this language are passed by reference. Objects are never copied. And the triple equal operator compares two values to ask, are they the same object.

[00:06:49] It doesn't ask, are they the same, are they similar values.
>> Douglas Crockford: So, A triple equal B is only true if both values point to the same object.