Join us and get access to hundreds of tutorials and a community of expert Pythonistas.

Unlock This Lesson

This lesson is for members only. Join us and get access to hundreds of tutorials and a community of expert Pythonistas.

Unlock This Lesson

Hint: You can adjust the default video playback speed in your account settings.
Hint: You can set the default subtitles language in your account settings.
Sorry! Looks like there’s an issue with video playback 🙁 This might be due to a temporary outage or because of a configuration issue with your browser. Please see our video player troubleshooting guide to resolve the issue.

Even More JavaScript Quirks

If you’re interested in exploring these quirks further, here is a resource that includes a quiz, which covers many of them at

00:00 In the previous two lessons, I ranted about JavaScript quirks. It probably says something when the section on quirks is longer than the section on syntax. In this lesson, more quirks.

00:10 It’s quirk-tastic! I’ve spoken before about the implicit typecasting in JavaScript and how it can get you in trouble. This can make comparing two values complicated.

00:22 Here are some examples. So far, so good. Typecasting makes these the same. This was so problematic that JavaScript introduced another kind of comparison operator, the triple equals (===). The triple equals compares the value and make sure that both items are of the same type. This fixes the problem.

00:45 There is also a not double equals (!==), which is the not equals of the triple equals world.

00:52 The weirdness goes deeper than just strings and numbers. You can get some strange things with arrays as well.

01:03 See? Kind of weird. Best practice is always use triple equals.

01:11 The original JavaScript didn’t have integers, it had numbers. It wasn’t until 2020, when ES11 introduced the BigInt type. Fortunately, it was adopted quickly and as of this recording has almost 90% penetration in the browser space.

01:26 If JavaScript numbers aren’t integers, what are they? Well, they’re floats. This is problematic as floats are meant for storing a huge range of numbers, but they do this at the cost of precision.

01:39 This precision problem becomes evident when dealing with certain decimal values. To be clear, this isn’t a JavaScript-specific thing. It is a float thing, and in almost all languages. That being said, though, almost all languages give you a way to opt out of the use of float.

01:55 Prior to BigInt, you had no other choice in JavaScript. Precision isn’t the only problem. There is also a numeric ceiling.

02:07 If you’re dealing with large numbers, you may get unexpected behavior. The introduction of BigInt solves this problem. JavaScript has built-in the suffix n to indicate that a number is a primitive type BigInt.

02:28 A BigInt is much larger than the biggest integer for a number. The ceiling problem from before has been lifted. Without the n on 42, the typeof is 'number'.

02:40 With the n, it’s typeof 'bigint'. And of course, there’s also the BigInt object, which will always be typeof 'object' because it’s a reference type.

02:52 I know you think you’ve seen function signatures in JavaScript, but they’re not really there, at least not in the way they are in Python. I briefly touched on this in a previous lesson when showing you default arguments.

03:04 The parameters in the declaration are a shortcut to make it easier to get at what was passed in, but they don’t change the execution. They’re there to make your life easier, that’s it. There’s a neat feature, which I haven’t shown you, though, which is the arguments variable, which you can get at to see all of the arguments passed in.

03:23 Let me open up a Node session and demonstrate all of these things. First, let me define a function.

03:35 This function returns a Boolean version of whatever was passed in. In the return statement, I’m using the NOT operator twice. In JavaScript, like most C languages, the exclamation point (!), or bang, is the NOT operator. Using it twice like this is a shortcut to convert a value to Boolean.

03:55 The first time you NOT something will convert it to Boolean and negate it. The second time you NOT something will invert it. And of course, if you’re inverting the negated thing, you get a Boolean of the same value as the thing passed in. Now let me call it.

04:13 This shows that JavaScript considers 1 to be equivalent to True. That’s great and everything, but I believe I was talking about arguments.

04:20 Let’s send all sorts of random stuff to truthy().

04:27 In Python, this would create an error. JavaScript sees the 42, which is a number greater than 0, which it considers True, and then ignores all the other arguments.

04:37 Change 42 to 0,

04:42 and you get False back. Same explanation as before, except this time I’m getting the truthiness of 0, which is False.

04:51 Calling the function without arguments will result in an undefined expression. undefined converts to False. Like many examples before where you’d get an error in other languages, JavaScript just keeps on trucking. Now a quick demo of the arguments value.

05:13 The contents of arguments is an array-like thing containing the arguments to the function. Using the triple dot rest operator (...) destructures arguments inside of the array.

05:24 I can then run the .reduce() function on the resulting array and sum up its contents.

05:31 Look at that! Math. You may have heard me use the phrase “array-like” when I spoke of the arguments value. I did that on purpose. It isn’t an array. It is iterable, and as you’ve seen here, it can be restructured. But unlike an Array object, it doesn’t support .forEach() or .reduce() or any of the other Array methods.

05:52 This is why it had to be destructured into an array before calling .reduce() in the sum() function. I guess that’s a bit of a quirk inside of a quirk.

06:01 It’s moving past quirk-tastic and into quirk-errific territory here.

06:07 What’s better than one nothing? Well, two nothings of course! JavaScript has two equivalents to Python’s None value: null and undefined.

06:17 Variables that have been defined but not set to a value are set to undefined. You can assign undefined to a variable or you can also assign null to a variable.

06:29 The difference is subtle. Because JavaScript isn’t finicky about the arguments to functions, you may need a way to distinguish between “I want this empty” and “I forgot to send something in.” To indicate to a function that you want an optional parameter to be empty, you can send in null. If you send undefined instead, you’d have no way of distinguishing between that case and the argument being left off altogether. With default arguments available in ES6, the importance of null is waning.

07:02 Next up, a quirk so complicated it gets its own lesson: the calling context of functions and this.

Become a Member to join the conversation.