The following quote is derived from an expert recommended book that covers the many aspects of Ajax. It’s called “Ajax in Action”, authored by Dave Crane, Eric Pascarello, and Darren James.

“The JavaScript Object Notation (JSON) is a core feature of the language [JavaScript]. It provides a concise mechanism for creating arrays and object graphs. In order to understand JSON, we need to know how JavaScript arrays work [...]”

Hopefully you’ve spotted the dodgy parts of that quote. For one, JSON, the data-interchange format is not actually a core feature of JavaScript and is, in more ways that one, quite different to JavaScript’s object notation (i.e. the way you markup an object literal in JavaScript code).

Despite my dismay I continued to read onwards, and I can tell you that the author has also made the classic mistake of thinking that JavaScript supports associative arrays, and for some reason thinks that you have to understand JavaScript arrays in order to understand JSON… (???)

So, just to set the record straight, JSON is an interchange format created/coined by Doug Crockford. It’s a subset of JavaScript’s object notation (specified in the ECMA-262 specification). To prove this, here’s a valid JavaScript object literal:

{
    foo: 123,
    bar: 456
}

Yes, I know, on its own it’s not valid JavaScript (since it’s interpreted as a compound statement), but that doesn’t matter; it is a valid object literal.

Run that through a JSON validator and you’ll get errors. That’s because JSON is not the same as JavaScript’s object notation. To make the above code a valid piece of JSON you’d have to wrap each property name (e.g. foo) with double quotes:

{
    "foo": 123,
    "bar": 456
}

I don’t blame the author of that book. In all likelihood, the information within that book was thought of as 100% correct at the time of writing. I only wanted to set-straight one of many misconceptions surrounding JavaScript and its “subsets”.

PS. Please forgive the confusing title.

I can’t speak for other languages but one of the best things about JavaScript, in my opinion, is the fact that almost everything can be considered as an expression. An expression makes up part of a “statement” and is evaluated to produce a value. Every expression has a “return” value. Consider this:

42

Yup, the number 42 happens to be an expression. This expression is evaluated as the literal number, 42. You can create more complex expressions by using operators. An operator (e.g. the assignment operator, =) expects a number of “operands”.

An “operand” can be thought of as an operator’s argument. For example, what we all know as the “ternary operator” (x?y:z – actually called the “conditional operator”) takes three operands, hence the name “ternary”. It’s the only operator in JavaScript that takes three operands. The assignment operator (=), for example, takes two operands – one on the left and one on the right.

Operators and their corresponding operands can be combined to create interesting and useful expressions. Expressions, as the name suggests, allow you to “express” a piece of logic concisely and efficiently. Much of the logic expressible in a series of if/else statements can also be expressed in a tiny expression.

Precedence & Associativity

Consider the following expression:

+new Date()

There are two operators; the unary plus operator (+) and the new operator. What would you expect this expression to do? Would you expect the + operator to convert the new operator to its numerical form? Would you expect a syntax error to be thrown? Nope? Then what?

The + operator actually “waits” until the new operator resolves its operand; then the + acts on the returned object. So, +new Date() is fundamentally the same as +(new Date()). The order in which operators run is defined by each operator’s “precedence”. The new operator has a higher precedence than the unary plus operator so it’s evaluated first.

Here’s another example:

x = y || z;

The logical OR operator (||) expects two operands, one on the right and one on the left – if the one on the left evaluates to true then it’s returned (z never gets a chance to evaluate). If, however, the one on the left is false then the one on the right is evaluated and returned from the expression. The return value of y || z is assigned to x – this is what you’d expect – but underneath the surface it’s the precedence of each operator in the expresson that defines what happens.