Ideally, we should do most (but not all !) of the hashing on the client side.
The overall need for password hashing, with all the involved iterations and salts (see this answer), is to make sure that the value which is stored (the "password verification token") cannot easily be used for an offline dictionary attack (the attacker tries potential password, until one which matches the stored value is found). For that specific functionality to be fulfilled, it suffices that the slow-and-salted password hashing occurs "somewhere", and the client machine is a reasonable place for that.
However, protection against offline dictionary attacks is only one part of the security goal. In particular, we do not want an attacker to be able to obtain "password-equivalent" values. If you do the complete hashing client-side, and store the value "as is" on the server, then a glimpse on the server's database (as happens all too often with SQL injections and lost backup tapes) will reveal the hash values and allow the attacker to log in as any user immediately. Thus, you still want to do some hashing server side.
What works, for instance, is to have the slow-and-salted hash on the client, resulting in a value V, and the server stores SHA-256(V). Since the slow-and-salted hash has been done, the protection against dictionary attacks is there; and since the server does not store V but still requires the client to send V to be granted access, read-only breaches are not trivially escalated into full read-write compromise.
Client-side hashing has the very interesting feature of using client-side resources, not server-side, thus allowing a given server to process many concurrent clients without running out of CPU, while still having an overall slow-and-salted password hashing. However, this is not often done in practice because of some drawbacks:
The client cannot hash without knowing the salt, which is stored on the server. The protocol thus implies an extra roundtrip: the client must send the username, the server responds with the salt, and then (only then) can the client do the slow-and-salted hash.
Client-side hashing means client-side code, which may not be easily upgraded or modified. With server-side hashing, the hash function choice is entirely up to the server and can be switched without having to alter installed clients in any way.
Some servers like to have access to cleartext passwords occasionally, not for storage, but for other features such as automatically detecting very poor user passwords, or sending a copy of the passwords to the relevant Law enforcement authorities (where applicable -- I am not saying that this is good or bad, but when it applies, it is not subject to a choice by whoever designs the login system; if you are in a country where you must allow governmental agencies to peek at passwords, then, well, you must, so this becomes an element of the context to be dealt with).