- From: David Bruant <bruant.d@gmail.com>
- Date: Tue, 13 Aug 2013 01:27:50 +0200
- To: Kyle Simpson <getify@gmail.com>
- CC: public-web-perf@w3.org
Le 13/08/2013 01:02, Kyle Simpson a écrit :
> I'll take a stab at part of this.
>
> AFAICT, setImmediate is spec'd to happen *after* the currently waiting events on the queue are exhausted, as soon as possible, which should mean that the UI remains responsive even in a tight setImmediate() loop.
I'm not worried about responsiveness and setImmediate. The way it
politely pulls itself after any other event takes care of that indeed.
> The current debate is: is `function f(){ setImmediate(f); }` really something that would *inequitably* discriminate against one browser and thus force that browser to clamp, and then topple all the dominoes of the other browsers.
Yes, this is *exactly* what happened with Firefox. Bug 123273 is very
instructive on that point. They were inequitably discriminated against
other browsers and were forced to move.
People will make the exact same mistake with setImmediate. This is the
web. Lots of non-techy people write code. This mistake will be made
again. Browsers will have to react as they see modern versions of bug
123273 being filed against their bug trackers.
This mistake will be made again with setImmediate. And I really wish
someone dared to suggest what implementations should be doing.
Browsers will be in a prisonner's dilemma sort-of situation where the
first to make a move gets the reward (being popular for not draining
phone battery on crappy websites).
David
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=123273
Received on Monday, 12 August 2013 23:28:20 UTC