So if I understand correct, they didn't like LLVM because it wasn't really designed for this purpose. Webasm has some advantages over it like being designed from the ground up to be a secure sandbox and fit in with existing javascript JITs. LLVM also isn't a fixed open standard and doesn't guarantee backwards compatibility (I think.) You can also compile LLVM code to webasm even today, so it isn't that much of an issue.

But this is just my impression to listening to some talks by the developers of webasm.

I work on off-tree LLVM and have been following NaCL from the beginning. I think it's mostly nobody wanted to adopt googles solution or even admit that browsers needed sandboxing. Hell, Firefox only recently got serious about putting different sites in different processes. It took them years to accept they needed a pNaCL, and by then they couldn't really stomach using something already tried and tested by political opponents. Browsers and LLVM are both too political.

Supporting pNaCL and whether or not the browser's own code is sandboxed seem like very different issues; I'm not sure why you're conflating them.

>Hell, Firefox only recently got serious about putting different sites in different processes.

A multi-process architecture is a huge thing to try to bolt on later, and Firefox was also held back because many of its add-on APIs were incompatible with a multi-process architecture. They are finally making progress at least.