Why is setTimeout fn 0 sometimes useful

Question

I ve recently run into a rather nasty bug  wherein the code was loading a  lt select gt  dynamically via JavaScript   This dynamically loaded  lt select gt  had a pre-selected value   In IE6  we already had code to fix the selected  lt option gt   because sometimes the  lt select gt  s selectedIndex value would be out of sync with the selected  lt option gt  s index attribute  as below   field selectedIndex   element index    However  this code wasn t working   Even though the field s selectedIndex was being set correctly  the wrong index would end up being selected   However  if I stuck an alert   statement in at the right time  the correct option would be selected   Thinking this might be some sort of timing issue  I tried something random that I d seen in code before   var wrapFn    function         var myField   field      var myElement   element       return function             myField selectedIndex   myElement index              setTimeout wrapFn  0     And this worked   I ve got a solution for my problem  but I m uneasy that I don t know exactly why this fixes my problem   Does anyone have an official explanation   What browser issue am I avoiding by calling my function  later  using setTimeout

User · Answer

Both of these two top-rated answers are wrong. Check out the MDN description on the concurrency model and the event loop, and it should become clear what's going on (that MDN resource is a real gem). And simply using setTimeout can be adding unexpected problems in your code in addition to "solving" this little problem.

What's actually going on here is not that "the browser might not be quite ready yet because concurrency," or something based on "each line is an event that gets added to the back of the queue".

The jsfiddle provided by DVK indeed illustrates a problem, but his explanation for it isn't correct.

What's happening in his code is that he's first attaching an event handler to the click event on the #do button.

Then, when you actually click the button, a message is created referencing the event handler function, which gets added to the message queue. When the event loop reaches this message, it creates a frame on the stack, with the function call to the click event handler in the jsfiddle.

And this is where it gets interesting. We're so used to thinking of Javascript as being asynchronous that we're prone to overlook this tiny fact: Any frame has to be executed, in full, before the next frame can be executed. No concurrency, people.

What does this mean? It means that whenever a function is invoked from the message queue, it blocks the queue until the stack it generates has been emptied. Or, in more general terms, it blocks until the function has returned. And it blocks everything, including DOM rendering operations, scrolling, and whatnot. If you want confirmation, just try to increase the duration of the long running operation in the fiddle (e.g. run the outer loop 10 more times), and you'll notice that while it runs, you cannot scroll the page. If it runs long enough, your browser will ask you if you want to kill the process, because it's making the page unresponsive. The frame is being executed, and the event loop and message queue are stuck until it finishes.

So why this side-effect of the text not updating? Because while you have changed the value of the element in the DOM — you can console.log() its value immediately after changing it and see that it has been changed (which shows why DVK's explanation isn't correct) — the browser is waiting for the stack to deplete (the on handler function to return) and thus the message to finish, so that it can eventually get around to executing the message that has been added by the runtime as a reaction to our mutation operation, and in order to reflect that mutation in the UI.

This is because we are actually waiting for code to finish running. We haven't said "someone fetch this and then call this function with the results, thanks, and now I'm done so imma return, do whatever now," like we usually do with our event-based asynchronous Javascript. We enter a click event handler function, we update a DOM element, we call another function, the other function works for a long time and then returns, we then update the same DOM element, and then we return from the initial function, effectively emptying the stack. And then the browser can get to the next message in the queue, which might very well be a message generated by us by triggering some internal "on-DOM-mutation" type event.

The browser UI cannot (or chooses not to) update the UI until the currently executing frame has completed (the function has returned). Personally, I think this is rather by design than restriction.

Why does the setTimeout thing work then? It does so, because it effectively removes the call to the long-running function from its own frame, scheduling it to be executed later in the window context, so that it itself can return immediately and allow the message queue to process other messages. And the idea is that the UI "on update" message that has been triggered by us in Javascript when changing the text in the DOM is now ahead of the message queued for the long-running function, so that the UI update happens before we block for a long time.

