Re: do not deprecate synchronous XMLHttpRequest

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 16:48:51 UTC