Inconsistently Insightful

Just because an operator or statement needs a boolean value does not mean that it converts the value to a boolean. Instead, it merely interprets the value in a boolean way according to the rules . That's an especially important distinction when dealing with the two short-circuit pseudo-boolean operators, && and || . Let's look at && first, using this example: var boys = { Manny: 1, Moe: 2, Jack: 3 }; var str = ""; for ( var pep in boys) str += (str && " ") + pep; alert(str); This code takes the names of the properties in the PepBoys object and joins them into a single string separated by spaces. But what's going on with the && operator? The first time through the loop, str is an empty string which is false in Javascript's book. Since && is a short-circuit operator, the second operand of a space doesn't come into play. However, instead of returning false , it returns the actual value of str --the

Earlier, I mentioned that you never need new Boolean to create a boolean value. That's because Javascript rarely needs boolean values at all; it will gladly make boolean decisions based on any type of variable--numbers, strings, even objects! When used in a context that needs a boolean value, Javascript considers these values--and only these values--to be false : false (the boolean kind) 0 (numeric zero) null (the null value) undefined (the undefined value) NaN (the not-a-number value) "" (an empty string) Anything else is considered to be a true value. Anything. Really. Memorize the entire set of potentially false values, it will make your Javascript better. Be careful, Javascript will not automagically convert values from another type when it evaluates their booleanosity. String values of "0" , "false" , or "null" evaluate to true . In contrast, an expression like parseInt("0") returns numeric zero and evaluat

The best way to get going with any language is to start with some existing code; tweak it, extend it, rewrite it, and break it. It's good to have some background information for that effort though, which is where Javascript references come in handy. If you want just the facts without third-party interpretations, go directly to the ECMA 262 (EcmaScript) standard . Like many standards documents, though, it can be very dense for a programmer. ECMA 262 is written as though the reader's job is to implement a Javascript compiler, which means you can count its primary audience using just your fingers. Although ECMA 262 serves as the Supreme Court for correct Javascript behavior, you're better off going to a lower court for intelligible opinions. By far, my favorite dead-tree book on Javascript is O'Reilly's Javascript: The Definitive Guide . It includes a thorough overview of language features, plus a comprehensive reference section for Javascript functions and objects. Ev

I've spent a lot of the past decade writing Javascript. The language was rough at first--just like the browsers that implemented it--but over time it's evolved into an incredible environment. I particularly like the way it filched features from Perl, another language that I happen to like. If I had to reduce my Javascript programming philosophy to three words, I'd choose the title of Paul Graham's essay, "Succinctness is Power" . Every profession--medical, legal, engineering, programming--has shorthand incantations that save time and reduce ambiguity. As outsiders, we look at another profession's shorthand with disdain and confusion. Some of the methods I advocate here will probably trigger objections along the lines of "That's not clear enough, it's better to spell it out so everyone understands what you're doing." I say that it's worth learning the shorthand of Javascript, it will serve you well in the long run. Mainly, I've