[whatwg/xhr] Why do we need to remove synchronous XHR? (Issue #336)

I don't understand why there's such a strong push to get rid of sync XHR.  For developing simple local web applications, network latency isn't an issue, and there's no need to introduce race conditions associated with the user being able to interact with the web page while a request is in flight, which is by definition what async XHR introduces.

Also, the assumption we seem to be operating under is that developers aren't accounting for network latency and how that poorly impacts UX (and I agree that's likely true for most cases).  Are we assuming that just because they now use this async flag that they're testing their page on high latency networks? If we're already assuming that the developer didn't account for the case of high latency, I'd also venture to say they didn't test running some number of arbitrary concurrent actions which weren't realistic to make concurrent on fast networks, but now that the network is slow, the user can click new buttons while a request is processing, and scripts could get into a bad/unexpected state.  Personally, I think a slow page on a slow network is better than an unpredictable one with functional problems. Not to mention removing sync XHR will break existing pages utilizing the current state that meets their needs.

Is there really a need to remove sync XHR, or more broadly what are our goals with this effort? You can probably sense that I think this is idealistic, and I know that people have the best intentions with this effort in an attempt to help developers make better web pages, so I don't want to give any impression that I'm taking a stab.

I think async XHR is a great thing that enables developers to take on some coding complexity to make a more responsive UI that can do certain actions that make sense while a request is in flight, but it's a serious decision to be made if that added complexity is worthwhile for the use case at hand.  Sure, you can probably argue that async is always as good or better than sync assuming you've done the work of synchronizing conflicting tasks on your web page, but the benefit of putting that time in isn't always the most important thing a developer should be working on when there are other unmet needs that have _no_ solution, yet, and could get more attention if less time needed to be spent on synchronizing concurrency.

-- 
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/336