Hashing on the server and hashing on the client mitigate different attacks, and so one must consider which attacks one needs to protect against.
Server side hashing
Hashing on the server mitigates the compromise of the stored passwords (e.g. database leak). If passwords are not hashed here a successful attacker would have immediate access to the credentials, thereby allowing them to access the server. By storing hashed passwords the attacker is forced to spend additional effort in order to retrieve the actual credentials.
Client side hashing
Hashing on the client mitigates attacks on the channel between the client and the server, as well as on the server components which process the raw credentials (log in component, password set and change component). By hashing the password on the client the attacker is forced to spend additional effort in order to retrieve the actual password. Note however that this hash is a plaintext-equivalent -- if an attacker captures the hash they can use it to authenticate to the server.
The value here is in protecting the password which the user entered, since most users use the same password for other services. While capturing the plaintext-equivalent would compromise the user's account on your service, it would not compromise the user's accounts on other services. Obviously if all services used this scheme the same hash would be a plaintext-equivalent for other sites, and so a salt unique to one's service should be added here.
So what should one do?
The first class of attacks definitely must be protected against, since database leaks do happen, and so server side hashing is a must. The second class of attacks are largely mitigated by the use of TLS, and so the extra effort to use client side hashing is usually not worth it.
As others have said, the use of MD5 and SHA1 are strongly discouraged. The SHA2 family of hashes are in themselves secure, but not alone appropriate for password hashing because they are designed to be fast. Passwords should be hashed with a scheme specifically designed for password hashing, such as bcrypt, scrypt or PBKDF2. If one of these schemes is really not an option, the password must be salted and iteratively hashed with a SHA2 hash.
There are schemes such as SRP which don't store the password or plaintext-equivalent on the server, nor transmit the password or plaintext-equivalent between the client and server.