Aside: how is WebAssembly's binary form currently shipped? In a demo I saw yeste...

esrauch · on Nov 14, 2017

wasm files are already a binary format, an explicit Uint8Array should only only necessary if you want to inline the wasm directly with the JS that instantiates it.

vanderZwan · on Nov 14, 2017

Right, I thought it was odd; I remember reading that part of the big benefit of WASM was more compact, faster-to-parse source code. Going all the way up to text form and back down to binary data is at odds with that.

> an explicit Uint8Array should only only necessary if you want to inline the wasm directly with the JS that instantiates it.

Are there any realistic scenarios where this is the more sensible option?

Anyway, I should have searched MDN first, the relevant bit of documentation is pretty clear:

    fetch('simple.wasm').then(response =>
      response.arrayBuffer()
    ).then(bytes =>
      WebAssembly.instantiate(bytes, importObject)
    ).then(results => {
      results.instance.exports.exported_func();
    });

https://developer.mozilla.org/en-US/docs/WebAssembly/Loading...

esrauch · on Nov 15, 2017

I suppose you could avoid having the extra request roundtrip by inlining a uint8array (or a base64 encoded string or something), and it also lets you have wasm and it's associated JS be put together which would automatically avoid cache/version mismatch without any extra work, but I would be surprised if that makes sense in any normal scenario.