- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 04 Dec 2013 16:38:09 -0800
- To: Ke-Fong Lin <ke-fong.lin@4d.com>, Jonas Sicking <jonas@sicking.cc>, Webapps WG <public-webapps@w3.org>
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.
Received on Thursday, 5 December 2013 00:38:31 UTC