Salts need to be globally unique
Although this may not apply to your case, there are good reasons why salts cannot just be derived from a username or other constant data about the user.
Consider a user Alice who using the same password on multiple sites, both of which use her username as the salt. This will lead to the same hash appearing in both. Using a combination of the username and the site itself for the salt should address that specific concern.
As others have pointed out, your salt is in the wrong format. You could perform a hash of the email address and site name and then truncate that hash to 16 bytes.
Server side hashing is still required
There are some things that client side hashing offers, but it can never (well, hardly ever) be a replacement for server side hashing. And unless coupled with some other useful constructions, client side hashing really doesn't offer much at all. Mostly it helps save the server some work.
There is also a sort of pass the hash mentality here. The hash that the client sends is a secret. If it is captured (say in transit) it can be used by an attacker to log in to the service just as knowledge of the source password would. So just because the hash doesn't look like a secret (while the source password does), it is an authentication proof.
I'm not saying that client side hashing is of no use, but it is of much less use that people expect under most circumstances.