Re: [xhr] Abandon hope of removing sync XHR from the web platform? (#20)

In my particular case, I’m using a 3rd-party date-time-timezone widget.  On
init, I can supply it with a “get current time” callback that is supposed
to return the current date/time/timezone (for when the “Now” button inside
the widget is pressed).  The widget takes care of updating the DOM to
reflect the new date/time (calendar, sliders, dropdowns, etc).



Here’s what pushed me towards async: false:



·         Have to get “now” time from server since I can’t trust the user’s
system time to be correct.

·         Have to handle timezone stuff server-side since JS Date object
timezone handling is very poor.

·         Could re-init control every time the user presses the “Now”
button, but that would make it necessary to save the full state of the
control (size, position, etc) and restore it on re-init (which is doable,
but much more trouble than setting async to false, and introduces flicker,
and may duplicate-create certain DOM elements that have to be cleaned up).

·         Could alter the 3rd-party widget’s code to pass a continuation to
the “get current time” callback so that the remaining work can be postponed
until after the async time request has finished, but then I have diverged
from upstream.

·         Could make a synchronous call to the server to get the current
time/date for a given timezone inside the “get current time” callback, and
return a date without having to change 3rd-party code.  No stalls, no
unresponsiveness, completely indistinguishable from async from the user’s
perspective.



>From a little web research, it seems as though async: false is used a lot
for file-upload scenarios and browser-based desktop-style applications.



https://bugs.jquery.com/ticket/11013

https://core.trac.wordpress.org/ticket/33349



I’m a little fuzzy on the rationale for getting rid of this feature (aside
from it blocking the main thread and not being the most desirable
practice).  Can anyone point me to a deeper discussion on why this has to
go?



*From:* Philip Jägenstedt [mailto:notifications@github.com]
*Sent:* Monday, March 21, 2016 2:33 AM
*To:* whatwg/xhr
*Cc:* Jason Stewart
*Subject:* Re: [xhr] Abandon hope of removing sync XHR from the web
platform? (#20)



@BourgeoisBear <https://github.com/BourgeoisBear>, there isn't a shared
WHATWG stance on this, I'm involved in the WHATWG and filed this issue
precisely because I doubt that usage can drop by enough, at least unless
there are additional efforts to understand and drive down usage.

It's interesting that you mention 3rd party libraries, which seems to have
been the problem in #20 (comment)
<https://github.com/whatwg/xhr/issues/20#issuecomment-187188271> as well.
What do the details here look like? Are those 3rd party libraries using
document.write, so that some init data for them is fetched using sync XHR?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
<https://github.com/whatwg/xhr/issues/20#issuecomment-199156883>


---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/xhr/issues/20#issuecomment-199169326