Please change roadmap checkmark chart to caniuse style "first introduced in"

[juj]

The page https://webassembly.org/roadmap/ is a great improvement in gauging the different feature sets of Wasm. Would it be possible to change that chart to instead of checkmarks, show the version of the browser where the feature was first introduced, like caniuse.com works?

That works better when one has to make decisions that balance between supporting old browsers vs when it's safe to assume that a certain feature is ubiquitous.

[RReverser]

@juj That's a great idea and definitely something that I considered while creating the table.

Problem is, while gathering data on feature support was more or less straightforward, there is no good source of truth on historical versions, which makes hunting down each [feature x engine] cell for "first introduced" a pretty difficult and time-consuming process.

It becomes even more difficult when you consider spec changes (e.g. SIMD opcode renumbering, where some browsers passed the feature tests, then the spec change happened and they stopped passing it, and then they updated to newer spec and are passing again - which version would you even put as "first introduced"? all the ranges? only the latest version of the spec?).

Given that WebAssembly is mostly supported and used in evergreen browsers (ones that self-update automatically for majority of users), all of this didn't seem like a big concern and pure checkmark works well for most use-cases. That said, if someone is willing to dedicate time, solve the above questions and make a PR, I would be more than happy to accept it :)

[juj]

... which makes hunting down each [feature x engine] cell for "first introduced" a pretty difficult and time-consuming process.

Yeah, agreed, and I think that is exactly the reason why it should be done by the WebAssembly group. If it is really hard and time-consuming, it would be criticial for one party to do it right once, rather than leave it every individual Wasm user out there to figure out on their own (and get wrong).

which version would you even put as "first introduced"? all the ranges? only the latest version of the spec?).

The relevant version(s) of the spec should be listed. See how caniuse.com manages this. For example with the SIMD opcode renumbering, it would list Wasm SIMD as a feature, then list each browser version that introduced that, and then for the nonstandard old opcodes numbered version, it'd show up with a footnote superscript number¹ for the first version of the browser that introduced the nonstandard version. That version may be shown in green, yellow or red to hint towards level of compatibility with the official standard as ratified.

For example, here is an excellent entry of how caniuse.com highlights WebGL 1.0 support, along with the older nonstandard experimental-webgl path.

That said, if someone is willing to dedicate time, solve the above questions and make a PR, I would be more than happy to accept it :)

The first PR does not need to be perfect. E.g. if the table is updated with, say, Chrome team filling up their own column (I bet there are more than one Wasm engineer in the Chrome team who can list up the "first introduced in" version numbers for each feature, and take less than a few hours to do it), marking all other browsers with ✓ introduced in unknown version, someone will eventually come up from Mozilla and Apple and other teams to fill up their own column. (maybe even ping up the relevant authors to fill in their own turfs)

[tlively]

@RReverser If you have the bandwidth to set up a framework for exposing this information on the website, I can take point on actually collecting and filling in the relevant data for Chrome.

[juj]

Now with the recent branding of WebAssembly 2.0, I think there is even more important need to have good documentation about which VMs/browsers first added support to WebAssembly 2.0 and when. The W3C news are already circulating the web and people are already asking "when will you support WebAssembly 2.0", hence we (and no doubt many other devs) are again playing the investigative game of trying to figure out "which version of browser X,Y,Z first added support to A,B and C?"

@tlively any chance you might have the Chrome data at hand, and e.g. just drop the info here, or reply under Fyrd/caniuse#5687 (comment) which had the Firefox information, to have the info at least somewhere, even if the website has not yet been updated?

[tlively]

I think @dschuff had made a good start on collecting this information.

[d0sboots]

Given that WebAssembly is mostly supported and used in evergreen browsers (ones that self-update automatically for majority of users), all of this didn't seem like a big concern and pure checkmark works well for most use-cases.

Maybe this was true ~2 years ago, but as this (or any web technology) matures, knowing when it can be relied on (and which parts) becomes increasingly important. My particular interest was reference types, but it could just as easily have been exception handling, or anything else.

That said, if someone is willing to dedicate time, solve the above questions and make a PR, I would be more than happy to accept it :)

I agree with tlively here that setting up the framework might best be done by someone with domain-knowledge on the code here. The actual data-collection, which is the burden you want to avoid, can be done by other contributors once the framework is present.

[juj]

LLVM is now bumping the minimum required WebAssembly VM capabilities required to run LLVM-compiled WebAssembly content. https://reviews.llvm.org/D125728 and emscripten-core/emscripten#17690

This change is being done casually without identifying the minimum browser and VM requirements that will now be needed by end users, with a statement "all latest VMs have these features", which has now developers scrambling to figure out "what does this change mean for us?" and "which browser and shell versions can we now support for our users?"

This seems like information that could be readily and trivially readable from the WebAssembly roadmap page itself, if the roadmap was maintained in a "first introduced in" form. Namely, developers once again need to figure out answers to questions like "which browser versions have nontrapping-fptoint, sign-ext, bulk-memory, and mutable-globals available to them?", but it seems that this information is not available without an extensive google spree - while it could be readably available on the roadmap page.

Given that practically the same set of developers who develop WebAssembly spec and the website, are also the people who develop the VMs at Google, Mozilla and Apple, I think it would be extremely helpful to the community if this information was developed in sync and provided to developers? 🙏

[torokati44]

I'm just adding my +1 here. Please, if you can find the means and resources to make this change, it would evidently be immensely helpful for many people.

[dschuff]

Just to bring one clarification from the discussion on emscripten change: LLVM is changing its defaults soon, but emscripten is not going to change its defaults without more announcements and help for developers. One of the PRs pending in emscripten is to give emscripten the ability to add clang flags at compile time (so that emscripten can keep its default even when LLVM changes, and switch on its own timing). Emscripten will also support setting wasm feature sets based on browser version rather than needing to choosing them individually, which I hope will also make things easier.
But yes, we should surface this in the website. As @tlively said above, I've collected most of this information (you can view it at https://docs.google.com/spreadsheets/d/1jT05jtyun8KFDMZWGjqtqprqJpKkdvC0zfq0aHcAxVE/edit#gid=0).
I'm no web designer but hopefully we can get this on the site in a simple way (I think we'd also be happy to accept PRs for this). Ideally we could maybe get it on caniuse.com too. Some of these features are not actually wasm proposals but are either implementation features (4G linear memory), JS features (growable ArrayBuffer), or weird combinations (Wasm Atomics + SharedArrayBuffer) so it can get a little complicated.