Re: [ScriptYielding] setImmediate clamping returns.

Le 13/08/2013 01:42, Kyle Simpson a écrit :
>>> 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.
>
> I've read that thread (or parts of it) before.
>
> You still haven't answered why you think setImmediate() has to, unequivocally and inevitably, harm a specific browser inequitably?
I see. I had misunderstood that part. But now I understand it and I have 
already answered. But let's start with a direct answer to your question: 
there is no reason; setImmediate, if equally implemented, cannot harm a 
specific browser inequitably. The insides of the callback are insignificant.

The trouble I forsee may start in what I described as a prisonner's 
dilemma situation.
Let's say all browsers initially implement unclamped setImmediate.
Let's say a high profile website (not demo or benchmark, not actual 
website) makes the function f(){ setImmediate(f); } mistake.
Some users will try different browsers, will realize the websites sucks 
everywhere and say "fuck it, I'm off this phone, I'll check the news 
from my laptop tonight. Not wasting my battery on that website."
But some other users will go to their favorite browser bug tracker and 
file a bug like: "this website is draining my battery just because they 
have a f(){ setImmediate(f); } bug" (this is exactly what happened in 
bug 123273).
The said browser has the following choices:
1) respect the spec that says "do not clamp" and ignore the user bug report
2) address the user concern without breaking the website
2.1) clamping (and they already know how to do that)
2.2) plain stopping to call setImmediate callbacks after some level of 
nesting... uh... no, that breaks websites actually, so no 2.2, my mistake
2.3) ideas?
3) ?

Let's discuss the incentives to choose 1 or 2:
1.1) the browser is a good citizen of the web standards environment, 
respectful of specs to the letter. All that so that a handful of devs 
(which I'm part of) who want high-perf JS can save a few milliseconds 
here and there.
1.2) risk of TechCrunch or equivalent going for "browser X drains people 
battery" (regardless of the fact that other browsers have the exact same 
behavior). We've seen this recently with some dumb article saying that 
Google Chrome has a security flaw [1] even though all browsers have the 
exact same feature.
2.1) making users happy because you solved their problem quickly
2.2) competitive advantage over other browsers (suddenly, other browsers 
drain batteries while yours doesn't. This is the equivalent of the 
high-reward part of being a douchebag in the prisonner's dilemma).

Put every 4 rendering engine makes in this situation. One of them is 
going to crack. The incentives weighs in favor of 2.

I really wish, from the bottom of my heart, that my analysis is deeply 
flawed, that I have missed something crucially important that reverses 
the incentives and that browsers have excellent reasons to never move 
away from not clamping. I do. I want this feature. I want a setImmediate 
of sort. But I want it for good, not for 5 minutes and that some broken 
websites forces to break that feature as it happened with setTimeout 0. 
We'd be back to square one.

Please, find a flaw. Please, make a better, more in depth analysis that 
shows that browsers will keep not clamping.
Really on this one, I really want to be wrong. I really want someone 
comes up with elements I haven't thought of.



>> 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.
> Sure they will. But that doesn't mean that for sure we're in an apples-to-apples situation here. That doesn't mean the way the browsers solved such issues in the past HAS to be how they solve it in the future.
>
> Especially if the spec says "DO NOT CLAMP", I would expect browsers to figure out other ways to fix whatever perceived injustices they are facing in some other way.
"expect browsers to figure out other ways to fix"
No, we're in this together, browser vendors and us (web devs). We need 
to help them "figure out" the solution otherwise, they'll force it on us 
and this is not something that's been to our advantage. They forced 4ms 
clamping on us for nested setTimeout. They had to. That's the reason 
we're even discussing setImmediate.

>> Browsers will be in a prisonner's dilemma
> I don't concede that we're doomed to repeat everything from the past.
We are if we're designing new APIs (setImmediate) exactly like the old 
ones that failed.

> Otherwise, what's the point of trying to push any standards forward? We might as well declare the web finished.
No. We can learn from the past and propose alternative ideas that might 
not lead to the same situations that designs that have proven to fail 
[2]. I don't have made an in-depth analysis of this new design. Maybe 
it's doomed to fail as well. Maybe others have better new design ideas?

David

[1] 
http://www.theguardian.com/technology/2013/aug/07/google-chrome-password-security-flaw
[2] https://mail.mozilla.org/pipermail/es-discuss/2013-August/032630.html

Received on Tuesday, 13 August 2013 00:31:59 UTC