On Tue, Jul 29, 2014 at 1:41 PM, <nmork_consult...@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