Re: [w3ctag/design-reviews] Scheduling APIs (#338)

> people might choose between say, Promises and setTimeout based on API familiarity or usability, even when they have non-obvious differences in semantics that are important. 
Yes that is right. The introduction of async / await has compounded this by steering developers towards microtask timing, when they are really making a syntax choice without considering the semantics.

> * if we should have a more flexible relationship between the syntaxes and the timings, e.g., better ability to choose the timings when using a given syntax (at least for some of the important ones)
Would love to hear your ideas.
I'd floated the idea of additional syntax for promise, but we also really should address async / await.
Example:
Promise.resolve().thenYield(bar);
OR
myPromise
  .then(Priority.Default)
  .then(value => { ...
  });
OR
myPromise
  .thenAtPriorityDefault()
etc.

> * whether the builtin API for task queues proposed here makes that problem better or worse -- which I suspect may depend on how easy/hard it is to hook all the existing sorts of delayed work we have in the platform up to these task queues (in lieu of their current defaults).
the builtin API certainly aims to make this better with "semantic priority", however we have to really pick appropriate names here (work-in-progress):
https://github.com/spanicker/main-thread-scheduling#1-immediate-priority
https://github.com/spanicker/main-thread-scheduling#2-render-blocking-priority-render-immediate
etc.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/338#issuecomment-462567185