Yes, wasm makes sense as a standalone runtime. It's basically just like any other bytecode. Like any bytecode (including jvm's), it comes at a performance pena

Yes, wasm makes sense as a standalone runtime. It's basically just like any other bytecode. Like any bytecode (including jvm's), it comes at a performance penalty over bare asm. I personally don't anticipate it will replicate jvm's success as being a runtime when there is no reason for a runtime to exist - since it shouldn't be much harder to compile wasm (and languages that compile to wasm) to native asm ahead of time. On the other hand I wouldn't have predicted jvm's success either. In places where you want a runtime though, like in shared computation models where it gives you security/performance advantages, it makes perfect sense. It looks like it's probably going to succeed there to me. Compiling X -> JS -> Wasm doesn't make much sense. Not only is wasm a language with cleaner semantics to compile to, but JS doesn't actually really fit wasm semantics particularly well. In fact, while I could have missed something, I'm not aware of any good JS->wasm compilers. The closest I can think of is https://www.assemblyscript.org/ https://www.assemblyscript.org/ - and it's not 100% JS compatible.