Mr Crockford has done a lot for the JS world, but I think he's on the wrong track. The best thing we should be doing is focusing on building a best-of-breed VM replacement in WebAssembly where the language is disconnected from the page itself.
Build infrastructure and the right languages will come. Build another language, and we'll end up building a second Javascript.
There was NaCl, PNaCl by google. Didn't fly though, i think because there was no fallback possible. Near-native performance (within 10% margin), any concurrency you can think of. Played Bastion game in browser on crappy old macbook Air many many years ago
PNaCl was a terrible, terrible hack on top of LLVM's intermediate representation. The only good thing that came of it was paving the way for WebAssembly.
This is worse, the runtime overhead will always persist. It's nature is to be secure, not fast. It can be faster than JS in instances where you're doing heavy lifting of memory/algorithms. But that is limited to languages like C/Rust that are compiled directly without need for a runtime.
There's no such thing as "not secure" for web-based languages. If the language is not secure, it's simply a non-starter. You cannot bolt on security to the web. You simply cannot build with "fast" as a primary motivation.
It's a spectrum. JIT is inherently insecure, but is "secure enough" given other guards. We use it because it's fast, at the added risk.
We can infact make things provably safe within certain contexts. But we don't, because it's hard, and it can never perform as well.
Wasms safety is dependent upon the runtime implementation, not the language.
"Fast" is a motivation in web. If it renders slow, it loses money. We have 20 years of hacky methods to make JavaScript fast. These lead to security flaws.
Build infrastructure and the right languages will come. Build another language, and we'll end up building a second Javascript.