Re: RE : Sync IO APIs in Shared Workers

On Wed, Dec 4, 2013 at 4:38 PM, Charles Pritchard <chuck@jumis.com> wrote:

>
> 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.
>

They help, but there's more that JS can do here to help. Generators/yeild
will help in many cases, and a "async" or "await" keyword can be used to
hide promises entirely in a future version of hte language with annotated
functions. We can do a lot to alleviate the burden even more, and I'm
excited about that future.


> Devs are already in an async world when doing JS.


+1.

I can't speak for the Blink team, but I (sort of obviously) think that sync
APIs in workers are, at best, features destined to get little use and even
less love. Code that uses them won't be portable outside of (specific kinds
(!!!) of) workers, and code that wants to be library-ish will need to add
the async indirection no matter what.

Lastly, while i have sympathy for Jonas' argument about event-loop
concurrency creating thread-like issues as you pile more actors in, the
beauty of Workers is that they largely allow a coordinating document to
decouple actors and give them their own workspaces (workers). That the
problem arises in theory says nothing about how often it will in practice.


>  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.
>
>
>
>