[whatwg] Request: window.postMessage should be async
jonas at sicking.cc
Fri Apr 11 14:45:13 PDT 2008
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
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
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
More information about the whatwg