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

@foolip:

The sync XHR call is inside the "get current time" callback that I provide to the widget.

The page is long-lived.  The time polling idea is close.  Minor drawback is that the server will have to constantly source multiple polls--instead of sourcing singles on an as-needed basis.  Major drawback is that the "now" call takes the user-selected time zone as an input (like America/Pacific), and the server returns "now" in that time zone.  If I polled in UTC and cached it, I would have to do time zone conversion client-side.  JS native date/time facilities are anemic, so I'd have to pull in another dependency ([moment.js](http://momentjs.com/) or the like).  Still far less elegant than setting async to false.

If the sole problem we're trying to solve here is excessive blocking in the rendering thread, why does it have to be something as drastic as full removal?  Putting a tighter ceiling on the timeout would have the same effect, wouldn't break as much code, and would give the developer an opportunity handle the timeout gracefully.  It couldn't possibly be as bad as just silently ignoring the async flag so that things which were originally developed to run synchronously mysteriously stop doing so.

---
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-199233396