[whatwg] Asynchronous database API feedback

[Darin Adler]

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