This is how I make sense of it in my head, I haven't gone and researched the facts I cite, they are just from memory. So, as far as factual information, take it with a grain of salt. But as for intuition, I think it's pretty good.
History is Helpful
Imagine if you emulated a hardware architecture in JavaScript and then instead of compiling your C to Assembly, you compiled it to JavaScript that performed those assembly operations on your JavaScript emulated hardware. Eg you represent memory with a big array of integers (it turns out JS does have integers if you're really idiosyncratic).
Well, some people did that and called it asm.js What was interesting about it was that the instructions were technically valid JavaScript, but they took advantage of weird JavaScript nuances so that the types all mapped to things like 32 bit integers.
They happened to work at Mozilla, so they modified Firefox to notice when their code was doing this and instead of running through all the layers of javascript interpretation, they straight swapped it out with the underlying hardware instructions that would perform the same operations.
Turns out hardware is ridiculously insanely fast (like billions of operations per second), so not only did this allow them to get crazy performance, but it also meant they could run other languages, like C, in the browser. To show how badass this was, they compiled Unreal Tournament from C++ into asm.js compatible JavaScript and you could play it in the browser (video). Now, you could run it in other browsers that didn't know about asm.js, because it was valid JavaScript, and they weren't changing its behaviour, it's just that it would be a lot slower because it had to be evaluated by JavaScript instead of the underlying hardware.
This opened people's eyes, because previously you would have said games like that must necessarily be native (ie download an app and run it on your computer). It showed the potential of the browser as a platform.
Now, one thing that's stupid about asm.js is it was really verbose. They were really shipping down JavaScript, here is an example, look how verbose that is! So the obvious thing to do is to say "instead of compiling your C to "JavaScript assembly" and then having us detect this, parse it, validate it etc etc, why don't you just ship us some sort of binary format.
So, between needing to map it to a binary format, wanting to iterate on the things they learned from asm.js, and the need to make this a standard across browsers, all the web giants got together, iterated on it a bit, and called it "WebAssembly".
Why does WebAssembly matter?
In a paradigm sense: Because it means the browser is becoming a platform (ie you won't need to make native apps, the browser will be rich enough to target directly). It's not there yet, but it's trending strongly in that direction. Eg check out all the web APIs -- side note, I don't think it can get there without some sort of UDP option, eg notice that the unreal tournament demo was vs bots. IMO, when people talk about "progressive enhancement", they're talking about asymptotically approaching this ideal (I haven't heard anyone say that, but it's my interpretation).
In a pragmatic sense: Because you'll be able to get significantly better performance, you'll be able to use best-in-class libraries written in languages like C, and you'll be able to use other languages than JavaScript in the browser (without having to implement them in JavaScript, which is verbose and slow). Rust is definitely primed to be the next browser language. And, I'll point out, Rust comes out of Mozilla, too! I'm down with this, may Rust eat C.
Yeah, I think those are my big thoughts. It's not the only thing we need, but it's a big piece of the puzzle.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
DISCLAIMER
This is how I make sense of it in my head, I haven't gone and researched the facts I cite, they are just from memory. So, as far as factual information, take it with a grain of salt. But as for intuition, I think it's pretty good.
History is Helpful
Imagine if you emulated a hardware architecture in JavaScript and then instead of compiling your C to Assembly, you compiled it to JavaScript that performed those assembly operations on your JavaScript emulated hardware. Eg you represent memory with a big array of integers (it turns out JS does have integers if you're really idiosyncratic).
Well, some people did that and called it asm.js What was interesting about it was that the instructions were technically valid JavaScript, but they took advantage of weird JavaScript nuances so that the types all mapped to things like 32 bit integers.
They happened to work at Mozilla, so they modified Firefox to notice when their code was doing this and instead of running through all the layers of javascript interpretation, they straight swapped it out with the underlying hardware instructions that would perform the same operations.
Turns out hardware is ridiculously insanely fast (like billions of operations per second), so not only did this allow them to get crazy performance, but it also meant they could run other languages, like C, in the browser. To show how badass this was, they compiled Unreal Tournament from C++ into asm.js compatible JavaScript and you could play it in the browser (video). Now, you could run it in other browsers that didn't know about asm.js, because it was valid JavaScript, and they weren't changing its behaviour, it's just that it would be a lot slower because it had to be evaluated by JavaScript instead of the underlying hardware.
This opened people's eyes, because previously you would have said games like that must necessarily be native (ie download an app and run it on your computer). It showed the potential of the browser as a platform.
Now, one thing that's stupid about asm.js is it was really verbose. They were really shipping down JavaScript, here is an example, look how verbose that is! So the obvious thing to do is to say "instead of compiling your C to "JavaScript assembly" and then having us detect this, parse it, validate it etc etc, why don't you just ship us some sort of binary format.
So, between needing to map it to a binary format, wanting to iterate on the things they learned from asm.js, and the need to make this a standard across browsers, all the web giants got together, iterated on it a bit, and called it "WebAssembly".
Why does WebAssembly matter?
Yeah, I think those are my big thoughts. It's not the only thing we need, but it's a big piece of the puzzle.