Need Discussion of 'why' Behind Deprecation of sync xhr

[gulachek]

I see all over the internet that synchronous XMLHttpRequest is deprecated because it has "detrimental effects" to the user experience. I have often searched for discussions of why, but I don't think I've ever seen any authoritative discussion behind this deprecation, what exactly is detrimental about synchronous requests, and how async solves this problem. I think the XHR standard should link to such a discussion to provide better guidance to web developers.

Let me explain why I think an authoritative discussion is necessary: from my perspective, the best I can glean for why sync xhr is detrimental is because, on a slow network connection, the web page is going to hang. Is that the gist of it? Let's take a look at two example web pages:

1. An article employs xhr polling to update a newsfeed. The user is primarily concerned about reading the content of the article, and might be interested in the newsfeed that's dynamically updated. In this scenario, the XMLHttpRequest should absolutely be async. If the user successfully downloaded the main content of the article, then the user shouldn't be punished by a slow network and should be able to scroll through the article to read the content.

2. An online documentation editor is created in a dynamic single page application. Users on this web page click buttons to perform complex documentation tasks that require a trip to the web server to validate/save, but under normal network conditions, an entire page render is too expensive, so an XMLHttpRequest is used. Now the network is slow. Should the XHR be synchronous? Either way, the user is going to have to wait for the request to complete to perform the primary task of his job on the webpage. If we pretend that the network connectivity isn't a problem and make the request async, at what point are we making a worse user experience by allowing the user to interact with the page and queue up endless actions? Do we expect users to not start spam clicking when buttons are interactive and requests are in flight? If the user clicks a huge series of buttons, do we expect the user actually wanted every action to trigger, or was the user just frustrated that the page was slow and we're risking allowing the user to make a mistake? Should the web developer reinvent trying to make things synchronous by making the webpage inert and preventing further user interactions while the web server is busy? Why is that better than a synchronous request? Are there recommendations for how to tackle a problem like this?

It's likely apparent in my second example that I'm concerned that we're told that the UX of blocking the user is detrimental, but I think there's a lack of guidance for how a better UX should be designed for very common cases such as dynamic single page applications that are writing information to a database instead of simply presenting readonly content to the user. It seems inevitable to me that a slow network connection is going to make for a frustrating user experience on a web page, and we can't always fool a user to think that the page is actually responsive. It seems like at some point we need to allow the web server to catch up and block the user, but following that line of thinking, if we recreate a "synchronous request" by making the page inert to the user while the async request is in flight, is that the same "detrimental" experience? How are we supposed to design that differently? Perhaps there's still benefit if there is more work on the js stack to allow the browser and server to do work in parallel with an async request, but that doesn't seem like the main concern of making everything async. I'm just very confused on what is envisioned as a good UX in this situation. Without formal guidance from the same authority that says "blocking the user is bad" (I think?), if it seems like at some point we really do need to block the user even during an async request, it seems like we're working around the warning message instead of the root problem of "blocking the user is bad", unless I'm misunderstanding what the recommendations are, which brings me back to needing the "why".

Please let me know if my concerns are unclear and if I can provide more information. This has been a question of mine for years.

[annevk]

If you're really completely blocked on the server you could show a spinner. The point is that synchronous XMLHttpRequest doesn't give you UI. Variations of this have been discussed to great extent in #20 and its numerous duplicates.

[gulachek]

I don't know how many times I've read through all of the comments on that chain over the past few years but I don't see anywhere on that chain that discusses better alternatives. Would you save time responding to all of these issues over the past 8 years if we just had better discussion of the topic in formal documentation instead of invalidating people's honest inquiries?

…

On Fri, Mar 17, 2023 at 13:44 Anne van Kesteren ***@***.***> wrote: If you're really completely blocked on the server you could show a spinner. The point is that synchronous XMLHttpRequest doesn't give you UI. Variations of this have been discussed to great extent in #20 <#20> and its numerous duplicates. — Reply to this email directly, view it on GitHub <#371 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALOZK3TMFAJ5FTXXFS7C4BLW4SWHTANCNFSM6AAAAAAV62TOEE> . You are receiving this because you authored the thread.Message ID: ***@***.***>