That's obviously a common misconception given the name -- LLVM was meant to be a VM early in its life, but never was, and isn't now. It's clarified in the first sentence of a home page - https://llvm.org/
It's basically a bunch of C++ libraries that implements an IR that changes over time, which help you write compilers.
Curiously, I think a decade or more ago there was a project at Google targeting the same space as WASM which made this mistake. They thought LLVM was a virtual machine! That was PNaCl or something.
I guess it's a little like LuaJIT freezing Lua at Lua 5.1 -- Lua was never a standard, but for the purposes of re-implementation, a specific version of it can be frozen. (But there are obvious problems with that approach, namely that the re-implementers don't know about all the bugs they're also freezing in time.)
---
I have raised some eyebrows at the "compromises" of WASM, but the once thing that you can't doubt is that it is in fact a virtual machine !!!
I watched a talk on the WASM GC, and the creators were up front about the compromises (e.g. you will need runtime casts at first, with the measured overhead being reasonable), which gives me more confidence in it:
https://old.reddit.com/r/ProgrammingLanguages/comments/17crk...
I feel like I really don't get wasm. It's not clear to me what problem we're trying to solve here...
Is the goal to be able to write applications in programming languages that aren't javascript or (transpiled to javascript)? Does that include writing the parts that interact with the browser's DOM presentation layer? I think my understanding is that you can't actually do that? If that's right, is the goal instead to be able to run applications in a dedicated canvas within the DOM, like how Flash worked? If so, how big is the niche for that?
Or somebody in a different thread mentioned using wasm for cloudflare workers. Because those work via a javascript interpreter, I guess? But, like, if people want to write cloudflare workers in arbitrary runtimes, couldn't cloudflare just add support for those other runtimes? Surely they have the wherewithal to do that...
Or is there something that is uniquely great about wasm as a bytecode, beyond its connection to the javascript ecosystem?
I just really feel like I've missed reading some introductory material on why this technology is exciting, but it's embarrassing to ask at this late point...
WasmGC, which is the proposal under current discussion, is one of the biggest steps towards that. You can't safely interact with the DOM if you can't pin references to the DOM. You can't pin references to the DOM if you can't let the JS VM garbage collect you (or otherwise understand your garbage collection needs).
(One of the demos mentioned in the article shows Dart/Flutter driving what seems to be a lot of DOM via GC pointers. I haven't dug in far enough to see exactly what the balance is between JS and Dart there, but it should be a lot closer than previous demos.)
Besides memory checking, there are much fewer nasty things a process can do in terms of control flow since executable memory (procedures) do not exist in linear memory. It supports function pointers via a separate table system (kind of like having a separate address space for executable memory). All of this is in place so if a WASM module crashes, it doesn't take down whatever process it's running in.
For example, there's a project called Oak (https://github.com/project-oak/oak) that basically allows your private information to be processed by servers without revealing them to the servers. It uses a bunch of technologies and wasm is a center piece for allowing a safe form of code execution.
For another example, check out Mozilla's post about securing Firefox with wasm (https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...). Again, here we compile C/C++ code with unknown memory safety properties into wasm and then compile that to native code. The benefit of doing it over directly compiling C/C++ to native code is that any memory safety issue is strictly sandboxed to be within the wasm module. You can't have one library's memory safety bug trampling over another library's memory.
On the supportive side: Embedding arbitrary code (mostly, but not entirely in browsers) with secure sandboxing.
On the skeptical side: Just a way to make the browser less of a user agent and less accessible by running opaque code blobs.
LLVM (without a lot of coding anyway, wasmer has an LLVM backend) doesn't do the whole "easy secure sandbox by default" thing, which IMHO is easily the biggest differentiator of WASM.
WASM saw that and decided to make security priority number one from day one.
More like "WASM is the new JVM".
It's just turning into, excuse my philosophy nerdism ... like Hegel's quip about “the night in which all cows are black.” An Absolute into which meaningful content just dissolves. A proverbial hammer looking for nails, and finding them everywhere, but honestly, adding no new utility.
Wasm in the browser for porting certain kinds of apps makes a lot of sense. But if you're running e.g. JS inside Wasm on a server somewhere, you got off on the wrong exit on the hype train. You don't need to do that. It's neat that you can, but ... don't.
A "universal runtime" is a kind of ultimate nerd fantasy. I've had it too. It's also mostly pointless overhead. The reality is that containerized or virtualized execution already exists and there's no "universal" garbage collection or virtual machine. They end up inevitably tailored to the language they're there to support. And that's not a bad thing.