It’s still not quite clear to me what new things WASM introduces to using different languages. Weren’t we already able to transpile any language to JS?

What WASM provides is an actual low-level bytecode for languages to target. Languages which transpile to javascript are forced to emit code which conforms to the particular limitations and peculiarities of javascript, which can be buggy and inefficient and brittle, whereas bytecode is more generic and only has to conform to a virtual or physical architecture. Bytecode is also faster, because it doesn't need to be interpreted.

You are assuming a compilation that results in high-level JavaScript code. As JavaScript is a Turing complete language, you can trivially compile any other programming language to target it, and we not only have done that a lot but even made it efficient using asm.js. All WASM is buying us is a more efficient encoding format that can be parsed more quickly than asm.js.

> All WASM is buying us is a more efficient encoding format that can be parsed more quickly than asm.js.

That is only the initial property. WASM is expected to get a number of new features that aren't expected to come to JS, like actual threads.

It also applies to asm.js.

Just because it runs does not mean it does so efficiently, or that 100% of the source language semantics are supported without any constraints.

Note that you can't try this out yet unless you have a paid Elements license.

Might help if you link your app `Elements` somewhere in your blog!