Seems like most (all?) people in this thread are not picking up on the key insight that he's putting forward here -- which is the encapsulated process & security capability model that was in E.
I think he's absolutely right that the "right" replacement for JS is something built on that kind of foundation. It's not a matter of a language with a better syntax or a better arbitrary runtime like WASM, or whatever. It's the component and security model itself.
Unfortunately 30ish years on, people still don't seem in general to understand capabilities and what this can provide for us, especially in a environment with the trust model of the browser, which is executing arbitrary code from all over.
I encourage people to read up on caps, and actually on E itself.
I'm glad to see Fuchsia running with the capabilities baton. And it's in a lot of devices in the form of SeL4. But almost never exposed as an aspect of "end user" programming.
EDIT: obligatory WP links: https://en.wikipedia.org/wiki/Object-capability_model and https://en.wikipedia.org/wiki/E_(programming_language)
> It's the component and security model itself.
WASI and the WASM component model proposal [1] are moving to a capability based system (enabled by unforgeable references aka `reftype`) and to isolation between different parts of your code, which would make isolating and restricting dependencies really easy.
Combined with interface types (essentially a universal cross-language ABI) the ecosystem has the building blocks for building very secure systems.
Sadly progress has been very slow, with no end in sight, but I remain hopeful.