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

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 UTC