Re: do not deprecate synchronous XMLHttpRequest

Given implementations already support synchronous behavior, the only reason
to deprecate would be if continuing to support that behavior comes at a
significant burden to future versions of these implementations. I would
conjecture it is not, so I oppose deprecation on the principle that policy
should be determined by the user/author, not the standard.

Morality should not be legislated!


On Tue, Feb 10, 2015 at 7:47 AM, Ashley Gullen <ashley@scirra.com> wrote:

> I am on the side that synchronous AJAX should definitely be deprecated,
> except in web workers where sync stuff is OK.
>
> Especially on the modern web, there are two really good alternatives:
> - write your code in a web worker where synchronous calls don't hang the
> browser
> - write async code which doesn't hang the browser
>
> With modern tools like Promises and the new Fetch API, I can't think of
> any reason to write a synchronous AJAX request on the main thread, when an
> async one could have been written instead with probably little extra effort.
>
> Alas, existing codebases rely on it, so it cannot be removed easily. But I
> can't see why anyone would argue that it's a good design principle to make
> possibly seconds-long synchronous calls on the UI thread.
>
>
>
>
> On 9 February 2015 at 19:33, George Calvert <george.calvert@loudthink.com>
> wrote:
>
>> I third Michaela and Gregg.
>>
>>
>>
>> It is the app and site developers' job to decide whether the user should
>> wait on the server — not the standard's and, 99.9% of the time, not the
>> browser's either.
>>
>>
>>
>> I agree a well-designed site avoids synchronous calls.  BUT — there still
>> are plenty of real-world cases where the best choice is having the user
>> wait: Like when subsequent options depend on the server's reply.  Or more
>> nuanced, app/content-specific cases where rewinding after an earlier
>> transaction fails is detrimental to the overall UX or simply impractical to
>> code.
>>
>>
>>
>> Let's focus our energies elsewhere — dispensing with browser warnings
>> that tell me what I already know and with deprecating features that are
>> well-entrenched and, on occasion, incredibly useful.
>>
>>
>>
>> Thanks,
>> George Calvert
>>
>
>