What is "x && foo()"?

Both AND and OR operators can shortcut.

So && only tries the second expression if the first is true (truth-like, more specifically). The fact that the second operation does stuff (whatever the contents of foo() does) doesn't matter because it's not executed unless that first expression evaluates to something truthy. If it is truthy, it then will be executed in order to try the second test.

Conversely, if the first expression in an || statement is true, the second doesn't get touched. This is done because the whole statement can already be evaluated, the statement will result in true regardless of the outcome of the second expression, so it will be ignored and remain unexecuted.

The cases to watch out for when using shortcuts like this, of course, are the cases with operators where defined variables still evaluate to falsy values (e.g. 0), and truthy ones (e.g. 'zero').

This is known as short-circuit evaluation.

In this case, if x is False, then foo() doesn't need to be evaluated (the result of && will always be False); if x is True, it does need to be evaluated (even if the result is thrown away).

It's not exactly equivalent. The first one is an expression with a return value you can use; the second one is a statement.

If you are not interested in the return value (that is, the information whether both x and foo() evaluate to a truthy value), they are equivalent, but normally, you should use the boolean-logic version only if you want to use it as a boolean expression, e.g.:

if (x && foo()) {    do_stuff();}

If you are only interested in running foo() conditionally (when x is truthy), the second form is to be preferred, since it conveys the intention more clearly.

A reason people might prefer the boolean-logic version might be that javascript is subject to an unusual restriction: source code size (more verbose source code means more bandwidth used); since the boolean-logic version uses less characters, it is more bandwidth-efficient. I'd still prefer the more verbose version most of the time, unless the script in question is used a lot - for a library like jQuery, using optimizations like this is perfectly justifyable, but in most other cases it's not.