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.
