Here's a good overview from the emscripten author: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-...

TL;DR: much faster parsing over asm.js (10x to 20x faster), parsing should also use much less memory, 10%..20% smaller downloads (when comparing the compressed sizes, uncompressed WASM is several times smaller then asm.js), 64-bit integers (these have to be emulated on asm.js),

    much faster parsing

Isn't parsing super fast already? From my experiments, jquery seems to compile in a staggering 0.1ms.

I get 165ms for my 8-bit homecomputer emulator which is 534KB compressed asm.js (http://floooh.github.io/virtualkc/), and it seems the first call into the code takes another 500ms on Chrome (probably for JIT warmup). Bigger apps like UE4 or Unity demos are several times bigger and can take seconds to compile.

If you are using ms as a unit you several orders of magnitudes too slow for many domains.

3d gaming comes to mind, most games have a tight budget of 16ms per frame, and at those speeds 0.1 ms is a real chunk of that. If I am going to download a new module in then try to load it the game shouldn't have to hiccup for that.

The partial intent of WASM is to write things orders of magnitude larger than jQuery. Whether or not it will ever be practical to ship e.g. a complete Photoshop clone in a browser remains to be seen, but if that's your goal then you do have to start worrying about things like parse time.

Why would the whole Photoshop be downloaded and compiled? I would expect a web app to only download the parts the I use. If I want to blur an image, I don't need the other gazillion filters for example.

And hey, even if photoshop is 1000 times bigger then jquery - that would still compile in one tenth of a second.

Developers like you are why apps are slow when they don't need to be.

EDIT: Also, if you think 10%-20% smaller downloads aren't worth it, you're clearly not working at a CDN.

jQuery is tiny. https://code.jquery.com/jquery-3.2.1.js is 268KB; the minified version at https://code.jquery.com/jquery-3.2.1.min.js is 86KB, 30KB after gzip compression.

For asm.js/webassembly we're talking about source code sizes in the multiple megabytes range after gzip compression.

A lot.

There's a talk by Alex Danilo from Google IO 17 explaining it in detail.

Here, I'll link you directly to the part where he starts explaining the differences on a technical level:

https://www.youtube.com/watch?v=6v4E6oksar0&t=11m24s

Another part is that I suspect it makes maintaining a good JS compiler easier, because all of that asm.js code can be removed. I'm sure the browser vendors are happy about that.

I don't mean the technical differences. I mean the benefit. What will be the gain for the user of a web app?

I'm not 100% sure about any of this (I've only listened to most of the video above), but I think the gist is that WebAssembly provides a compile target for applications, meaning you can pre-compile an application so that your source is downloaded essentially as machine code. Furthermore, that means your compilation can perform as many optimizations that you care for, because it's happening ahead of time (not on the user's machine).

Without WebAssembly, browser vendors have to strike a balance between optimizing the JS as much as possible (for increased performance), and running the script as soon as possible (so the user isn't waiting too long for execution to begin).

edit: Demo of this in-browser video editor charts a FPS difference between the JS and WebAssembly implementations. https://github.com/shamadee/web-dsp

Compressed download size is indeed only slightly smaller (mostly around 10%), but the parsing is much faster, even noticeable for fairly small demos.

(edit: replied to the wrong comment, apologies)

Is the "parsing" what is displayed as "compile script" in Chromes profiler? That seems to take almost zero time. For example jquery.min.js compiles in 0.1ms here.

Libraries like jquery are not the target use case for WASM. Its intent is to make large applications viable on the web, like something you'd normally install on your computer.

Yes, faster load times. Also, a more sensible target language.

How much faster? I would think gzip should even out most of the difference between a text based and a byte based code.

> I would think gzip should even out most of the difference between a text based and a byte based code.

You would be wrong then. Quoting Unity https://blogs.unity3d.com/2015/06/18/webgl-webassembly-and-f...

"Experimenting with a prototype WebAssembly format on a build of our AngryBots demo, we saw the size of the generated JavaScript code go from 19.0 MB of asm.js code (gzip-compressed to 4.1 MB) down to 6.3 MB of WebAssembly code (gzip-compressed to 3.0 MB). This means that the amount of data the browser needs to process gets reduced by 3.0x, and the compressed download size gets reduced by 1.4x."

So WebAssembly is 1.4x smaller, after gzip.