Abandon hope of removing sync XHR from the web platform?

[foolip]

https://xhr.spec.whatwg.org/#sync-warning

Synchronous XMLHttpRequest outside of workers is in the process of being removed from the web platform as it has detrimental effects to the end user's experience. (This is a long process that takes many years.) Developers must not pass false for the async argument when the JavaScript global environment is a document environment. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an InvalidAccessError exception when it occurs.

There are some Blink use counters for sync XHR:
https://www.chromestatus.com/metrics/feature/timeline/popularity/465 (measure only)
https://www.chromestatus.com/metrics/feature/timeline/popularity/472 (deprecated)
https://www.chromestatus.com/metrics/feature/timeline/popularity/581 (deprecated)
https://www.chromestatus.com/metrics/feature/timeline/popularity/677 (async for comparison)

This does not look at all promising. There's a slight downwards trend, but starting from >2% it's hard to see it dropping to the point where removal is possible.

[foolip]

Some discussion (by me) at https://code.google.com/p/chromium/issues/detail?id=392311#c17

[caitp]

Software developers generally don't like warnings in their terminals (or dev consoles). If they know why they shouldn't use it, they're less likely to ignore it. If warnings show up, their users are slightly more Likely to report issues with their product.

There are good reasons to remove this use pattern from the platform, so folks should not give up on the idea.

[foolip]

At this level of usage, it doesn't seem likely that console warning will be able to drive down usage enough so that sync XHR can be removed. If console warnings is the only tool in our tool box, I think giving up hope is appropriate.

[hallvors]

Probably discussed to death, but if the browser can just keep its UI responsive does it really matter if a script author sometimes makes his/her page freeze by a sync call to an unreliable or slow server?

[glittle]

To me, this is very strange. When I click on a link to go to another page, the browser UI become unresponsive as it goes to get that page.

I have a few cases in my code that I need the browser to wait while it talks to the server using XHR. The user has just clicked a button, and is expecting a short wait.

If I can't do that call synchronously, I'll have to build an artificial approach to freeze the UI until the response is received!

I can live with a "warning" in the developer terminal, but to remove this feature from the spec is going to hurt a lot!

Timeouts can be used to ensure the UI isn't locked for too long!

[marcoscaceres]

@glittle, can you explain how you "need" to pause the browser? Maybe show us some code? It can't be that 98% of other developers don't have this issue, but you do. Can you explain what is so critical in the interaction with the server that the user is forced to not use the browser or the page?

[glittle]

In this case, the call for data is sent down a number of levels, and an answer is expected. If the server call is async, there won't be an answer returned. I can see that that sounds like a bad approach in an async world. I guess I'll have to bite the bullet and redesign each of the levels of code to use async calls, and keep the user entertained while they wait!

[marcoscaceres]

@glittle thanks for the additional details. Best of luck with the refactor! Your users, and local Browser Vendor, will thank you for it :)

In the slim chance you are using ES6, there are ways of keeping your code looking like it's sync, but actually running async (with generators and promises).

[annevk]

@hallvors yes, because the user experience of such an application sucks. Sites need to be motivated to use good practices so they don't become abandonware.

@foolip apart from the desire to remove, anyone using this also should really reconsider. Is the warning really that harmful?

[foolip]

@annevk this is the console warning in Blink with by far the highest usage, around 2%:
https://www.chromestatus.com/metrics/feature/timeline/popularity/581

There's trade-off here, between training web developers to ignore console warnings because they happen too often and for things that aren't actually going to break, and nudging people away from sync XHR even if it will never be removed. 1% would be better than 2%, after all.

What the spec says on the topic (quoted above) goes too far, I think. I don't think sync XHR is "in the process of being removed from the web platform" and no browser will be able to throw InvalidAccessError any time soon. If it were made a bit more tentative like "sync XHR on the main thread is bad for the user experience, browsers please show console warnings and developers please stop using it, if usage is eventually low enough maybe we'll remove it" that would be better.

[annevk]

Given the discussion in https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg232 I guess we can consider alternative wording. I think the wording was based on showModelDialog()...

[shakyjake]

I don't think we'll see a drop off until support for FormData in Web Workers improves (currently only Chrome and Opera support it). Until then there's no real alternative for developers.

[foolip]

That's a connection I was not aware of, which uses of sync XHR can be replaced by FormData in Web Workers?

[shakyjake]

Well I can only speak from personal experience - I'm currently using sync XHR with FormData for a drag & drop file upload system. Async causes issues with script timeouts on the server when uploading multiple large files so I need to keep it synchronous. Web Workers seemed like the ideal solution for this but the poor support for FormData means I can't use it yet.

[foolip]

I'm not sure I understand, does the server timeout not result in an error event in the async case like it should? Is this to work around an implementation bug, or is there something actually broken in the specs here?