Browsers and Runtimes compatibility
Spoonbender opened this issue · comments
While a crate may properly compile to a specific WASM target, it might still not work correctly in all browsers and runtimes.
This issue is dedicated to considering if and how the crate's compatibility with various browsers and runtimes.
I'll try to survey the state of affairs:
The WebAssembly working group released an MVP (WebAssembly 1.0) in Nov 2017.
Since then, WASM is gaining new features through a standardization process.
We can find a partial matrix of features compatibility, which includes browsers and runtimes, here: https://webassembly.org/roadmap/
As we can see, for each feature+host combo, there are three possible levels of support indicated: supported, not supprted, or experimentally-supported (needs to turn on some browser/runtime configuration to enable it).
Additionally, the working group is working on the WebAssembly 1.1 version of the spec (which will basically "bundle" a bunch of features).
IMO, asking the crate author to specify exactly which version of each browser and runtime is required for its crate to run is unrealistic. A better approach would be to:
- Let the crate author specify which WASM features their crate requires
- Let the crate author specify which minimal WebAssembly version is required (this will be useful once WASM 1.1 is out)
The actual support status can then be evaluated (manually or automatically) by checking the min WASM version + required features against the implementation status in different browsers and runtime versions (data that we might be able to get from caniuse or the working group)
@yrashk If that makes sense, I'll try to establish a proposal for extending the metadata with this information.
Something to consider: the min-version and required features list may depend on the compilation target (unknown/emscripten/wasi), the crate features, and perhaps even the actual host (browser/node/etc.) - though I'm unsure about the latter.
Devil's advocate: this may be too much information to try and squeeze in the metadata, and we might just leave it to the crate's readme file to explain these limitations.
It makes sense to me. I get the concern about overabundance of information in this. Let's at least try to see what we can do in a minimalist fashion?
Addressed in #8