Spec review for scheduler.yield()

[shaseley]

こんにちは TAG-さん!

I'm requesting a TAG review of scheduler.yield().

scheduler.yield() is an API for yielding control to the browser's event loop, which can be used to break up long tasks. Awaiting the promise returned by scheduler.yield() causes the current task to yield, continuing in a new browser task. This can be used to improve responsiveness issues caused by long tasks. Continuations are prioritized to mitigate performance problems of existing alternatives.

• Explainer¹ (minimally containing user needs and example code):
  • https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md
  • https://github.com/WICG/scheduling-apis/blob/main/explainers/prioritized-task-scheduling.md#scheduleryield (in context of the "bigger picture")
• Specification URL: https://wicg.github.io/scheduling-apis/#dom-scheduler-yield
• Tests: https://github.com/web-platform-tests/wpt/tree/master/scheduler/tentative/yield
• User research: N/A
• Security and Privacy self-review²: https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#self-review-questionnaire-security-and-privacy
• GitHub repo: https://github.com/WICG/scheduling-apis/
• Primary contacts (and their relationship to the specification):
  • Scott Haseley (@shaseley), Google (feature/spec author)
• Organization(s)/project(s) driving the specification: Google
• Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification
  • Some positive twitter sentiment:
  • https://x.com/cramforce/status/1588912606777335808
  • https://x.com/mohamedmansour/status/1752909705842933943
  • https://x.com/sebastienlorber/status/1589939130225475584
• Key pieces of multi-implementer support:
  • None yet; to be updated.
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • Chrome Status

Further details:

• [X ] I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: We're hoping to ship this soon, pending feedback.
• The group where the work on this specification is currently being done: WICG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG
• Major unresolved issues with or opposition to this specification:
• This work is being funded by: Google

You should also know that...

• The API has not substantially changed since the early design review
• The feature builds on scheduler.postTask(), previously reviewed here
• Because of the above, a "bigger picture" explainer was requested in the early design review, which can now be found here

[martinthomson]

The yield piece of the scheduling project looks good to us, with the caveat that if the rest of the scheduling project doesn't pan out, or if the different scheduler bits end up hanging off of other objects, we'll need to come back and rename scheduler.yield() to avoid having it hang off of an otherwise-empty object.