Re: RE : RE : Sync IO APIs in Shared Workers

fOn Thu, Dec 5, 2013 at 2:14 AM, Ke-Fong Lin <ke-fong.lin@4d.com> wrote:

> >> 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.
>
> Yes, JS web developers are well used to that.
> Yet, sync APIs are simpler and much less error prone.
>

It's unclear that they're less error prone. It's clear that they're easier.

For instance, the cases I bring up in the post which Jonas cited are
instances where, when presented with "small" amounts of data or work,
synchronous APIs may indeed be "correct" and easy. But when the data scales
up to some amount (a fuzzy line at best), they become attractive nuisances;
things which you must then teach developers not to use lest they screw up
the end-user experience -- which, on the client, is really the only thing
that matters.


> If something easy can be done easily, do it the easy way.


And if that something can't be "correct" or easily proven to be so, we
should stop offering error-ish-prone ways of doing that thing.


> >> 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.
>
> You may well use the "usual" async version of the API in a worker.
> In which case, there is no need for re-writes.


...assuming you're only ever porting code from a document to a worker and
not the other way around. I think this hopelessly naive.