Note that a) The long-running function still blocks everything when it runs, and b) you're not guaranteed that the UI update is actually ahead of it in the message queue. On my June 2018 Chrome browser, a value of 0 does not "fix" the problem the fiddle demonstrates — 10 does. I'm actually a bit stifled by this, because it seems logical to me that the UI update message should be queued up before it, since its trigger is executed before scheduling the long-running function to be run "later". But perhaps there're some optimisations in the V8 engine that may interfere, or maybe my understanding is just lacking.

Okay, so what's the problem with using setTimeout, and what's a better solution for this particular case?

First off, the problem with using setTimeout on any event handler like this, to try to alleviate another problem, is prone to mess with other code. Here's a real-life example from my work:

A colleague, in a mis-informed understanding on the event loop, tried to "thread" Javascript by having some template rendering code use setTimeout 0 for its rendering. He's no longer here to ask, but I can presume that perhaps he inserted timers to gauge the rendering speed (which would be the return immediacy of functions) and found that using this approach would make for blisteringly fast responses from that function.

First problem is obvious; you cannot thread javascript, so you win nothing here while you add obfuscation. Secondly, you have now effectively detached the rendering of a template from the stack of possible event listeners that might expect that very template to have been rendered, while it may very well not have been. The actual behaviour of that function was now non-deterministic, as was — unknowingly so — any function that would run it, or depend on it. You can make educated guesses, but you cannot properly code for its behaviour.

The "fix" when writing a new event handler that depended on its logic was to also use setTimeout 0. But, that's not a fix, it is hard to understand, and it is no fun to debug errors that are caused by code like this. Sometimes there's no problem ever, other times it concistently fails, and then again, sometimes it works and breaks sporadically, depending on the current performance of the platform and whatever else happens to going on at the time. This is why I personally would advise against using this hack (it is a hack, and we should all know that it is), unless you really know what you're doing and what the consequences are.

But what can we do instead? Well, as the referenced MDN article suggests, either split the work into multiple messages (if you can) so that other messages that are queued up may be interleaved with your work and executed while it runs, or use a web worker, which can run in tandem with your page and return results when done with its calculations.

Oh, and if you're thinking, "Well, couldn't I just put a callback in the long-running function to make it asynchronous?," then no. The callback doesn't make it asynchronous, it'll still have to run the long-running code before explicitly calling your callback.

User · Answer

There are conflicting upvoted answers here  and without proof there is no way to know whom to believe  Here is proof that  DVK is right and  SalvadorDali is incorrect  The latter claims       And here is why  it is not possible to have setTimeout with a time   delay of 0 milliseconds  The Minimum value is determined by the   browser and it is not 0 milliseconds  Historically browsers sets this   minimum to 10 milliseconds  but the HTML5 specs and modern browsers   have it set at 4 milliseconds     The 4ms minimum timeout is irrelevant to what is happening  What really happens is that setTimeout pushes the callback function to the end of the execution queue  If after setTimeout callback  0  you have blocking code which takes several seconds to run  the callback will not be executed for several seconds  until the blocking code has finished  Try this code   function testSettimeout0          var startTime   new Date   getTime       console log  setting timeout 0 callback at    sinceStart        setTimeout function            console log  in timeout callback at    sinceStart           0      console log  starting blocking loop at    sinceStart        while  sinceStart    lt  3000            continue           console log  blocking loop ended at    sinceStart        return    functions below     function sinceStart              return new Date   getTime   - startTime          sinceStart      testSettimeout0   Output is   setting timeout 0 callback at 0 starting blocking loop at 5 blocking loop ended at 3000 in timeout callback at 3033

User · Answer

One reason to do that is to defer the execution of code to a separate  subsequent event loop  When responding to a browser event of some kind  mouse click  for example   sometimes it s necessary to perform operations only after the current event is processed  The setTimeout   facility is the simplest way to do it   edit now that it s 2015 I should note that there s also requestAnimationFrame    which isn t exactly the same but it s sufficiently close to setTimeout fn  0  that it s worth mentioning

User · Answer

