[FrancoDiaz]

I don't see what the difference is between WebAssembly and what we have now. Now we have transpiling to ES5. Eventually, we'll be "compiling" to WebAssembly. The only difference is that one target is a bytecode and the other is a source language.

[bobajeff]

Yep, from a developers perspective there is very little difference between asm.js and WebAssembly.

The main differences for developers will be the download size for compiled code will be smaller and the startup time will be faster.

Outside of those differences all browsers will consistently optimize for it. At least one upstream compiler backbend (clang/llvm) will support it. So you'll get more tooling from outside of the few folks working on emscripten and you'll more likely see support from language frontends like Swift and Rust.

[Gxorgxo]

If you transpile to ES5 you get code that still has to run in the JS engine. WebAssembly is low-level code that gets executed faster and allows you to build different kinds of abstractions on top of it. It's comparable to sending an executable to the browser, it could have been written in any language.

[FrancoDiaz]

Uhmm...yeah, I thought I pretty much said that. My point was from the application developer's perspective, what's the difference? Even now, C++ can be compiled to JS via EMScripten to asm.js.

I don't write "JavaScript" right now. I write Typescript. Most of the front-end ecosystems that I deal with (primarily Aurelia and React) aren't being written in ES5. It's usually ES6/7 and Typescript.

[gsnedders]

WebAssembly is still run in the JS engine, though. And especially if we start adding GC support to it, that's not going to change.