Can you provide a source for this? I've never heard it and, though it may be correct, this would make wasm much less useful to me.

I have heard that accessing the DOM from wasm will be quite expensive, but that's different from just calling a function.

Unfortunately you need to interop with JS at the moment in order to interact with the DOM, if you do things entirely in WebGL then ASM is a lot faster.

(If so, this seems like a regression compared to unoptimized asm.js.)

The method I'd expect for high-throughput communication between js and wasm would be for the wasm code to build structures directly in memory and for JS to traverse those directly using the memory buffer (TypedArray, but really ArrayBuffer).

TypedObjects in ES* will let you directly build lightweight JS objects that are just pointers into an ArrayBuffer.

Edit: Updated to note the fact that I really don't know what the status of TypedObjects is currently..

It is enabled in Firefox nightly, though I don't know if the API is stable yet:

    > var Point = new TypedObject.StructType({x:TypedObject.int32, y:TypedObject.int32})

    undefined

    > new Point({x:1, y:2})

    InlineTransparentTypedObject { x: 1, y: 2 }

> The TypedObject proposal predates ES2015 and the yearly release model ECMAScript is on now. That said, the Firefox experimental implementation is not based on current standards work. I'm not sure how useful it is to further advertise or to document it in this case.

Lars T. Hansen of Mozilla added:

> IMO it's premature to document TypedObjects. I think TypedObjects are coming back, but initially to support WebAssembly's interaction with JS, and I would expect the TypedObjects' form to be slightly different from what we have now, more suited to that purpose.

So we may look forward to an eventual revised TC39 proposal for TypedObject, one that explicitly considers interoperability with WebAssembly. But that will probably take a long time. Hopefully someone will write a strawman proposal/polyfill soon.

Seemed like a really nice proposal for procedural construction of typed views into ArrayBuffers, and perplexing that talk of it seems to have died down...

I see the main use cases outside of games will be intensive computing tasks. For instance Glimmer/Ember could run it's VM on a different thread using WebWorkers and WASM, the same could go for React and it's virtual dom.

The interpreters and baseline JITs will always construct the object because they can't inline and they don't do whole-method analysis.. and the heavyweight JITs _probably would_ inline the constructor, then notice that the constructed array does not escape, then scalarize the whole thing down to a single read...

but hey, why work the optimizer so hard when you can just make life easy for it and do a single allocation up front, and it runs fast in all performance tiers, and performance isn't predicated on a particular optimization strategy being utilized.

The more important thing however is the cost of parameter passing. Let's keep in mind that WASM only support numeric types and typed arrays. So in order to make a function call from JS to WASM or the other way around which passes a string as a parameter the string needs to be converted into a format that the other side understands (Javascript string object <-> WASM typed array which contains string in UTFx format). So basically for all more complex data types crossing the boundary costs the [de]serialization of the parameters, which may be huge (and even causes allocations).

If you also only work with integers and typed arrays on the JS side that does not apply. But I guess most people won't be comfortable with that.

…why can't it be inlined? There's no good reason why it can't be inlined.

But yeah, assuming both WASM and JS run inside the same JITting VM it is probably happening.

Your comment immediately made me think of this. Highly recommended talk for anyone that hasn't seen it. It goes through a "fictional" (maybe not so much anymore) history of javascript until 2035. We are getting pretty close to javascript all the way down.

And then, just like the ad spams using JS, its advocates will be getting more than they asked for.

Get ready for WASM blockers.

I think Google is very afraid of this. Hence their push for Angular/Polymer/AMP. If they can build a good enough platform in JS they can stall the inevitable.

In the future only marketing parts of the site will use JS/HTML. The "web app" part will be some language compiled to WASM throwing frames to the canvas

What Google has liked to do recently is take all your data and replace your service. Search for recipes, jobs, music, or weather for examples.

They're trying to make leaving the homepage irrelevant by using sites data in their search results. Eventually the web will rebel.

Instead of "why I moved from Angular/React/.... to Vue.js", it will be "why I ported into WASM".

So the way to do it today would be WebAssembly -> asm.js/js -> canvas

asmj.js as JS is irrelevant to the point I was making, because if you access the DOM directly, your code won't verify as the asm.js subset, and so won't run via the asm.js engine.

asm.js is javascript.

asm.js === javscript