well it's supposed to be a fallback...you are aware that a fallback is just something better than nothing, right? There are several prototypes already (i.e. https://github.com/lukewagner/polyfill-prototype-1 )
Of course, but I'm basically asking which of the two possible fallbacks would be better:
- test for presence of WASM, if absent fetch the pre-compiled asm.js fallback
- test for presence of WASM, if absent fetch an asm.js WASM compiler to runtime-compile WASM to asm.js.
There's a potential a trade-off in both downloaded size (depending on how big the compiles asm.js file would be compared to WASM + asm.js-based compiler) and loading times.
The prototype you linked looks cool though; too bad development on it seems to have stopped in early 2016. I'll copy their outline of how it works for the lazy:
1. On the main thread, the client kicks off a load
of a URL by calling loadWebAssembly and receives
a Promise<Function>.
2. The polyfill library starts up a worker containing
asm.js code compiled from unpack.cpp concatenated
with the glue code in load-wasm-worker.js.
3. The worker glue code fetches the binary via XHR
then copies the result into the asm.js heap.
4. The asm.js code decodes the binary into asm.js
in the form of UTF8 bytes in a separate region
of the asm.js heap.
5. The worker glue code creates a Blob (a read-only
copy) from a view of just the asm.js UTF8 bytes.
6. The Blob is postMessage()ed back to the main
thread (a non-copying operation) where it is
loaded as a script element with
script.src = URL.getObjectURL(blob).
7. When the asm.js script is executed, it passes the
asm.js module function object to a callback which
resolves the promise in step 1.
