- From: Darin Adler <darin@apple.com>
- Date: Sat, 15 Dec 2007 18:09:39 -0800
On Dec 15, 2007, at 6:00 PM, Benjamin West wrote:
> I suspect that for most typical uses on most typical runtimes, most
> developers would choose to risk the performance hit of synchronous
> access to the complexity of binding methods to their objects. I
> suspect this allows faster prototyping with a migration to more
> robust and flexible code, as well. It would be great if there was a
> way to measure this.
Experience at Apple with Dashboard widgets suggests that many
developers will use the synchronous version, not be aware an
asynchronous version exists, and be mystified by reports of hangs or
blame the hangs on the operating system. This is currently happening
with the widget.system function offered by Dashboard JavaScript as
well as with the synchronous form of XMLHttpRequest.
While it's hard to measure this phenomenon, we know it's happening a
lot because of the hang reports that we get direct from some customers
from the Apple tool called Spin Tracer and it's a regular point of
confusion with developers on the Dashboard development list. Some
developers have said things like, "The code is running in a setTimeout
(or XMLHttpRequest) callback function so there's no way using a
synchronous call could affect user interface responsiveness."
Unlike the hypotheticals in this thread, in most of the cases
discussed on the Dashboard developer mailing list, conversion to an
asynchronous model would be trivial.
On the other hand, I agree that doing complex operations with an
asynchronous callback model is inconvenient. Doing the same thing with
threading is also difficult, but the difficulty arises in different
ways.
But synchronous calls without threading are simply not good enough for
software that's going to be used by people other than the ones writing
it.
-- Darin
Received on Saturday, 15 December 2007 18:09:39 UTC