setTimeout   buys you some time until the DOM elements are loaded  even if is set to 0   Check this out  setTimeout

User · Answer

This is an old questions with old answers  I wanted to add a new look at this problem and to answer why is this happens and not why is this useful   So you have two functions   var f1   function             setTimeout function          console log  f1    First function call             0       var f2   function          console log  f2    Second call            and then call them in the following order f1    f2    just to see that the second one executed first    And here is why  it is not possible to have setTimeout with a time delay of 0 milliseconds  The Minimum value is determined by the browser and it is not 0 milliseconds  Historically browsers sets this minimum to 10 milliseconds  but the HTML5 specs and modern browsers have it set at 4 milliseconds       If nesting level is greater than 5  and timeout is less than 4  then   increase timeout to 4    Also from mozilla      To implement a 0 ms timeout in a modern browser  you can use   window postMessage   as described here    P S  information is taken after reading the following article

User · Answer

The other thing this does is push the function invocation to the bottom of the stack  preventing a stack overflow if you are recursively calling a function  This has the effect of a while loop but lets the JavaScript engine fire other asynchronous timers

User · Answer

In the question  there existed a race condition between    The browser s attempt to initialize the drop-down list  ready to have its selected index updated  and Your code to set the selected index   Your code was consistently winning this race and attempting to set drop-down selection before the browser was ready  meaning that the bug would appear   This race existed because JavaScript has a single thread of execution that is shared with page rendering  In effect  running JavaScript blocks the updating of the DOM   Your workaround was   setTimeout callback  0    Invoking setTimeout with a callback  and zero as the second argument will schedule the callback to be run asynchronously  after the shortest possible delay - which will be around 10ms when the tab has focus and the JavaScript thread of execution is not busy   The OP s solution  therefore was to delay by about 10ms  the setting of the selected index  This gave the browser an opportunity to initialize the DOM  fixing the bug   Every version of Internet Explorer exhibited quirky behaviors and this kind of workaround was necessary at times  Alternatively it might have been a genuine bug in the OP s codebase      See Philip Roberts talk  What the heck is the event loop   for more thorough explanation

User · Answer

setTimout on 0 is also very useful in the pattern of setting up a deferred promise  which you want to return right away   myObject prototype myMethodDeferred   function         var deferredObject     Deferred        var that   this      Because setTimeout won t work right with this     setTimeout function              return myMethodActualWork call that  deferredObject          0       return deferredObject promise

User · Answer

The answers about execution loops and rendering the DOM before some other code completes are correct  Zero second timeouts in JavaScript help make the code pseudo-multithreaded  even though it is not   I want to add that the BEST value for a cross browser   cross platform zero-second timeout in JavaScript is actually about 20 milliseconds instead of 0  zero   because many mobile browsers can t register timeouts smaller than 20 milliseconds due to clock limitations on AMD chips   Also  long-running processes that do not involve DOM manipulation should be sent to Web Workers now  as they provide true multithreaded execution of JavaScript

User · Answer

Take a look at John Resig s article about How JavaScript Timers Work  When you set a timeout  it actually queues the asynchronous code until the engine executes the current call stack

User · Answer

Javascript is single threaded application so that don t allow to run function concurrently so to achieve this event loops are use  So exactly what setTimeout fn  0  do that its pussed into task quest which is executed when your call stack is empty  I know this explanation is pretty boring  so i recommend you to go through this video this will help you how things work under the hood in browser  Check out this video - https   www youtube com watch time continue 392 amp v 8aGhZQkoFbQ

User · Answer

