Comments (6)
Curious if there are other posts similar to https://medium.com/airbnb-engineering/building-a-faster-web-experience-with-the-posttask-scheduler-276b83454e91 about adoption of the API. In particular I think the point of splitting up "long tasks" is compelling, but has there been interest in the more granular API surface such as changing priorities of a task that is in-flight? And will that additional complexity actually lead to meaningful improvements in performance? (It will also increase the amount of script that needs to be written and transferred.)
from standards-positions.
I don't know of any posts or articles discussing dynamic prioritization. It was something that came up with partners initially when designing the API, e.g. to dynamically reprioritize tasks during loading as the viewport changes (IIRC Datadog might be doing something like this). But usage of TaskSignal.setPriority()
is much lower than that of scheduler.postTask()
. There has been more focus on scheduling recently, however, due to a recent focus on interaction-to-next-paint, so we might see usage of that tick up -- although I'd imagine not in the common case.
from standards-positions.
One other thing that came up when looking at this internally is that yield()
and render()
are inconsistently named. (And yield()
is probably the odd one out given wait()
and postTask()
.)
With await scheduler.render()
you're awaiting rendering to happen. But with await scheduler.yield()
you're not waiting for yield to happen. You're waiting for a continuation task.
from standards-positions.
I had thought the naming was consistent, since in each case you're waiting for a task to run after the associated action (the continuation always happens in a new task, not during the action):
API | Action to resume after | Behavior |
---|---|---|
scheduler.yield() |
yield to the event loop | The returned promise is resolved in a new task (after yielding to the event loop, which is implied by a new task), allowing higher priority work to run |
scheduler.wait() |
X ms have elapsed | The returned promise is resolved in a new task after the X ms |
scheduler.render() |
rendering | The returned promise is resolved in a new task after rendering |
We're open to renaming yield()
if there's a better name, but we haven't thought of one. And I think "yielding" as a strategy for responsiveness is common enough that it's a good name for the API (some motivation for the current name is mentioned here). We discussed maybe prefixing these with after
to help alleviate confusion, but I'm not sure if that's worth it.
from standards-positions.
I discussed this some more with colleagues and the concern is that if you think of each of the names as describing what it waits for and what it does, they are not consistent:
- yield: describes what it does, but not what you wait for
- wait: describes what it does and arguably what you wait for (the argument)
- render: does not describe what it does, but does describe what you wait for
You could possibly make these names more aligned by renaming render to waitForRender or yield to currentTask. What do you think?
from standards-positions.
Thanks @annevk, I agree with your assessment. I'm still thinking about this -- I filed WICG/scheduling-apis#95 with some additional naming concerns that came up in discussions and to solicit wider feedback. I'm not opposed to waitForRender()
, but wondering if switching to noun names would be better (it's growing on me).
from standards-positions.
Related Issues (20)
- Timing Info for ServiceWorker static routing API
- New `trusted-types-eval` keyword for CSP script-src HOT 10
- Reference Target for Cross-Root ARIA HOT 1
- VisibilityState performance entry
- ServiceWorkerAutoPreload HOT 2
- Add a noopener-allow-popups value to COOP HOT 3
- Support 'color-interpolation: linearrgb' on SVG gradients HOT 2
- Partitioning :visited links history HOT 2
- MediaTrackSupportedConstraints.backgroundMask
- WebAuthn hints parameter
- Implement box-decoration-break:clone everywhere
- SVG Favicon
- Temporal - structured clone
- CSS Nesting: The Nested Declarations Rule
- ariaNotify API HOT 2
- Add ability to trigger autofill on form elements in webdriver-bidi specs HOT 1
- Backdrop filter mirror edgeMode HOT 2
- WebAuthn JSON serialization
- Support for PointerEvent getCoalescedEvents() API HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from standards-positions.