Re: [whatwg/xhr] Abandon hope of removing sync XHR from the web platform? (#20)

As many have already mentioned, there are rare, but legit use cases for sync xhr that have no alternative solutions as of now. In an ideal world, everything, including browser api, will be async. But until then, and during transition, there should be possibly dangerous or unsafe solutions for real world cases. 

I have been involved in optimizing other people's applications for a long time. In many cases, even if the app developers want to follow best practices themselves, they cannot easily influence the behavior third party libraries they need. Which makes transition to better api very hard.

What I have noticed in most cases is this: although the JS itself is single threaded, it still sometimes need to synchronize with external events. In a web app, we run into a lot of non-deterministic elements such as state of the browser cache, network behavior, user behavior ...; which make optimizations hard. 

In general, we can have aggressive solutions that rely on common case scenarios, but have a fall back mechanism for correctness. In these cases, we need a mechanism to pause the execution of the JS "without unwinding the whole call stack" and un-pause when some event happens. This is equivalent to the necessary evil "wait-on" mechanism in other languages or platforms. To discourage casual usage, we can make it hard to use, e.g. require explicit api for taking a snapshot of call stack, and then explicitly restoring it at the beginning of the event handler. 

As of now, sync XHR is **the only** available mechanism for simulating this behavior. Unfortunately, the "wail-on" feature of sync XHR is mixed up with network activity. I think if these two were separated, a lot of current legit use cases for sync xhr would go away, or can be re-implemented with some effort.




-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/xhr/issues/20#issuecomment-302994760

Received on Monday, 22 May 2017 04:09:38 UTC