Re: RE : Sync IO APIs in Shared Workers

I totally agree, this is the kind of things I said several weeks ago
about why we shouldn't promote the development of sync APIs on
workers, and stick only with the same async APIs from the main thread.

2013/12/5 Charles Pritchard <chuck@jumis.com>:
>
> On 12/4/13, 2:43 AM, Ke-Fong Lin wrote:
>>
>> IMHO, we should make sync APIs available in both dedicated and shared
>> workers.
>> In order of importance:
>>
>> 1) Sync APIs are inherently easier to use than async ones, and they are
>> much
>> less error prone. JS developers are not C++ developers. Whenever possible,
>> it's
>> just better to make things more simpler and convenient.
>
>
> This argument is not particularly helpful. Apart from that, many JS APIs use
> callbacks,
> all developers are-or-have to be aware of them.
>
>> 2) Sync APIs do the job. We are talking about web-apps, not heavy load
>> servers.
>> High performance applications will use async APIs anyway. I'd rather think
>> there
>> are a lot of use cases where the dedicated or shared worker would do a lot
>> of small
>> and short duration work, suitable for sync coding. Why force the
>> complication of async
>> on developers ? If easy things can be done easily, then let it be.
>
>
> Promises seem to have solved quite a it of the syntactic cruft/issues.
> Devs are already in an async world when doing JS.
>
>> 3) It does no harm.
>
>
> It's not particularly fun re-writing async methods from the webpage to be
> sync for workers, or otherwise using shims to avoid redundancy. The extra
> semantic load on the namespaces (docs and otherwise) isn't all that pleasing
> either. There is a cost.
>
>
>



-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux

Received on Thursday, 5 December 2013 08:38:42 UTC