Preface   Some of the other answers are correct but don t actually illustrate what the problem being solved is  so I created this answer to present that detailed illustration   As such  I am posting a detailed walk-through of what the browser does and how using setTimeout   helps  It looks longish but is actually very simple and straightforward - I just made it very detailed    UPDATE  I have made a JSFiddle to live-demonstrate the explanation below  http   jsfiddle net C2YBE 31    Many thanks to  ThangChung for helping to kickstart it   UPDATE2  Just in case JSFiddle web site dies  or deletes the code  I added the code to this answer at the very end     DETAILS   Imagine a web app with a  do something  button and a result div   The onClick handler for  do something  button calls a function  LongCalc     which does 2 things    Makes a very long calculation  say takes 3 min  Prints the results of calculation into the result div    Now  your users start testing this  click  do something  button  and the page sits there doing seemingly nothing for 3 minutes  they get restless  click the button again  wait 1 min  nothing happens  click button again      The problem is obvious - you want a  Status  DIV  which shows what s going on  Let s see how that works     So you add a  Status  DIV  initially empty   and modify the onclick handler  function LongCalc    to do 4 things    Populate the status  Calculating    may take  3 minutes  into status DIV Makes a very long calculation  say takes 3 min  Prints the results of calculation into the result div  Populate the status  Calculation done  into status DIV   And  you happily give the app to users to re-test   They come back to you looking very angry  And explain that when they clicked the button  the Status DIV never got updated with  Calculating     status       You scratch your head  ask around on StackOverflow  or read docs or google   and realize the problem   The browser places all its  TODO  tasks  both UI tasks and JavaScript commands  resulting from events into a single queue  And unfortunately  re-drawing the  Status  DIV with the new  Calculating     value is a separate TODO which goes to the end of the queue   Here s a breakdown of the events during your user s test  contents of the queue after each event    Queue   Empty  Event  Click the button  Queue after event   Execute OnClick handler lines 1-4   Event  Execute first line in OnClick handler  e g  change Status DIV value   Queue after event   Execute OnClick handler lines 2-4   re-draw Status DIV with new  Calculating  value   Please note that while the DOM changes happen instantaneously  to re-draw the corresponding DOM element you need a new event  triggered by the DOM change  that went at the end of the queue  PROBLEM    PROBLEM    Details explained below  Event  Execute second line in handler  calculation   Queue after   Execute OnClick handler lines 3-4   re-draw Status DIV with  Calculating  value   Event  Execute 3rd line in handler  populate result DIV   Queue after   Execute OnClick handler line 4   re-draw Status DIV with  Calculating  value  re-draw result DIV with result   Event  Execute 4th line in handler  populate status DIV with  DONE    Queue   Execute OnClick handler  re-draw Status DIV with  Calculating  value  re-draw result DIV with result  re-draw Status DIV with  DONE  value   Event  execute implied return from onclick handler sub  We take the  Execute OnClick handler  off the queue and start executing next item on the queue  NOTE  Since we already finished the calculation  3 minutes already passed for the user  The re-draw event didn t happen yet    Event  re-draw Status DIV with  Calculating  value  We do the re-draw and take that off the queue  Event  re-draw Result DIV with result value  We do the re-draw and take that off the queue  Event  re-draw Status DIV with  Done  value  We do the re-draw and take that off the queue  Sharp-eyed viewers might even notice  Status DIV with  Calculating  value flashing for fraction of a microsecond - AFTER THE CALCULATION FINISHED   So  the underlying problem is that the re-draw event for  Status  DIV is placed on the queue at the end  AFTER the  execute line 2  event which takes 3 minutes  so the actual re-draw doesn t happen until AFTER the calculation is done     To the rescue comes the setTimeout    How does it help  Because by calling long-executing code via setTimeout  you actually create 2 events  setTimeout execution itself  and  due to 0 timeout   separate queue entry for the code being executed   So  to fix your problem  you modify your onClick handler to be TWO statements  in a new function or just a block within onClick     Populate the status  Calculating    may take  3 minutes  into status DIV Execute setTimeout   with 0 timeout and a call to LongCalc   function    LongCalc   function is almost the same as last time but obviously doesn t have  Calculating     status DIV update as first step  and instead starts the calculation right away    So  what does the event sequence and the queue look like now    Queue   Empty  Event  Click the button  Queue after event   Execute OnClick handler status update  setTimeout   call   Event  Execute first line in OnClick handler  e g  change Status DIV value   Queue after event   Execute OnClick handler which is a setTimeout call   re-draw Status DIV with new  Calculating  value    Event  Execute second line in handler  setTimeout call   Queue after   re-draw Status DIV with  Calculating  value   The queue has nothing new in it for 0 more seconds  Event  Alarm from the timeout goes off  0 seconds later  Queue after   re-draw Status DIV with  Calculating  value  execute LongCalc  lines 1-3     Event  re-draw Status DIV with  Calculating  value  Queue after   execute LongCalc  lines 1-3    Please note that this re-draw event might actually happen BEFORE the alarm goes off  which works just as well        Hooray  The Status DIV just got updated to  Calculating     before the calculation started         Below is the sample code from the JSFiddle illustrating these examples  http   jsfiddle net C2YBE 31     HTML code    lt table border 1 gt       lt tr gt  lt td gt  lt button id  do  gt Do long calc - bad status  lt  button gt  lt  td gt           lt td gt  lt div id  status  gt Not Calculating yet  lt  div gt  lt  td gt       lt  tr gt       lt tr gt  lt td gt  lt button id  do ok  gt Do long calc - good status  lt  button gt  lt  td gt           lt td gt  lt div id  status ok  gt Not Calculating yet  lt  div gt  lt  td gt       lt  tr gt   lt  table gt    JavaScript code   Executed on onDomReady and may require jQuery 1 9   function long running status div         var result   0         Use 1000 700 300 limits in Chrome             300 100 100 in IE8             1000 500 200 in FireFox        I have no idea why identical runtimes fail on diff browsers      for  var i   0  i  lt  1000  i              for  var j   0  j  lt  700  j                  for  var k   0  k  lt  300  k                      result   result   i   j   k                                      status div  text  calculation done          Assign events to buttons     do   on  click   function              status   text  calculating            long running   status             do ok   on  click   function              status ok   text  calculating               This works on IE8  Works in Chrome        Does NOT work in FireFox 25 with timeout  0 or  1        DOES work in FF if you change timeout from 0 to 500     window setTimeout function     long running   status ok      0

