W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2012

Re: Web Workers

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Mon, 19 Mar 2012 20:33:22 +0200
Message-ID: <CAJhzemX8aJwhysBB2Rd9Rdv6Wo5-JASnCBgfZ4DHx8nOOvLDow@mail.gmail.com>
To: robert@ocallahan.org
Cc: public-audio@w3.org
On Mon, Mar 19, 2012 at 8:28 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Mon, Mar 19, 2012 at 11:59 PM, Jussi Kalliokoski <
> jussi.kalliokoski@gmail.com> wrote:
>> It's possible to hog the main thread from the background tabs without
>> using timers, too, using postMessage or worker communications, and that's
>> even more expensive, but sometimes you need have audio in background tabs
>> as well (music streaming services come first in mind). We can't tell in
>> forehand what it's going to be used for, so I don't see the point in making
>> it harder for the smart developer to do what he wants efficiently to make
>> it harder just so that the less smart one didn't accidentally (especially
>> when it's as unlikely as it is) make his application less efficient than he
>> can. I think being a nanny for developers is a bad idea. This is a case
>> where people are far more likely to know what they are doing than with
>> setTimeout/setInterval, throttling which I don't think was a good idea
>> either.
> I appreciate how frustrating it must be for you and other competent
> developers, but the reality is that as browser developers, catering to
> "average" developers (and preventing them from causing damage) is something
> we have to worry about a lot.
> We have to be careful about logic like "developers who use this API will
> know what they are doing", because it's normal for developers to
> copy-and-paste code that they don't understand and tweak it until it works.

I understand this completely, especially as a user of many unnecessarily
resource-intensive sites. But I think it's better they copy-and-paste
something like a predefined flow for main thread processing, than some
weird hack that's using postMessage timers, virtually using 100% CPU.

Received on Monday, 19 March 2012 18:33:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:49:58 UTC