WebAssembly subfeatures

[juj]

WebAssembly currently supports a growing number of subfeatures that is causing fragmentation in WebAssembly adoption. Simply listing a single WebAssembly supported Yes/No page is not enough.

The WebAssembly roadmap page at https://webassembly.org/roadmap/ lists the most recent state of each browser, but that is not really useful for anyone developing a site that needs to take marketshare statistics into account.

In WebAssembly/website#187 a question was raised to the WebAssembly CG if they would like to revise the website to be more precise caniuse.com-like in the data they provide, but the query did not gain traction, citing "it is too complex" to report the data like caniuse.com does.

Would it be possible for caniuse.com to do this?

The different subfeatures of WebAssembly so far are:

• Wasm BigInt support
• Bulk memory
• Multivalue functions
• Mutable globals
• Reference types
• Nontrapping Float-to-Int conversions
• Sign-extension operations
• Wasm exception handling
• SIMD128
• Tail calls
• SharedArrayBuffer and Atomics. This is already covered by https://caniuse.com/sharedarraybuffer
• 4GB Wasm Memory support. Add 4GB heap support to roadmap? WebAssembly/website#214

To get going, I gathered the results list for Firefox desktop:

Signext: Introduced in Firefox 57
Nontrapping FpToInt: Introduced in Firefox 60
Mutable Globals: Introduced in Firefox 61
Bulk memory: Introduced in Firefox 64
BigInt: Introduced in Firefox 74
Multivalue: Introduced in Firefox 77
Reference types: Introduced in Firefox 78

Wasm exceptions: No support as of Firefox 82
SIMD128: No support as of Firefox 82
Tail calls: No support as of Firefox 82
4GB Wasm Memory: No support as of Firefox 82

Do you think this kind of data could be integrated to caniuse.com?

[juj]

Started a repository that one can use to quickly test out the different subfeatures: https://github.com/juj/wasm_feature_test . I'll try to complete to the full set soon.

[kiding]

Very much related: #5200

[andylizi]

webassembly.org/roadmap has been revamped to report detailed support data, which is now mostly complete for mainstream browsers.

Should we replicate this data to caniuse.com?

Pros:

1. Discoverability: caniuse.com is significantly more well-known than WebAssembly roadmap. It is the go-to place for developers seeking centralized knowledge about web feature status.
   • Updates to WebAssembly #6383 addded a link of the roadmap to the resources tab, but I feel it's too hidden for most people. I personally almost never check in there.
2. Marketshare statistics: This is arguably more useful than raw version numbers. The roadmap doesn't have this.

Cons:

1. Maintainance burden required to manually keep the two projects in sync.
2. Design mismatch: the roadmap is designed slightly differently. Overall it's just less powerful/expressive than caniuse.com in general.
   • For example, it doesn't track the first-introduced version of feature flags (rationale).
   • And it can't express complicated situations very well. Such as the threads feature, which is entwined with a bunch of different stuff like SharedArrayBuffer/cross-origin policies/atomic instructions/platform support/etc.

[dschuff]

I think we should add the feature extensions, basically for the reasons given in the Pros section above.
I just uploaded #6952 as a test case and it wasn't too bad. Based on my experience keeping webassembly.org/features up to date, It doesn't seem like it will be a huge burden to also put the data on caniuse.

For future features, we can add data on first-introduced version of feature flags if we want; although I agree with the rationale given in your link, that developers should use bleeding-edge browsers to test flagged features. Also feature flags sometimes change (which would be onerous to track here), and there are also Origin Trials, which are arguably more relevant to track wrt browser versions than flags. But those considerations apply to all new browser features and are not unique to wasm, so we can do whatever the common practice on caniuse is.

I agree that SharedArrayBuffer is tricky; this is true for both webassembly.org/features and caniuse.