W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: [xhr] responseType for sync requests in window context

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 27 Jan 2012 14:42:11 -0800
Message-ID: <CAAWBYDAegZE06Aqj3nJJoiwFVGN6PyGHNnn2EAObEaSTa_xP=Q@mail.gmail.com>
To: Mark Callow <callow_mark@hicorp.co.jp>
Cc: public-webapps@w3.org
2012/1/26 Mark Callow <callow_mark@hicorp.co.jp>:
> I do not think you should be in the business of brute-forcing authors into
> converting their applications to use async XHRs. As far as I understand it,
> it is the application's UI that may be unresponsive during a sync XHR. In
> that case it should be the app. authors choice which to use. If it is the
> browser's UI, that is a bug in the browser.
>
> Since this change principally affects WebGL app's it would have been nice of
> someone to have mentioned this change in the public-webgl mailing list while
> it was still at the proposal stage.
>
> For the record the change has broken all our WebGL applications. Forcing us
> to jump through the hoops of using async XHRs is going to have zero impact
> on the user experience in our case because the 3D itself is the UI. Until
> its loaded there is nothing the user can do.
>
> If sync XHRs are so bad, why to they exist?

Sync XHR was designed first, before we all collectively came to the
realization that blocking the main thread is a horrible horrible idea.
 We're doing our best to kill it, by doing precisely the sort of
things you're complaining about.  ^_^

~TJ
Received on Friday, 27 January 2012 22:42:59 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT