

8.4% of IE9 hangs caused by not using XMLHttpRequest asynchronously - dclaysmith
http://blogs.msdn.com/b/wer/archive/2011/08/03/why-you-should-use-xmlhttprequest-asynchronously.aspx

======
unfletch
For people who only read as far as the "Fixing It" section, this post will
make the problem worse. There's an unfortunate mistake that changes the
meaning to the exact opposite of what was intended:

    
    
        Write your code to call open asynchronously. 
        You need to pass false for the bAsync parameter to the open method...
    

The "bAsync" parameter governs whether the call will _be async_. _True_ (the
default) means async, not false. Oops. At least the examples get it right.

------
AshleysBrain
Why do they run javascript on the UI thread?!

~~~
pak
How would JavaScript be able to override default event handlers if it weren't
tied to the UI thread?

Synchronous XHR will tie up every other browser too--because it's a blocking
call, hence the "synchronous"...

A rare example of appropriate use is an onbeforeunload handler that saves your
work on a webpage when you close the window, because in this case,
asynchronous calls will never complete between the click and the window
unloading so you have to synchronously block the unload event handler. Now, go
post that on this SO thread [1] and make some points ;-)

[1] [http://stackoverflow.com/questions/2088318/is-there-any-
reas...](http://stackoverflow.com/questions/2088318/is-there-any-reason-to-
use-a-synchronous-xmlhttprequest)

~~~
AshleysBrain
Doesn't Chrome run javascript in its own process for each tab's page? How do
they handle overriding default event handlers? Or am I misunderstanding
something?

~~~
pak
Chrome runs a separate process for each tab, and that process includes the
layout engine and the JS engine (V8) running in tandem. V8 has to be able to
block the layout engine from rendering, otherwise it will draw invalid page
states. The execution model (greatly oversimplifying) is that the browser runs
a tight loop that monitors for changes to the DOM state and input events, and
then synchronously executes JS code bound to these events (and the native
handlers if they are not overridden), finally re-rendering parts of the
viewport that become "dirty".

In a browser that isolates tabs into their own processes, like Chrome, try
opening a tab for www.google.com and then enter this in your address bar:

    
    
        javascript:document.getElementById('lst-ib').onclick=function(){while(1);}
    

When you click on the search box the entire tab will freeze, because the tab
process is stuck inside the JS engine running the infinite loop function we
bound to the click handler. It's not a matter of bad browser design, that's
how the JS execution model is intended to work.

"Web workers" is the HTML5 proposal for running JS code that does not block
the event loop. They do not have direct access to the DOM and can only
communicate with JS code in the main event loop via a message passing API.

------
bstar77
I personally have not had a need to use XMLHttpRequest in my 5 years of js
development, so I find it very strange that it accounts for 8% of hangs in IE.
Is there some design pattern MS devs use in javascript causing this problem?

Pretty much every JS framework encourages async requests and managing deferred
objects. Also, why are people still doing JS calls inline and not at the
bottom of the page... or at least on domloaded?

I don't think XMLHttpRequest specifically is the problem, sounds more like a
multitude of poor coding practices that create blocking situations.

~~~
olavk
Another commenter has a legitimate use case for a synchronous XHR:
<http://news.ycombinator.com/item?id=2846258>

Regarding bottom on page, domloaded event etc. - that does not change
anything, the js is still executed synchronously.

------
cpeterso
Havoc Pennington wrote recently about synchronous and asynchronous APIs, with
an interesting analysis of the differences between (synchronous) callbacks and
(asynchronous) events. He suggests that a call­back should be either _always
sync_ or _always async_ , as a doc­u­mented part of the API con­tract.

 _Callbacks, synchronous and asynchronous:_
[http://blog.ometer.com/2011/07/24/callbacks-synchronous-
and-...](http://blog.ometer.com/2011/07/24/callbacks-synchronous-and-
asynchronous/)

------
ams6110
In the early days of AJAX, IE actually had the best support for doing things
like getting some XML data from the server and doing in-browser XSL
transforms. I would often write synchronous calls when there was nothing the
user could really do until the result of the call was obtained and the UI
updated, as it made the code more straightforward and also IIRC the browser
blocked while the transform was happening anyway.

