> is evaluated forgoing their ability to be optimised ahead of time. ...not sure what you mean with that, but WASM isn't actually AOT compiled in browsers anym

> is evaluated forgoing their ability to be optimised ahead of time. ...not sure what you mean with that, but WASM isn't actually AOT compiled in browsers anymore, instead there are several tiers of JIT-ting on a per function level. E.g. when a WASM function is only called once it is compiled quickly but without optimization, and then when called more frequently, higher compilation tiers will kick in which compile the WASM function in the background with more optimizations. This is pretty much the same strategy as used with Javascript code. You can also split your WASM code into several dynamically loaded modules (and if neeeded, loaded and instantiated in parallel), but (AFAIK) unlike with Javascript bundlers this can't be done automatically. You'll have to design your code that's compiled to WASM from the ground up for being split into several modules (similar to how DLLs are used in native code). > The reliance on JavaScript for WASM modules inherently relies on the wild world of JavaScript tooling. I write all my WASM code with C/C++ tooling only, no npm or similar involved. There's only a minimal .html file which defines how a WebGL/WebGPU canvas integrates with the browser environment. > I'd also like to see us eliminate the need for the `Cross-Origin-Opener-Policy: same-site` and `Cross-Origin-Embedder-Policy: require-corp` headers as they make multi threading in the browser largely impractical. This I fully agree with. There is a "legal" client-side workaround using service workers btw: https://dev.to/stefnotch/enabling-coop-coep-without-touching-the-server-2d3n https://dev.to/stefnotch/enabling-coop-coep-without-touching....