Re: do not deprecate synchronous XMLHttpRequest

On Tuesday, February 10, 2015, Marc Fawzi <marc.fawzi@gmail.com> wrote:

> 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


This won't work, state changes are async and long running while loops
result in the hung script dialog which means we'll probably just kill your
page.

The main thread of your web app is the UI thread, you shouldn't be doing IO
there (or anything else expensive). Some other application platforms will
even flash the whole screen or kill your process if you do that to warn
you're doing something awful.


>
> Sent from my iPhone
>
> > On Feb 10, 2015, at 8:48 AM, Michaela Merz <michaela.merz@hermetos.com
> <javascript:;>> 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 <javascript:;>
> >> <mailto:george.calvert@loudthink.com <javascript:;>>> 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____
> >
> >
>
>