But if you wanted to, you could verify the authenticity of the code. If you're just sending plaintext off into the void, then you have zero control whatsoever. You could also open up Wireshark to verify your plaintext isn't being transmitted anywhere.
How exactly are you verifying the authenticity of the code? By looking at the Javascript code? Even if you're among the 0.0000000% of users who could look at JS AES and know if it's backdoored, how do you know if any of the Javascript functions it's calling have been backdoored? Similarly: what does it matter if you can see plaintext on the wire? The attacker siphoning off your data can re-encrypt it for themselves. You helpfully provided them a library to do exactly that.
When was the last time you checked whether your compiler wasn't producing backdoored code? How about those chips on your motherboard? Perhaps an instruction or two are being executed without your consent?
You are just being paranoid at this point.
Like someone mentioned, using this to encrypt state secrets? Stupid idea. Using it to provide some level of trust that the server never sees the plaintext data? Pretty reasonable.
Why are you protecting against the server never seeing plaintext data? In case the server is compromised? If the server is compromised, then so is your JS!
The difference between traditional compilers, chips on motherboards, and so on and so forth, are that you aren't downloading and using a fresh copy every time.
If it were possible to securely store some JavaScript in your browser (trust-on-first-use), or otherwise verify that the JS hadn't changed since the last time you used it, and if that JS weren't accessible from the DOM, and if that JS were well-written and used standard practices and had been reviewed by cryptographers, then maybe it would be OK to use.
