Even so, making the assertion that:

"javascript adoption in the browser will increase in future, therefore we will enforce javascript"

is like saying:

"more people will have passports in future, therefore we require passports to get a bus pass".

By doing that; you make it true.

It's already true. You can quibble over who's fault it was, but it really doesn't matter at this point. The web serves code that users run. That's because the web is the best distribution medium for code we've ever seen.

I bet you've also installed client side applications that came from the web, on a vendor installed OS that came from the web, and drivers for your machine that came from the web.

You're equating my signed/sealed/delivered package management to javascript??

??

??????

Really? You honestly don't see a difference? I have a chain of trust with my OS manufacturer (apple) and a defecto trust with a centralised entity for most of my applications (IE; my company for things that we build, or the home-brew project for most other packages)

I should not have that trust with any idiot who manages to get a signed SSL certificate; IE: the whole internet.

You mean like the signed/sealed/delivered csp policies that browsers have supported for years?

https://developers.google.com/web/fundamentals/security/csp/

To quote the signature section:

'<hash-algorithm>-<base64-value>'

A sha256, sha384 or sha512 hash of scripts or styles. The use of this source consists of two portions separated by a dash: the encryption algorithm used to create the hash and the base64-encoded hash of the script or style. When generating the hash, don't include the <script> or <style> tags and note that capitalization and whitespace matter, including leading or trailing whitespace. See unsafe inline script for an example. In CSP 2.0 this applied only to inline scripts. CSP 3.0 allows it in the case of script-src for external scripts.