Thomas Pornin has already answered your question accurately, but I'd like to add a strong warning to the discussion.
You should probably not be computing password hashes client-side.
In the most naïve approach, completely eliminates most of the value in password hashing. By computing hashes on the client and simply comparing their equivalence server-side, you are now effectively storing the "password" used to log in directly on the server. This will allow anyone who gains read access to the hashes table to impersonate any user.
Again in a naïve approach, with simple string comparison, you now open yourself up to timing attacks. Standard language string comparison operators short-circuit their evaluation at the first differing character. This is great for performance but bad for cryptography, since a malicious user can use this leaked timing information to iteratively "guess" the password. Recent work has shown that this type of attack is viable, even over typically internet latencies.
Third, in the event that this is for authentication to a website, this means you'll be using crypto in the browser, which is still a very long ways from being able to ensure security assurances we take for granted when doing local computation.
That said, there are ways of constructing protocols that allow for client-side computation of password hashes for server relief. The new Catena password hashing candidate has this concept built in, although it hasn't yet been thoroughly vetted by the cryptographic community. SRP, as mentioned by Thomas, is another example. However, it's not something that one who is not intimately familiar with cryptography should be attempting on their own, as (with most things in cryptography) there are many pitfalls and traps for a novice to unknowingly overlook.