4 ms·

> JavaScript does not require an event loop. It actually does now that Promise got added to the language. For extra fun the interaction of the JavaScript even

> JavaScript does not require an event loop. It actually does now that Promise got added to the language. For extra fun the interaction of the JavaScript event loop and the HTML/DOM event loop is not actually specified and getting it specified will be rather exciting: both sides want to "own" the event loop...

_ZeD_ 11y ago
just to add spice: there is also the CSS loop (with events like hovering and animations and stuff...) that is interesting to handle
- bzbarsky 11y ago
  Hovering is handled via the HTML/DOM event loop, since it needs to be coordinated with mouseover events. Animations, though, do need to be worked into this somehow. And they need to be able to run on a completely independent event loop to some extent so you can do animations on the compositor thread, not the DOM thread.
andrewmcwatters 11y ago
I wonder how that works in practice outside of web environments, considering the spec doc doesn't mention it anywhere. I get the premise of having Promises in the language requiring an event loop, but without one, you'd be creating objects that never get resolved across frames (since they don't exist), which is still entirely possible.
- bzbarsky 11y ago
  The spec doc sort of mentions it: http://www.ecma-international.org/ecma-262/6.0/#sec-jobs-and-job-queues http://www.ecma-international.org/ecma-262/6.0/#sec-jobs-and... and when you initially start up your environment you do http://www.ecma-international.org/ecma-262/6.0/#sec-ecmascript-initialization http://www.ecma-international.org/ecma-262/6.0/#sec-ecmascri... which ends with a NextJob call. So you have to go do a Job. There are various sorts of Jobs, but all of them end their processing steps with a NextJob call. I guess the only issue is that what happens if you have unresolved promises when your Job queues go empty is implementation-defined, because an implementation is allowed to terminate when there are no Jobs. But if it doesn't terminate, resolving the Promise will enqueue a PromiseReactionJob. And I guess not actually call NextJob; that part is up to the implementation.

_ZeD_ 11y ago

just to add spice: there is also the CSS loop (with events like hovering and animations and stuff...) that is interesting to handle

bzbarsky 11y ago
Hovering is handled via the HTML/DOM event loop, since it needs to be coordinated with mouseover events. Animations, though, do need to be worked into this somehow. And they need to be able to run on a completely independent event loop to some extent so you can do animations on the compositor thread, not the DOM thread.

andrewmcwatters 11y ago

I wonder how that works in practice outside of web environments, considering the spec doc doesn't mention it anywhere. I get the premise of having Promises in the language requiring an event loop, but without one, you'd be creating objects that never get resolved across frames (since they don't exist), which is still entirely possible.

bzbarsky 11y ago
The spec doc sort of mentions it: http://www.ecma-international.org/ecma-262/6.0/#sec-jobs-and-job-queues http://www.ecma-international.org/ecma-262/6.0/#sec-jobs-and... and when you initially start up your environment you do http://www.ecma-international.org/ecma-262/6.0/#sec-ecmascript-initialization http://www.ecma-international.org/ecma-262/6.0/#sec-ecmascri... which ends with a NextJob call. So you have to go do a Job. There are various sorts of Jobs, but all of them end their processing steps with a NextJob call. I guess the only issue is that what happens if you have unresolved promises when your Job queues go empty is implementation-defined, because an implementation is allowed to terminate when there are no Jobs. But if it doesn't terminate, resolving the Promise will enqueue a PromiseReactionJob. And I guess not actually call NextJob; that part is up to the implementation.