True, but they have (generally) been second class citizens with very little adoption, mostly because targeting JS has had quite a few drawbacks, such as huge payload size or tons of time to parse and optimize.

Assuming wasm delivers on its promises, that should change, and that is when those languages will stop being mostly experiments but real viable platforms.

WebAssembly still has a long way to go. They don't have a plan yet for:

* GC

* Interoperating with browser objects (even strings)

* Debugging and other tooling

I don't think any high level language will be able to compete with JS on an even playing field until that language can use the high performance GC that's already in every browser.

If your language has to either not use GC (huge productivity loss) or ship your own GC to the end user with your app (huge app size), it's an unfair fight.

Right now, though, all non-JS languages are second class citizens. They have to be turned into JS to actually run, and JS gets to run natively. This has huge implications for debugging, among other things.

And that won't change in the MVP of this, where JS will still have capabilities that WebAssembly-targeting languages won't have. But their clear vision is to make WebAssembly a VM that puts languages on equal footing, with tooling and debugging that works cleanly for all targets.