Oh you mean the client sends 3 hashes and backend validates if just one matches?
EDIT: Oh right, salts.
Salting is more about making it non-obvious which passwords map to which hashes so you can’t easily build tables of hashes for common passwords.
Sending the password to the server in “plain text” is fine over https, it’s a secure channel. Hashing isn’t meant to hide the password on the wire, it’s to prevent anyone with access to the database from learning what the passwords are.
I feel like if the client always hash passwords as soon as it is typed (the javascript never sees the unhashed password), no one would notice. (except some with crazy password rules that would disallow a hash-looking password)
SRP is one such system: https://en.m.wikipedia.org/wiki/Secure_Remote_Password_proto...
This often isn't considered worth the accessibility and maintenance costs of requiring the user to compute a hash (the threat model isn't exactly hugely concerning, especially to service providers, and is mostly obviated by transport encryption anyway) or the risk that somebody's going to come along and ask why we're hashing twice and rip out the server hash (very bad), but calling that "no benefits" is more or less lies-to-children.