W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: do not deprecate synchronous XMLHttpRequest

From: Marc Fawzi <marc.fawzi@gmail.com>
Date: Tue, 10 Feb 2015 09:28:26 -0800
Message-Id: <F5CA8595-7B49-4DBF-8B20-E8902601BA31@gmail.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
To: Michaela Merz <michaela.merz@hermetos.com>
Here is a really bad idea:

Launch an async xhr and monitor its readyState in a while loop and don't exit the loop till it has finished.

Easier than writing charged emails. Less drain on the soul. 

Sent from my iPhone

> On Feb 10, 2015, at 8:48 AM, Michaela Merz <michaela.merz@hermetos.com> wrote:
> 
> No argument in regard to the problems that might arise from using sync
> calls.  But it is IMHO not the job of the browser developers to decide
> who can use what, when and why. It is up the guys (or gals) coding a
> web site to select an appropriate AJAX call to get the job done.
> 
> Once again: Please remember that it is your job to make my (and
> countless other web developers) life easier and to give us more
> choices, more possibilities to do cool stuff. We appreciate your work.
> But must of us don't need hard coded education in regard to the way we
> think that web-apps and -services should be created.
> 
> m.
> 
>> On 02/10/2015 08:47 AM, Ashley Gullen 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
>> <mailto: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____
> 
> 
Received on Tuesday, 10 February 2015 17:29:18 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC