[whatwg] Request: window.postMessage should be async

Aaron Boodman wrote:
> Here is one more point on the async vs sync thing.
> 
> In my opinion, one of the most compelling reasons to make an API
> synchronous instead of asynchronous is convenience. This is why I was
> so passionate about having a synchronous database API: getting the
> result of a call via a return value is much simpler conceptually than
> getting it via a callback. I was rightfully proven wrong on this issue
> -- blocking indefinitely on the UI thread is not worth the convenience
> of a procedure-call style interface.

I agree with this very much. Synchronous APIs are a lot easier for 
developers to understand. This was often a pain for us as we were trying 
to get people to write code that was Firefox compatible rather than IE 
only. IE have a lot of APIs that are synchronous and these were much 
preferred by web developers. For example in IE setting 
myScriptElement.src will synchronously load the targeted javascript file 
and execute it. Really excellent for web developers and avoids a lot of 
headache with callbacks and the like.

Similarly we often saw people strongly preferring to do synchronous 
XMLHttpRequest loads rather than asynchronous ones.

The downside, of course, is when that synchronous operation can take a 
long time. This is very much the case when the operation is a network 
request. Similarly it's been argued that database accesses take a long 
enough time that browser responsiveness would suffer if database 
interaction was synchronous.

However, with postMessage I don't think this is the case. The only thing 
that will happen when postMessage executes is that javascript code will 
run. Running javascript synchronous happens all the time, in fact, every 
time you call a javascript function or fire a DOM event. So there is 
certainly precedent for running JS synchronously.

> But as postMessage is currently spec'd, it is synchronous, but it does
> not have the convenience of a procedure-call style interface. If you
> send an iframe a message with postMessage, you don't get the result of
> that message as a return value. You have to hook up a listener and
> wait for it from a separate message.

Yes, the API for the return value is different, though not drastically 
so. It's trivial to set up a listener that modifies a local variable and 
then just grab that local variable once postMessage returns. This is 
especially true if you use the message-pipe mechanism.

> Which brings me back to my previous question: what advantage is there
> to the API being synchronous? We have on one hand authors with reasons
> (however edge casey you may believe them to be) they would prefer the
> API be asynchronous, but I have not heard any reason for it to be
> synchronous. There doesn't seem to be any advantage to it.

The advantage is much simpler communication with other frames if you 
need to send data back and forth a few times.

Peter Kasting brought up the argument that only "toy" code out there is 
able to ignore the stack-depth issue. However most code on the web is 
"toy" code. Copy/pasting code from tutorials or other peoples web pages 
is still a very common thing to do. And will hopefully stay the case 
forever. One of the main strengths with the web is how easy it is to 
create content for it. That's something we can never sacrifice. Yes, we 
certainly should allow and design for google-docs sized web 
applications, but we can't forget the little guy creating his first web 
site using view-source and notepad.

Like Jeff Walden pointed out. Having a synchronous postMessage allows 
for both async and sync communication. The same is not true for the 
reversed.

/ Jonas

Received on Friday, 11 April 2008 14:45:13 UTC