Alex Russell (2013-04-18T11:28:26.000Z)
github at esdiscuss.org (2013-07-12T02:27:00.329Z)
On Thu, Apr 18, 2013 at 8:48 AM, David Bruant <bruant.d at gmail.com> wrote: > Le 18/04/2013 09:40, Anne van Kesteren a ?crit : > >> On Thu, Apr 18, 2013 at 4:07 AM, Tab Atkins Jr. <jackalmage at gmail.com> >> wrote: >> >>> Note that Futures are entirely expressible in today's JS semantics. >>> >>> (Not to say that it shouldn't be reviewed by the language gurus here, >>> just saying.) >> >> JavaScript does not have an event loop (as I mentioned elsewhere) so >> that is not true. HTML defines the event loop model and processing >> model for any asynchronous JavaScript execution. Lifting that up to >> JavaScript seems difficult. > > What do you expect to be difficult? I foresee that it's going to be *a > lot* of work on both sides (W3C/WHATWG & TC39) to move this major piece > from one place to another without breaking anything. I don't think that's true at all. We're never going to be able to standardize on ONE event-loop, nor even be able to require that implementations have them...indeed, we've been pretty careful in designs like Object.observe() to avoid dependencies on it. What we can (and should) do is to say "if you have an event loop, some primitives behave in this way relative to turns". That doesn't require breaking anything. > But I would say it's a lot of "easy" work. It's going to take a lot of > eyeballs and probably tests to make sure what the new spec jonction between > HTML LS and ES7 conforms to what exists in reality (expecially in the new > prose). > Yes, we'll need lots of tests, but the real world gets on fine with event loops and lots of fine-grained, timing-dependent APIs in the web platform today across multiple implementations. We don't have it any harder than any other spec does in that regard.