Question: I have recently started exploring Javascript in more detail, and how it executes within the browser. Specifically, the setTimeout function.

My understanding is that calling `setTimeout(foo,x)`
will pass a handle to foo to be executed after x milliseconds. How reliable is this timing? Obviously if another long-running script is still executing after x milliseconds then the browser won't be able to call foo, but can I be absolutely certain that `setTimeout(foo,101)` will always be executed after `setTimeout(foo,100)`?

Answer: 
In nodejs we may be able to time events very precisely by setting a timeout to expire *shortly before* the desired moment, and then creating a tight series of event-loop ticks, and after each one checking how close to the target time we've approached:

1. Imagine `Date.now()` is currently, e.g., 11000 (unrealistic; just an example!)
2. Determine we want to act in EXACTLY 4000ms
3. Note that means EXACTLY when `Date.now() === 15000`
4. Use setTimeout to wait less than 4000ms, e.g., 3800ms
5. Keep awaiting microticks until `Date.now() >= 15000`

	* This won't block the event loop
	* (But it will keep your CPU very busy)

```js
let preciseWaitMs = async (ms, { nowFn=Date.now, stopShortMs=200, epsilonMs=0 }={}) => {

  let target = nowFn() + ms;

  await new Promise(resolve => setTimeout(resolve, ms - stopShortMs));

  // Allow `epsilonMs` to shift our wait time by a small amount
  target += epsilonMs;

  // Await a huge series of microticks
  // Note: this will eat cpu! Don't set `stopShortMs` too high!
  while (target > nowFn()) await Promise.resolve();

};

(async () => {

  let t1 = Date.now();
  let target = t1 + 2000;
  console.log(`Trying to act in EXACTLY 2000ms; at that point the time should be ${target}`);

  await preciseWaitMs(2000);

  let t2 = Date.now();
  console.log(`Done waiting; time is ${t2}; deviation from target: ${t2 - target}ms (negative means early)`);

})();
```

Note that `preciseWaitMs(4000)` will never wait *less* than 4000ms. This means that, if anything, it is biased towards waiting too long. I added an `epsilonMs` option to allow the bias to be moved back according to the user; for example `preciseWaitMs(4000, { epsilonMs: -1 })` may cancel out `preciseWaitMs`'s bias towards always being late.

Note that some js environments provide a higher-precision current-time query than `Date.now` - for example, nodejs has `require('perf_hooks').performance.now`. You can supply a function like this using the `nowFn` option:

```
{ epsilonMs: -0.01, nowFn: require('perf_hooks').performance.now };

```

Many browsers support `window.performance.now`; try supplying:

```
{ epsilonMs: -0.01, nowFn: window.performance.now };

```

These settings achieve sub-millisecond "precise" timing; off by only about 0.01ms on average

Note the `-0.01` value for `epsilonMs` is what seemed to work best for my conditions. Note that supplying fractional `epsilonMs` values is only meaningful if `nowFn` provides hi-res timestamps (which isn't, for example, the case with `Date.now`).
Most browsers use single thread for UI and JavaScript, which is blocked by synchronous calls. So, JavaScript execution blocks the rendering.

> 
> Events are processed asynchronously with the exception of DOM events.
> 
> 
> 

but `setTimeout(function(),1000)` trick is very useful. It allows to:

> 
> Let the browser render current changes. Evade the “script is running too long” warning. 
>  Change the execution flow. Opera is special in many places when it comes to timeouts and threading.
> 
> 
> 

So if another function is executing it will handle it by running in parallel.

another thing to `setTimeout(function(),1000)` her time is in millisecond not in seconds.