setImmediate

Domenic Denicola domenic at domenicdenicola.com
Thu Aug 8 07:03:19 PDT 2013


> This is not a "Trying to protect us from ourselves" situation. This is a "browser
> trying to protect users from any sort of abuse" situation. For while loops,
> they implemented the "script takes too long" dialog. For mistakenly infinitely
> nested too short setTimeouts, they implemented 4ms clamping.
> If browsers can't have mitigation strategies when features are abused, we
> will run in the same situations than before.
> 
> As a JS dev, I want the same features than you. Now, how do browsers make
> sure this doesn't drain users battery in case of misuse? (I don't have an
> answer yet)

To me the answer always seemed obvious: use the slow-script dialog. What am I missing? 

> That's what I suggested ("the implementation keeps track..."), isn't it?
> Do we disagree?

I assumed by "implementation" you meant "promise implementation," as in the quoted paragraph. I'd much rather have the browser implementation maintain it.

> I agree and I want "window.asap" asap. But I have the same question about
> misuse and battery. We need to tell implementors how they mitigate
> misuses. Otherwise, they'll just fallback to clamping as they did with
> setTimeout.

Why are implementers OK with giving us postMessage/MessageChannel but not setImmediate? Why are they OK with giving us MutationObservers/Object.observe but not "`window.asap`"?


More information about the es-discuss mailing list