I've read the Matasano whitepaper on why you can't count on Javascript for security, as I imagine you have, and it makes sense. Use https.

That being said, look at something like blockchain.info.

It adds javascript security on top of https, and for (what seems like) excellent reasons.

I was just musing hypothetically, but can you elaborate on why this is bad? Surely sending an encoded password is better than a non-encoded one, and in a worst case only as bad as sending a cleartext password (i.e. what happens now).

I don't think I was proposing not using TLS, just that if you interpret sending cleartext password over TLS as "plain-text" then sending it encoded over TLS sounds better.

In theory, you could use something like MD5 auth, but really there's not much point.

It's a good idea IMO, I don't understand why it gets so much flak. A server who doesn't want to know your secret is more trustworthy than one that does, a MITM might be able to hijack your account but he won't see your favourite password and you don't have to trust that the server is hashing the password at their end.

To avoid the "hash is a plaintext password" problem you save double-hashed passwords to your database, once in the browser and once on the back-end, twice on the back-end if JavaScript was disabled in your user-agent.

Of course that doesn't solve the problem above, but it still ought to be common practice.