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

I was going through this whole discussion to point where i thought adding my 2 cents worth is right. I think this message about deprecation and the actual deprecation should just be removed. Browsers should be coded not to freeze over this simple issue. I have never seen browser source code before to know what's going on in there, but I think this should be solved in the browser js engine not in the scripts being run. I was thinking why not multi-thread the browser? There are situations that cannot be solved with async/promises etc at all. consider this;

An app loads its scripts through webpack and some through async calls as required during runtime. The app wants to load a settings script from the server and those settings are to be used by various areas of code almost immediately after the settings request has been done. The catch is that this settings file cannot and shouldn't be bundled up into the webpack bundle file since these are settings that can be changed by other clients during runtime, then when the app reloads next time it has to use those new settings. Most of this code is modular and cannot be put in a single resolve function of promises as js would have just moved on deeper into the code. However, letting the code continue further without waiting for the settings will break it as there is no way of telling when the settings will arrive from the server. The only way is to wait for the response and then continue or throw an error after a timeout (because this file has to be there and exactly when needed)... hence sync XHR. 

This is a scenario I have faced and was actually looking for another solution offered by anything else outside of sync XHR. I tried refactoring the code several times using promises and most other methods and they never worked as effectively and simple as sync XHR requests. Throughout the code there is use of promises, async ... await, generators etc, but they don't work for this one scenario in the codebase. By trying to use these other methods has proven wasteful of valuable time and effort on unnecessary complicated and unsatisfactory trials, meanwhile knowingly ignoring the only solution that works perfectly without the detrimental effects being reported in the console.

So I am wondering why this would be removed at all. The page works fine without any detrimental effects as in the doomsday warning message being thrown in the console. 

To my point of view, if this problem is inherent of javascript, then the language is poorly designed, and removing this simply makes it worse. Async await is actually a way of trying to mitigate this, howbeit, it encapsulates the code in a function again, which is the same as promises. I think the people who threw this in were actually trying to solve this, but i don't know how or where they lost it. They ended up doing the same this over. I don't think there is anything you can do with async await that you can't do with regular promises... But there is one thing you can't do with promises that you can do with sync XHR and that's wait for a response from the server before you continue with execution.

-- 
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-313657110