[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] psa: battery api: just use all battery

The opponents of this functionality argue (among other things) that it's used in a bad fashion by Uber (surge pricing more to users with low battery) and should therefore be removed.

I believe this to be a spurious argument. Is Uber misbehaving? Yes. But what does it actually say about the value of a battery API? What it says that clearly users are intimately cognizant of their battery status, and that they're willing to spend actual money to preserve it, indicating that they value their battery, and in the case of Uber, they value it so much that they're sometimes statistically significantly more willing to pay a surcharge.

This clearly demonstrates that the battery API has value to users, even when Uber is misusing it.

This value will be vacuumed up when the API is removed. At present this might seem small (it's true, it's rarely used so far), but there's no telling if the future value would be so small. Would we know the value of losing a feature that takes a long while to adopt if it was revoked after a short period of time?

If say WebGL or CSS media queries or flexbox was removed after a short period before anybody had a substantial grip on the technology on the grounds that they're flawed features, what would the value be that was lost? Well clearly we can argue with hindsight that it would be pretty large now, because the hardware accelerated web and the responsive web would barely exist. But could you make that assessment from your armchair before those points where proven?

A short while (mere months) after WebGL was introduced, Microsoft argued that "WebGL is considered harmful" and made allegations of unsuitability of it for the web, and that they would never support it [source: https://blogs.technet.microsoft.com/srd/2011/06/16/webgl-considered-harmful/]. Should WebGL just have given up and be removed then?

Who can tell the exact value of a feature to be removed for the future of the Web if you don't give it appropriate time to be explored? Well clearly in this case, the opponents of this feature make that determination for the entire web. I admire the crystal ball they seem to possess that allows them to accurately predict the future value of a feature.

On Wed, Nov 2, 2016 at 11:07 AM, Cameron Yule <cameron@cameronyule.com> wrote:
Florian, do you have a link to an announcement?

I'd potentially be okay with losing the battery API if the browser had a way to tell my application it's throttling resources for a reason. 

On Wednesday, 2 November 2016, Maksims Mihejevs <max@playcanvas.com> wrote:
Apple always needs to be different and just worse.
Tons of bugs and issues because of their GPU specifics and now they removing API's..

On 2 November 2016 at 01:56, Florian Bösch <pyalot@gmail.com> wrote:
this just in. for the first time mobile (battery driven) browsing overtook power outlet driven browsing. so lets give those meddlesome mobiles a run for their battery life as the most emerging device category... because reasons.

On Wednesday, 2 November 2016, Florian Bösch <pyalot@gmail.com> wrote:
mozilla and apple are removing the battery api that would let performance intensive apps, such as webgl ones, choose a less or more battery intensive mode of operation automatically. they reason "os'es are now good at that stuff."

so just crank your rendering code to max and kill that battery. who needs battery life anyway. its no longer like you could tell you where killing the battery, so dont worry.