@cynthia, the first bullet "naming of the sync and async methods" is the most time critical for the WG. This is to avoid breaking changes to the mainstream parts of the API as we approach Dev Trial.

To ensure you use your review time effectively, I want to clarify we are not asking for a full (re-)review of this spec, but a recommendation on this one question. The latter two bullets are mainly for your information and to provide supporting information and context. Thank you!

Hi @anssiko just to let you know we're working on getting you feedback here this week.

@torgo thank you for keeping us updated. The WG is slated to discuss this on 2022-11-03.

I'm wondering, what's the motivation for the sync API? I think async APIs should be friendly to WebAssembly in the near future, given that WebAssembly JavaScript Promise Integration reached Phase 3 in the Wasm CG.

@littledan this was also brought up by @domenic in webmachinelearning/webnn#272 (comment), more context there.

Do we have an estimate when this integration might ship in multiple engines?

Sorry, I don't have any information about timelines here; maybe @fgmccabe does

Probably the next engine to implement JSPI will be Firefox. However, that will likely not be before sometime next year; they have a lot of other things to work on.

Apologies this took so long, especially given the small change. Given the implementation support ot do this nicely is currently not ready, we discussed this at length and came to a conclusion (albeit somewhat distant from unanimous) that the following tradeoff would probably be acceptable (while not ideal).

• x() + xSync() as conventions - we will add a design principle on this.
• Assuming xSync() would block the main thread for longer than we would likely be comfortable with, keeping it limited to worker should at least prevent inappropriate use degraging user experience.

That said, we would like to see a migration path forward once WASM Promise integration lands on multiple implementations. Thank you for your patience, and we're excited to see this work move forward.

Thank you @cynthia & TAG on behalf of the WG. Both the spec and the WIP implementation now follow this convention.

Hi again TAG!

NB: I'm piggypacking on this issue to retain context, but please let me know if I should file a new issue instead. On behalf of the WG I hope the TAG is happy to see these changes and look forward to your comments.

We're looking to publish a new CR Snapshot of the Web Neural Network API in Q1'24 and wanted to give you a heads up with the following high-level summary of changes for your information and review:

Since the initial Candidate Recommendation Snapshot the Working Group has gathered further implementation experience and added new operations and data types needed for well-known transformers to support generative AI use cases. In addition, the group has removed select features informed by this implementation experience: higher-level operations that can be expressed in terms of lower-level primitives in a performant manner, and support for synchronous execution. The group has also updated the specification to use modern authoring conventions to improve interoperability and precision of normative definitions and is developing a new feature, a backend-agnostic storage type, to improve performance and interoperability between the WebNN, WebGPU APIs and purpose-built hardware for ML.

You are probably happy to see we're removing support for synchronous execution per your guidance (removal discussed in webmachinelearning/webnn#531, we expect to land this change ahead this publication) and moving toward JSPI that is coming finally.

Edit: fix link to webmachinelearning/webnn#531