Especially with upcoming features like GC, threads, exceptions, polymorphic inline cache, and more[1]. Looks somewhere in between ASM and something like bytecode for a VM.

[1]http://webassembly.org/docs/future-features/

Well, ASM is a bytecode for a VM too … CPU are really complex theses days and you definetly don't run your asm on a dumb piece of silicon, as the phrase “bare metal” seams to imply.

And, as a reminder, there's often bugs in that VM. Meltdown was one of them, but there's tons of them.

To add to that, that it was always how most CPUs were developed.

Pure RISC CPUs were the outliers, but coupling RISC ideas with micro-code turned out to win the match.

Even modern ARM versions use micro-code on their CPUs.

I see your point, but threading, PIC, exceptions, DOM access, etc, are a level above ASM.

From one of the guys who work on WebAssembly: "WebAssembly: neither Web nor Assembly"

https://twitter.com/jfbastien/status/880831562207473664

I really wish WebAssembly didn’t use the word “Web”. Its best usecase is for the server. It just happens to also be great for challenging JavaScript in the browser.

Why do you say its "best" usecase is for the server? I'm actually asking, not disputing, but I'm asking because it seems the big selling point of WASM, running new types of code that you couldn't run before, was never a problem on the server, where you can run whatever you like.

So, I'm assuming you have something else in mind, and I'm wondering what it is.

It doesn't challenge JS in the browser, it augments it.

Though I guess you could say it challenges stopgap measures like asm.js.