Please keep in mind that multiple web apps share the same main thread. While browser's can keep their own UI responsive in the face of synchronous XHRs, they cannot do the same for other web app, which may share their main thread with a web app that uses synchronous XHR. Unfortunately, the web platform is a cooperatively multi-tasking system :-(
This applies even to browsers like Chrome that create multiple processes. There you can still end up with unrelated web apps in the same process, sharing the same main thread. Now, I have to admit that I'm quite sympathetic to your concerns. I think it is always bad form for a platform to give an API and then take it away. At least one nice thing about switching to async XHRs is that you can now display a progress meter to your users. There's no telling how long a network load may take afterall. Regards, -Darin On Thu, Jan 26, 2012 at 7:47 PM, Mark Callow <callow_m...@hicorp.co.jp>wrote: > 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? > > Regards > > -Mark > >
