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

After a first read-through, this seems like useful stuff.

Some of this (particularly the comment in the explainer about misuse of `Promise.prototype.then` for things that shouldn't block the browser's event loop) got me thinking a little about the tie between syntax and the various types of timing options on the platform.  As a result of adding new types of timing (e.g., microtasks) for things where that timing seemed like the right thing for the "canonical" use of a new API, we now have a set of syntaxes where 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.  It makes me wonder:
* 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)
* 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).

-- 
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-460154141