I have a test:
Html:
Empty
Empty
js:
var s1 =
eicto, setTimeout doesn't fire code when requested.
It queues code, inline, with ALL of the other code that comes before it, but it sets its place in line to be at minimum the time requested.
Moreover, most browsers have hard limits for minimum timeouts.
If you request a 1ms timeout, chances are good that in most browsers, you're going to get your request back 10ms-15ms later.
All of the JS interaction with the DOM, and, in reality, pretty much everything a single page does, all happens on one thread, with certain exceptions for custom browser extensions, and a few new APIs (like webworkers).
This is why large projects need to be considerate of everything else on the page, and why everything needs to be asynchronous.
Because setTimeout isn't a sleep and it doesn't return on the exact microsecond that it was croned in for...
...it puts a callback on the event stack, for a time no earlier than what you specify.