LLVM is not really a VM in the sense of the JVM. LLVM-IR is not platform independent, and was never intended for this use-case.

It is also significantly more complex than wasm, which is partially why wasm ended up working. Start small, add over time: that's the way of the web platform.

More importantly LLVM-IR isn't stable. It's intended to just be an intermediate between the bundled front-ends & back-ends. There's some limited compatibility provided ( http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compa... ), but nothing close to suitable for an actually persisted format.

There's a subset of LLVM-IR that IS platform independent. PNacl, and many others rely on this.

The reason for wasm's victory is two found:

1. WASM is a stack based VM (LLVM IR is register based). Additionally, instructions chosen for wasm were inspired by the byte code representation used in existing JS JIT compilers. This meant that WASM almost fit effortlessly into the browser compiler pipeline. Compare this to adding the LLVM jit engine that the nacl philosophy uses. WASM was easier to implement. Stack based VMs are also (apparently) easier to sandbox, with a significantly lower attack surface

2. Firefox was philosophically against nacl/PNacl. Considering how Webview Safari eventually chose LLVM jit for it's JS JIT, as of 2019, PNacl would probably have won, given Microsoft (chromium edge), Google and Safari all support LLVM jit anyways.

Safari ditched LLVM JIT for B3 a couple of years ago and V8 has never used it, so it was never really established for JS engines.

Every reliable complex system started as a reliable simple system and evolved.

"Worse Is Better", but describing it from the other side.

I see, that's a very good point. Thank you.

The spiritual ancestor or wasm, pnacl, was in fact based on a safe subset of the llvm IR. I think llvm/wasm interop will be hugely important, and will receive a lot of attention from the nascent wasm ecosystem.

Where were you when WebGL, WebRTC, HTML5, etc was introduced? Did you ask "Why do we have yet another graphics api/real time communications api/video streaming api?" back then? No you didn't. The web needs solutions that are built for the web, otherwise it's not going to work.

Especially the "Why not the JVM?" questions tick me off. The people asking this question must be living under a rock. The Web already tried java applets and failed.

I suspect that the JVM isn't an option since Oracle v Google showed that it's not as open as we'd hoped and nobody wants to try the same trick with .NET.

Sun and Oracle are pretty open to JVM vendors that don't play license games.

https://en.wikipedia.org/wiki/List_of_Java_virtual_machines#...

Additionally, Google could have bought Sun, and decided to see how it would burn instead.

The JVM isn't an option because java applets have failed. They are a massive security nightmare and they only run java, as opposed to everything (at least that's the promise of WASM).

Google’s PNaCl was essentially portable LLVM.