Explain WebAssembly Like I'm five

What in the heck is WebAssembly? Tried to understand the docs but had no success.

Comments

[EJBroeders]

WebAssembly is a binary format for web applications. That is, it is the format for applications for the web, which is very similar to what Javascript is.

However, developers don't write WebAssembly by hand (which is possible with Javascript). Instead they write some C, C++, Rust, or any other language code, which is compiled into WebAssembly. Similar to how a desktop application is written in some language, and then compiled into a binary format/file often with a .exe extension on Windows.

The main advantage is that WebAssembly has some optimizations built in which are impossible to build into the Javascript runtime environment. One example is garbage collecting. The Javascript engine in your browser has to keep track of all objects and free the memory when such objects can no longer be referenced from within the script. Obvious it takes time for the Javascript engine to keep track of all objects, allocations, and references. However WebAssembly has no garbage collecting mechanism and relies fully on the developer to keep track of his memory allocations. Therefore a WebAssembly program can run faster than a Javascript application. The down side is that it is a bit more difficult to develop WebAssembly applications because of that.

On a side-note, that's why Rust is now a popular language to write WebAssembly applications in. Rust is a fairly new language backend by Mozilla which has some neat syntax rules to keep track of memory allocations.

So in summary, it is a binary format for web applications which allows web applications to behave more like desktop applications. The main advantage is performance, and the main down side is that development is a bit tougher.

[Renan Lourençoni Nobile]

Thank you very much.

[EJBroeders]

You're welcome :-)

[Josh Cheek]

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?

• 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.