Doing some offline consultation with other experts on event loop

Martin: Naming discussion seems to be ongoing.

Scott Haseley: "render" is the only piece that's still up in the air. Noam threw out other ideas. Maybe pursue "render" as an argument to "yield". You're yielding but also waiting for rendering. Last comment was that there's another use case where you want high-priority rendering updates, which might benefit site performance. I'm not convinced we should couple those, but it made sense to experiment. Developers were happy with "yield". TAG reviews had asked for the bigger picture. Some pieces are far along, but "render" is fairly early, although some folks are interested. Might bring this up at TPAC in WHATWG/WebPerf.

Tess: Is the intent that ends up in WHATWG specs? Is it along the WHATWG Stages process?

Scott: Not yet. Had offline conversations with Anne. Didn't hear objections, but nothing formal has started. Goal is to integrate it into WHATWG: HTML and DOM.

Tess: Worth getting into the WHATWG Stages process sooner than later. TAG is elected, while WHATWG has the expertise.

Scott: There was activity from Anne and Ollie when we asked for standards positions. But +1 on moving to WHATWG.

Martin: 3 threads:

1. yield, which you think is far along and is a candidate for WHATWG.
2. "render" question: I'm convinced that it's good to have it as a central part of the API. I want a replacement for requestAnimationFrame(). Integrate the entire thing, don't just work around the one pole. See if the pole shoudl stay or you need to build something else. Request rendering and react to rendering. I'm equally convinced that the "render" spelling isn't right.
3. This is framework for other parts of the platform. When fetch or another async process wants to put something back into the event loop, they need a framework. That needs more thinking. You won't necessarily build an API for that, but you'll build a framework.

Scott: Prioritization for (3)?

Martin: Yes.

Tess: Like Fetch defines a JS API but also spec hooks, this needs to provide spec hooks.

Martin: Don't expect anything earth-shattering, but need hooks.

Scott: Thought about hooking into Fetch and Message Channels, in the explainer.

Martin: This is one of the m ore useful/fundamental pieces of work that's happened recently. You don't think of setTimeout() because it works, and it's almost enough.

Scott: Yep, until they're not. Like when people use MessageChannel to send a message to themselves.

Scott: Like hooking into rAF, there's overhead.

Tess: We should capture this on the issue.

Scott: If things come up, should I just file an issue?

Tess: Yes.

Peter: Also a Discussions area.

Thanks for doing this work. We see three general threads to this work, each of which are at a different stage, but all of which are worthwhile.

1. The work around basic task scheduling APIs, (yield and wait or whatever those end up being called). This is good stuff. We'd encourage you to take this to WHATWG and get that into their process now. Aside from maybe that open naming issue, it is pretty solid.

2. The work around render and requestAnimationFrame, which deals with how the event loop interacts with the rendering process. That seems less well formed, but still quite important, perhaps even more important than the first item. Having a firm understanding of that interaction and clear means of controlling it would be a significant contribution to stability and performance of sites. We'd encourage you to continue that work to understand that. Please, don't feel constrained by how requestAnimationFrame is; if there are ways in which that could be improved and integrated into a more comprehensive scheduling system, that would be excellent.

3. A general set of hooks that other APIs might use for scheduling work on the main event loop. To give an analogy, Fetch has an API for fetching stuff, but it also has a bunch of hooks that any other API can use if they need to obtain connections or resources. That's a useful contribution here also. For message channels or Fetch or WebRTC or whatever, the ability to schedule and prioritize work will be very useful. That aspect too needs work, but that can be taken to WHATWG also.