Update roadmap with feature support table & links #164
Conversation
Update roadmap page to describe current status of things, links to the standardization process and current list of proposals, as well as a caniuse-like table for implemented features across popular engines.
| "url": "https://www.google.com/chrome/", | ||
| "logo": "/images/chrome.svg", | ||
| "features": { | ||
| "bigInt": "#enable-experimental-webassembly-features", |
There was a problem hiding this comment.
This is useful, but I'm worried it will get out of date too. I guess it doesn't change that often, though.
There was a problem hiding this comment.
Well that's the point of caniuse-like table - to show feature support across engines. Indeed, it will require constant maintenance, but it's also currently the only way to find out which Wasm features are supported in chosen browsers and so on.
There was a problem hiding this comment.
Indeed, it will require constant maintenance, but it's also currently the only way to find out which Wasm features are supported in chosen browsers and so on.
I do agree that this is useful to have, but I share @binji's worries about it becoming outdated quickly. Can you share more information on your plans for keeping it up to date? (Case in point, in Wasmtime we recently enabled multi-value by default, finished implementing bulk memory, and are actively working on reference types.)
There was a problem hiding this comment.
Just like on caniuse.com, MDN or feature tables in https://v8.dev/features, I expect that this will be updated by website maintainers or engine maintainers relatively quickly after features are implemented. All of these websites share similar concerns, but on practice delay has never been too big thanks to community contributions.
I'm happy to update this table (admittedly, I wrote this JSON about a ~month ago and only made a PR now) with new Wasmtime features.
There was a problem hiding this comment.
Just like on caniuse.com, MDN or feature tables in https://v8.dev/features, I expect that this will be updated by website maintainers or engine maintainers relatively quickly after features are implemented.
I've seen this go wrong a good number of times, so I'm not sure this is a valid assumption to make. Would it make sense to bring this up in the CG and ensure that there's some amount of commitment from enough of the relevant implementers to really do this before landing this?
There was a problem hiding this comment.
What is the risk scenario here? In my perspective, tables like this are useful for development to know when you can compile with a specific feature or when you need to ship a polyfill / a version that doesn't rely on certain new feature.
Even if tables gets outdated, worst case is a false negative, which means that someone unnecessarily ships a polyfill to the engine that has a native support now, which might be suboptimal, but not critical by any means.
What matters / is the goal here is the best-case scenario where someone can ship a more optimised version (e.g. using SIMD or threads or native integer conversion ops) to engines that definitely support it, and for that scenario even an outdated table is better than nothing (what we have right now).
All in all, I'm commited to keeping this reasonably up-to-date, but I don't see delays as a critical problem for the original goal which is unblocking developers in using / testing new features on "definitely supported" platforms.
There was a problem hiding this comment.
Agreed, it's probably better to have out-of-date information than to have no information here. Maybe as a compromise we can include version numbers for the tools? Or even simpler, we could include a "last updated" mention.
There was a problem hiding this comment.
"Last updated" sounds like a good idea, yeah.
There was a problem hiding this comment.
I've updated the PR with version numbers for each engine so that it's immediately clear what version the table was tested against and reflects; please see a screenshot below and let me know what you think.
|
Can you upload a screenshot of the layout? Or is there a way to see it live? |
Right, aside from building locally, I don't think there is. Here:
|
- Use table caption, thead and tbody. - Shorten versions of engines to meaningful parts.
|
I've updated the data and added tested version numbers to each engine, which hopefully will clear up any confusion:
|
|
Looks good to me! @tschneidereit what do you think? |
|
@tschneidereit Ping. Does this sufficiently address your concerns so that we could merge it for now? |
|
I think I'm going to proceed with this as the solution with version numbers hopefully addresses concerns above by making it clear which version of the engine the table reflects. We can adjust the actual update workflow as we go, independently from the initial PR. |
Update roadmap page to describe current status of things, links to the standardization process and current list of proposals, as well as a caniuse-like table for implemented features across popular engines.