Yeah. The ability of Javascript to underpin a cryptographic system isn't a question. For some systems, where the code will never be transmitted to an executing system, no problems.
It's the transit that presents a vulnerability. If the cryptosystem can be intercepted and modified enroute to the host that will execute it, it cannot be considered secure. If the cryptosystem is delivered as part of an embedded system, it's more likely it can be considered secure.
edit: I'll add a caveat to the cannot. It's more reasonable to consider it secure if it sends a hashed checksum of itself to a server, using itself to generate the hash and it sends a copy of itself to the server to generate the hash. If the hashes match, it's quite likely good to go. The total transmission required for this style of code authentication is worth consideration.
How would you know it sent the hash to the server? It would have to tell you, and if it were undermined, they would just say, "Yep, hash checks out!" You'd really need a browser extension or something installed locally that checks the code for you, in which case you might as well just install something that does proper end-to-end encryption anyway.
What about it hashes itself, sends the hash to the server through a tunnel generated by the questionable cryptosystem. If that checks out, the server sends back a more robust cryptosystem through the questionable tunnel.
But Then we're right back where we started. Is that questionable tunnel weak enough to be considered vulnerable?
End-to-end is more easily checked for security.
To me, Javascript's good for an embedded system, no doubt about the possibility of a cryptosystem being implementable, but, it's difficult to consider it secure for many use cases.
It's the transit that presents a vulnerability. If the cryptosystem can be intercepted and modified enroute to the host that will execute it, it cannot be considered secure. If the cryptosystem is delivered as part of an embedded system, it's more likely it can be considered secure.
edit: I'll add a caveat to the cannot. It's more reasonable to consider it secure if it sends a hashed checksum of itself to a server, using itself to generate the hash and it sends a copy of itself to the server to generate the hash. If the hashes match, it's quite likely good to go. The total transmission required for this style of code authentication is worth consideration.