scheduling, scheduler, main thread, main-thread
We're waiting on the TAG spec review, but the pre-spec TAG review is here: https://github.com/w3ctag/design-reviews/issues/338
Since this is a new feature, the main risk is that it fails to be adopted by other browsers. This carries some adoption risk since scheduling can be a fundamental part of an app's architecture. But this API is polyfillable, which helps mitigate this risk.
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/546)
WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-June/031912.html). Ryosuke has been concerned with the risk of priority inversion, which we’ve explored and written about here: https://github.com/WICG/scheduling-apis/blob/main/misc/priority-inversion.md.
Web developers: Positive
- We've worked closely with React and Airbnb while designing this API, and both are planning to use the API. Airbnb wrote about there uses cases and performance improvements using the API here: https://medium.com/airbnb-engineering/building-a-faster-web-experience-with-the-posttask-scheduler-276b83454e91
React mentioned the partnership and planned adoption of the API in this thread: https://twitter.com/acdlite/status/1410609223705133074
- The tracking bug (crbug.com/979017) has 9 stars
- Blog post about using the API behind a flag: https://dev.to/nielsen-tlv/the-hidden-magic-of-main-thread-scheduling-16i9
Are there any other platform APIs this feature will frequently be used in tandem with? Abort[Controller|Signal]
Could the default usage of this API make it hard for Chrome to maintain good performance? Unlikely. There is always concern around starvation and abuse when introducing (higher) priorities. But it is always a possibility that script just won't yield (or queue microtasks, or abuse rAF); the scheduling mechanisms introduced here are intended to allow pages to improve their performance as an alternative to such non-yielding behavior. We will continue, however, to evaluate this as API adoption grows.
Will it be challenging for developers to take advantage of this feature immediately, as-is? No.
Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use? Yes. We plan to extend postTask to support more features, but in the meantime libraries will probably be helpful (e.g. event-based delays and timeouts). A polyfill will be very helpful since scheduling tends to be very integrated into a site's design. We have polyfill that was used by a partner during origin trial that we plan to publish (tracking issue: https://github.com/WICG/scheduling-apis/issues/37)
Exposing the task priority in performance traces would probably be quite helpful, as would showing where a task was scheduled. Tracking bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1225752.
Intent to Prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/HvqbB7TGJKU/m/Kd0WUGXkAQAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/QMQz7rWADO0/m/UYYZJMMOAQAJ
- https://github.com/WICG/scheduling-apis/issues/26 will be addressed prior to shipping, we're just waiting on TAG input (I've just requested this outside of our TAG review).
- We plan to address https://github.com/WICG/scheduling-apis/issues/24 after shipping, which is that isInputPending is on navigator.scheduling and we specced postTask on window.scheduler. Our plan is to move isInputPending to window.scheduler by
1. Updating the isInputPending spec to define it on window.scheduler
2. Aliasing navigator.scheduling.isInputPending to window.scheduler and doing outreach
3. Watching UseCounters and deprecating navigator.scheduling.isInputPending
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/972e1ec0-a096-4aa9-82ac-4f560a43b8a3n%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DchC9ib_7jq7HmJT8ytd671C3V%2BG%3DHMNed1ZrVqL_YjZg%40mail.gmail.com.
Thanks all! Regarding issue #26, unfortunately we haven't received a response from TAG folks yet via design review or on the issue itself. I went ahead and made the change to better future-proof the API, which IMO is unlikely to be controversial given it's in line with TAG guidance.Is it okay to ship now, or should we continue to wait for TAG feedback?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ1d8YwxaZDKQsCoRmmPh5vKBHG2wdK5Gev02VAhSsWPGg%40mail.gmail.com.