W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: =[xhr]

From: <nmork_consultant@cusa.canon.com>
Date: Fri, 1 Aug 2014 09:15:55 -0400
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: public-webapps <public-webapps@w3.org>
Message-ID: <OF822C364D.7CC3E308-ON85257D27.00482978-88257D27.0048DEB8@cusa.canon.com>
In this case, a freeze on all browser operations is desirable.  The thread 
cannot be interrupted, and if it is interrupted (by browser closure or 
other such) then the transactions are immediately stopped and no update 
will occur (this is the most desirable outcome.)  Async is not desirable, 
since it gives control back to the browser and the user has a false 
impression that interaction may be ok or even desirable.  In this case it 
is not, it is an all stop until complete requirement.  I use both async 
and sync xmlhttprequests, and they both have their place.  Please do not 
deprecate sync requests simply because you cannot imagine where they would 
be desirable.  When they are needed, they are ABSOLUTELY needed and async 
requests are not only NOT desirable, but can lead to potentially 
disastrous results.

From:   "Tab Atkins Jr." <jackalmage@gmail.com>
To:     nmork_consultant@cusa.canon.com, 
Cc:     public-webapps <public-webapps@w3.org>
Date:   07/31/2014 03:47 PM
Subject:        Re: =[xhr]

On Tue, Jul 29, 2014 at 1:41 PM,  <nmork_consultant@cusa.canon.com> wrote:
> While debugging an intranet application using xmlHttpRequest recently, I 
> a message on the Firefox browser console: "Synchronous XMLHttpRequest on 
> main thread is deprecated because of its detrimental effects to the end
> user's experience."
> This worries me, since many useful web browser features which are
> "deprecated" eventually disappear (e.g. CSS width specification in the 
> tag.)

This is definitely one of those things.

>  I have an application which makes many http requests to make multiple
> large updates to database work tables, finally running a single SQL
> xmlHttpRequest to copy all work table data to the main data tables after 
> updates are successful.
> 1. The volume and size of the data is too large to be sent by a single
> request
> 2. Each subsequent request cannot be submitted until the prior request 
> completed SUCCESSFULLY or the database will be corrupted
> 3. The final SQL acts as the "commit" for the whole shebang and has its 
> In this case, synchronous xmlHttpRequests are not only NOT deprecated, 
> are ABSOLUTELY ESSENTIAL to provide reliable database updating for the 
> user, and reliability is what the end user most desires, in addition to
> IMMEDIATE FEEDBACK whether the update succeeded or not.

None of what you have described requires a synchronous XHR; it can all
be done with async XHR.  You just wait to send the subsequent batches
of data until the listener from the previous one informs you that it
has succeeded.  This is slightly more complicated than doing sync, but
no slower (and possible faster, if some of them can be done in
parallel), and just as reliable.

You get feedback exactly as quickly, modulo a millisecond or two of
accumulated delay from waiting for your listener to reach the top of
the message queue.

Your users get a vastly better experience out of it, too.  Synchronous
XHR freezes the JS main thread until it returns, which means that any
interaction with the page is frozen too.  (Users *might* be able to
scroll, if the browser is doing scrolling on another thread, but
that's about it.)  Multiple large consecutive sync XHRs mean things
are frozen for a noticeable amount of time, especially if the network
is slow for whatever reason.  Async XHR has none of this problem.

The last person on this list to assert that they absolutely needed
sync XHR didn't seem to understand what async XHR was.  (They seemed
to think it was related to form submission; I don't know what you
think it is.)  It's exactly identical to sync XHR, but rather than
freezing javascript until the response comes back, and giving you the
result as a return value, you just have to register an event listener
which'll get called when the response comes back, passing the result
as an argument to your callback.  Spreading your logic across
callbacks is a little bit more complicated than doing sync code, but
it's a necessary part of tons of JS APIs already, so if you're not
familiar with how it works, you're gonna have to get familiar with it
really soon. ^_^

> Also, unrelated, please bring back CSS width to the <col> tag.  On very
> large data tables, this can reduce page downloads by megabytes, no 
> how small you make your column class names.

Rather than putting classes on your <td>s, you can just use better
selectors.  If you need to set the width of the cells in the second
column, you can just do `td:nth-child(2) { width: XXX; }`.  Save
yourself a couple megabytes. ^_^

(This isn't *precisely* reliable, because it doesn't know about
rowspans/colspans, but you can often deal with that yourself.
Selectors level 4 adds an :nth-column() pseudo-class which is
identical to :nth-child(), but only works on table cells and knows
about rowspans and colspans, so it'll properly style everything in the
desired column no matter how the table is structured.)

Received on Friday, 1 August 2014 13:16:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC