Documentation is sparse on why emscripten compiled wasms are incompatible. Please provide more information
Traditionally, all WebAssembly modules are essentially eval()ed. You need JavaScript to download the module into an ArrayBuffer or the like, then pass that to the WebAssembly API to compile it.
However, in Cloudflare Workers, we didn't want you to have to fetch WebAssembly remotely at startup. Instead, you upload your WASM module to the Cloudflare configuration UI/API together with your JavaScript code. At startup, the WASM is compiled and the resulting `WebAssembly.Module` appears as a global variable in your script, which you can then instantiate.
Emscripten normally automatically generates JavaScript for you to load your WASM. But Emscripten's generated script doesn't understand this delivery model where the module shows up as a global variable. It should be trivial to add support, but it would be awkward for us to try to submit a patch upstream without the functionality being public yet.
Edit: Just tested this on https://public.tableau.com/vizql/v_public-release1809140800/...
runtimeweb.wasm 2,484,043
runtimewebwasm.b64 3,355,640
runtimwebwasm.hex 4,968,086
runtimewebwasm.b64.gz 974,065
runtimewebwasm.hex.gz 701,052
runtimewebwasm.b64.br 718,918
runtimewebwasm.hex.br 466,221
* Security: In case of an attack we need to be able to call up the code to do forensics, which is hard if it was downloaded dynamically at runtime.
* Optimizations: We want to keep the ability to pre-compile code e.g. into V8 code cache format before distributing it to the edge.
which is hard if it was downloaded dynamically at runtime
Not sure if you mean something other than what this sounds like (I haven't used CF Workers), but just to clarify further, the option I mentioned causes emscripten to emit one single JS file with no external code downloaded at run time.
(In any case, that performance optimization alone certainly sounds like a good reason for the separation.)