Why Is This For Loop Blocking If It Is Called Afterwards?

Why does the div[id=box] not get updated until the for loop finishes? If I comment out the for loop, the div displays instantly. document.getElementById('click').onclick = function

Solution 1:

Simply, ALL browser processes (JS, repainting the page, even responding to user-clicks/key-presses and in most cases refreshes page-changes... even closing the tab) all happen in the same process thread.

Thankfully this isn't 100% true, 100% of the time, anymore. Certain browser-vendors are working to move different parts of the web-platform to different threads, for a smoother experience, but typically, if you lock your JS up, you lock everything.

This simply means that the browser won't actually repaint until JS has finished running, and gives control back to the DOM.

The good news is that it means you can measure elements by unhiding them, grabbing their dimensions and hiding them again, at the end of the function. The width/height that they would take up is calculated on the spot, but a large portion of the page might have to be painted if you change an element, so if it's possible to change 30000 elements in a loop, then painting them all as it happens would be a very bad thing.

Solution 2:

The cause is already explained by others. If you want the box to be painted instantly, the solution is simple. Put the loop in a timeout:

document.getElementById('click').onclick = function() {
  document.getElementById('box').style.display = 'block';
  // no delay anymoresetTimeout( function(){for (var i = 0; i < 2000000000; ++i) {}},10);
};

jsFiddle

Also check web workers

Solution 3:

That amount of iterations running continuously will use up all of the browser's resources and it won't be able to worry with applying styles.

Your javascript is executed in the order it appears there, but behind the scenes there is a queue for rendering style changes. In any normal usage, you wouldn't notice this behavior, but since you're running an poor performant loop, it becomes evident.

Solution 4:

Problem

It's because JavaScript is single-threaded and will only be able to run that loop.

Anything else will be on hold for as long as the loop lasts. As the DOM is wired into the JavaScript the DOM will be blocked as well (in general, except in browsers where DOM runs on a separate thread and will generate an event for the event queue instead which will be on hold until the current executing scope has finished).

Solution

To avoid this you need to split your functions into several asynchronous operations (not the same as multi-threaded) which will enable the browser to invoke some of the events queued up in the event queue (for example paint events).

You can do this by splitting up your function to perform iteration in segments using an inner mechanism to dispatch batches instead.

For example:

Live demo

functionbusyLoop(callback) {

    var segCounter = 0,    /// keep track of segment
        totCounter = 0,    /// keep track of total count
        max = 2000000000,  /// max count
        segment = 1000000; /// segment size (smaller = better response)/// invoke first batch
    (functionnextBatch() {

        segCounter = 0;    /// reset segment counter for each timefor(; segCounter < segment && totCounter <= max; segCounter++, totCounter++) {
           ///...work here...
        }

        if (totCounter < max) {
            /// call setTimeout() which makes it async, +/- 11ms gives browser/// chance to process other events such as paint events:setTimeout(nextBatch, 11);

            /// optional progress callback here
        } elsecallback();
    })();
}

Then call it with a callback function:

busyLoop(doneFunction);

Notice that you can now interact with DOM as well as getting feedback.

Tip: The smaller segments the more responsive the DOM but the longer the total time as the delay in-between accumulates. Experiment to find a balance that suits your solution.

Hope this helps.