No, it doesn't. JS implementations suffer from all the same flaws that everything else does, plus a few more, and it offers no protection from any flaws that anything else is vulnerable to.

"You can never be completely secure" is not a good justification for security theatre.

Well not really, because if you can verify the scripts that are loaded (and side-loading JavaScript would have to be a targeted attack that compromised either the server, or the Google API, or a malicious extension), then it guarantees end-to-end encryption for the user as opposed to having to send plaintext over the wire.

How exactly would you implement a browser based crypto solution?

Preferably:

That, plus a notification to the user if the signed JS has changed since the last time it was loaded, with SHA hashes of the scripts (and other data) stored directly in the browser in a way not accessible from the DOM.

Since in-page scripts could still on-the-fly rewrite the functions of loaded JS, they would have to be provided read-only by the browser, or there would have to be some kind of out-of-DOM API for working with them.

My hope would be that we'd see a handful of signed libraries provided and reviewed by cryptographers and that they wouldn't change very often because it would be a pain in the ass when they did.

But: I am not a cryptographer or even a qualified security expert. There is probably a good reason not to do it this way.

That would be pretty fantastic as an extension that could provide essentially allow for "signed" Javascript.