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 got
> a message on the Firefox browser console: "Synchronous XMLHttpRequest on the
> 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 <col>
> 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 all
> 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 is
> completed SUCCESSFULLY or the database will be corrupted
> 3. The final SQL acts as the "commit" for the whole shebang and has its own
> BEGIN TRANSACTION and COMMIT/ROLLBACK for safety
>
> In this case, synchronous xmlHttpRequests are not only NOT deprecated, they
> are ABSOLUTELY ESSENTIAL to provide reliable database updating for the end
> 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 matter
> 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.)

~TJ

Received on Thursday, 31 July 2014 22:47:50 UTC