#Things to consider

  • In JavaScript, variables don’t have types — values have types. Variables can hold any value, at any time.
  • It’s tempting for most developers to think of the word undefined as a synonym for undeclared. However, in JS, these two concepts are quite different.
  • JavaScript has seven built-in types: null, undefined, boolean, number, string, object, and symbol.
  • Variables don’t have types, but the values in them do. These types define the intrinsic behavior of the values.
  • null is an empty value. undefined is a missing value.
  • By convention (mostly from C-language programming), to represent the undefined value standalone by using void, you’d use void 0 (though clearly even void true or any other void expression does the same thing). There’s no practical difference between void 0, void 1, and undefined.
  • NaN is the only value in the whole language where that’s true; every other value is always equal to itself.
  • Simple values (aka scalar primitives) are always assigned/passed by value-copy: null, undefined, string, number, boolean, and ES6’s symbol.
  • Compound values — objects (including arrays, and all boxed object wrappers — see Chapter 3) and functions — always create a copy of the reference on assignment or passing.
  • An array with at least one “empty slot” in it is often called a “sparse array.”
  • Each of the built-in native constructors has its own .prototype object  —  Array.prototype, String.prototype, etc.
  • Parsing should not be seen as a substitute for coercion. These two tasks, while similar, have different purposes. Parse a string as a number when you don’t know/care what other non-numeric characters there may be on the right-hand side. Coerce a string (to a number) when the only acceptable values are numeric and something like “42px” should be rejected as a number.
  • If you pass in garbage, and you get garbage back out, don’t blame the trash can — it just did its job faithfully.
  • There’s another idiom that is quite a bit less commonly authored manually, but which is used by JS minifiers frequently. The && operator “selects” the second operand if and only if the first operand tests as truthy, and this usage is sometimes called the “guard operator” (see also “Short Circuited” in Chapter 5)—the first expression test “guards” the second expression: function foo() { console.log( a ); } var a = 42; a && foo(); // 42 foo() gets called only because a tests as truthy. If that test failed, this a && foo() expression statement would just silently stop (sometimes called “short circuiting”) and never call foo().
  • JavaScript is not bad because you can do such things, a developer is bad if they do such things. Don’t fall into the “my programming language should protect me from myself” fallacy.
  • The question of == versus === is really appropriately framed as: should you allow coercion for a comparison or not?
  • The b = a assignment expression results in the value that was assigned (18 above), but the var statement itself results in undefined. Why? Because var statements are defined that way in the spec. If you put var a = 42; into your console, you’ll see undefined reported back instead of 42.
  • The ++ increment operator and the — decrement operator are both unary operators (see Chapter 4), which can be used in either a postfix (“after”) position or prefix (“before”) position:
  • So, JSON is truly a subset of JS syntax, but JSON is not valid JS grammar by itself.
  • If you knew it well, the above examples wouldn’t have tripped you up in the slightest, because you’d already know that && is more precedent than. But I bet a fair amount of readers had to think about it a little bit.
  • Statements and expressions have analogs in English language — statements are like sentences and expressions are like phrases. Expressions can be pure/self-contained, or they can have side effects.