This is usually used for mistakes or long loops within the callback
do not affect what comes after the setTimeout
, is an attempt to "simulate" the Multiple threads
(multithreaded), is not a thread
true, but works on the same line.
With the 0
(zero), it will run itself at the same time as setTimeout
is called, but it will not be necessary what comes after the setTimeout
wait for the process to end, it is as if the callback was executed in a separate "process"
For example:
function meuCallback() {
console.log("Level2");
}
console.log("Level1");
setTimeout(meuCallback, 0);
console.log("Level1");
In the example it will deliver something like:
Level1
Level2
Level1
But it is good to note that each engine (browser technology Ecmascript - popularly called Javascript) adjusts as needed and tries its way to get better performance, sometimes the same script can deliver something like:
Level1
Level1
Level2
An example that some people use to avoid mistakes would be something like:
function meuCallbackComError() {
(a + b);
}
console.log("Execução 1: Level1");
setTimeout(meuCallbackComError, 0);
console.log("Execução 2: Level1");
See that in the log appears something like:
Execution 1: Level1
Execution 2: Level1
Uncaught Referenceerror: a is not defined
That is to say the second console.log
was not affected by the error.
Why not use zero in setTimeout
It does not mean that you will never use, for example just to avoid mistakes that can be caused inside the callback the zero will be enough, the situations that we should avoid the 0
is when processes of the browser itself occur that may take time, such as rendering images after the onload
, we often use the setTimeout
to wait for another process to end, for example an image inserted by javascript, even using Image.onload
not yet rendered within a millionth of a second (something imperceptible to humans), so a small "delay" can help, such as:
setTimeout(..., 1)
- works for most rendering cases this can work
setTimeout(..., 10)
- this may be preferable to others and hardly a human will realize
setTimeout(..., 100)
- in some cases we need a longer delay, where there is an element that will take time to render (hardly a human will see this).
Alternatives to setTimeout
It works well in most cases, but it should be noted that scripts that take time to execute will still freeze webbrowser for some time (varying according to the script), even using the setTimeout
.
I recommend you read this other answer, it explains the callbacks and the setTimeout
:
There are currently more functional solutions to prevent freezing, for example:
However if you just want to prevent small delays or errors that might occur, then just use the setTimeout
, if you want to run scripts that take more than 500ms to process then the Web Workers or the AMD may be useful to you.
Note that the AMD is being used by several libraries, such as the jQuery for example. See a snippet of the code jQuery:
if ( typeof define === "function" && define.amd ) {
define( "jquery", [], function() {
return jQuery;
});
}
Before anyone comes to speak in my ear: Related English: http://stackoverflow.com/questions/779379/why-is-settimeoutfn-0-sometimes-useful
– Wallace Maxters
I can’t read as well in English and the Google Translation becomes horrible!
– Wallace Maxters
Excellent question @Wallacemaxters, also wanted to know this. + 1
– Rafael Kendrik