User · Answer

By calling setTimeout you give the page time to react to the whatever the user is doing  This is particularly helpful for functions run during page load

User · Answer

Since it is being passed a duration of 0  I suppose it is in order to remove the code passed to the setTimeout from the flow of execution  So if it s a function that could take a while  it won t prevent the subsequent code from executing

User · Answer

Browsers have a process called  quot main thread quot   that is responsible for executing some JavaScript tasks  UI updates e g   painting  redraw  reflow  etc  JavaScript tasks are queued to a message queue and then are dispatched to the browser s main thread to be executed  When UI updates are generated while the main thread is busy  tasks are added into the message queue

User · Answer

The problem was you were trying to perform a Javascript operation on a non existing element  The element was yet to be loaded and setTimeout   gives more time for an element to load in the following ways    setTimeout   causes the event to be ansynchronous therefore being executed after all the synchronous code  giving your element more time to load  Asynchronous callbacks like the callback in setTimeout   are placed in the event queue and put on the stack by the event loop after the stack of synchronous code is empty   The value 0 for ms as a second argument in function setTimeout   is often slightly higher  4-10ms depending on browser   This slightly higher time needed for executing the setTimeout   callbacks is caused by the amount of  ticks   where a tick is pushing a callback on the stack if stack is empty  of the event loop  Because of performance and battery life reasons the amount of ticks in the event loop are restricted to a certain amount less than 1000 times per second

User · Answer

Some other cases where setTimeout is useful   You want to break a long-running loop or calculation into smaller components so that the browser doesn t appear to  freeze  or say  Script on page is busy    You want to disable a form submit button when clicked  but if you disable the button in the onClick handler the form will not be submitted  setTimeout with a time of zero does the trick  allowing the event to end  the form to begin submitting  then your button can be disabled

[javascript] Why is setTimeout(fn, 0) sometimes useful?

Examples related to javascript

Examples related to dom

Examples related to event-loop