"Synchronous XMLHttpRequest outside of workers i..."

[David263]

https://xhr.spec.whatwg.org/commit-snapshots/0d4253c784d2b71ca5bf6648c67f95b82bb8b239/#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 current global object is a Window object. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an "InvalidAccessError" DOMException when it occurs.

====

This note on your website fails to explain why Synchronous Ajax is detrimental.

In my use case, I want to extend JavaScript to support readonly references to the local file system for a tool intended only for local use. Since a file system read operation takes a moment, the user is not even going to see a spinner during that moment. The roundtrip time to a local PHP server using a local webserver is also going to take only a moment.

So in a local JavaScript app, using Synchronous Ajax would be a simple and effective solution to the need to read a local file, avoiding the need to load a potentially large JavaScript library containing Ajax code.

Extending the use case to reading from a database, even a remote one, by adding a spinner seems to me to be an acceptable user experience, in simple cases where the user cannot do anything else in the app anyway until the read operation is done.

If you can counter these use cases, cases where nothing further can be done for the user until the Ajax operation is complete, cases of natural synchronous operation, then perhaps deprecation of Synchronous Ajax is acceptable.

But in any case, even if you are correct, better justification is needed than this vague (and unsupported by evidence) language "has detrimental effects to the end user’s experience".

[annevk]

Basically, if you use synchronous I/O, you block the event loop and the user cannot do anything else, not even click a button if they accidentally started the current operation and want to go elsewhere.

And what might take a moment for you, might take a long time for the user, depending on their environment. File I/O is pretty far from always being fast.

Duping against #20.