Just running HTTPS is way preferable to implementing your own HTTPS in JavaScript.
But, of course, the larger problem is the password itself. No matter how you spin it with hashing or whatnot, a password is still a shared secret. You need to communicate a secret to the other party so they can verify it. You can almost hear how flawed a technology it is from the description, and I'm honestly surprised it has been allowed to exist for so long.
There are lots of challenge-response protocols that prove knowledge of a secret without communicating it. A simple example would be that the verifier could ask for the HMAC of the shared secret under a randomly-generated HMAC key. The prover can reply with the correct HMAC, but neither the verifier nor an eavesdropper would be able to reconstruct the shared secret from this reply without previously knowing the secret.
https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
but it's not what's commonly used in website authentication.
In this case the attacker might have also been doing SSL stripping, which (1) would typically work even if it were an HTTPS site, but not if it had HSTS or an HSTS preload; (2) would also allow him to change the site's user interface so that it asked for or received information in a different way from usual. So even if a site didn't normally solicit or transmit some specific kind of information, the tampered-with version might do so, assuming the attacker had thought to prepare a modified version of that particular site.