The One Bad example and One Good example of setTimeOut to cause blockage in the main thread and to cope with as good solution respectively.

// Output:

Start

End

Inside setTimeout

(Note : for beginners considering the output would be start, inside setTimeout, and then end because 0 as timer value, this won't be the case because of the behaviour of Call stack in GEC and the Event loop with callback queue. Do check this out)

• Considering the intention is to set the timer function with 0 time value, used to execute the function after completing all synchronous tasks, at the end of call stack, let's check how this blocking of the main thread is a bad practice.
• If there is some important work in set time out which is just to be executed at the end of all operations and due some reasons there is some issue in the main thread execution, the?callback queue (task queue) could not push this web api into the call stack as it is waiting to do so.
• I had seen it somewhere as a trick, but could not get it into practice,afterall there are a bunch of good precise ways, how can I?
• Think if you had more than one operation consecutively to be executed after the end of all synchronous operations how could those 2 be dependable or placed hierarchically?
• That is where the promise/async await or operators in RXJS comes in, which could handle the synchronous or Async operations failure and provide the abilities of using elsewise logic.Lets use best from the best like some above, for good results as it won't cost any difference.

setTimeOut is one of coolest web api though, if used for the purpose it was created. One Simple, easy to understand use case -

Ex. In case we want delays in operations involving promises.

If the original promise resolves or rejects before the timeout :?

• timeout is cleared &
• The new promise processes the same resolution or rejection as the original promise

If the timeout expires before the original promise resolves or rejects:

• The timeout triggers, and the new promise rejects with a "timeout" error overriding the original promise.

Tip : The above operation could be enhanced by a small change.Instead of rejecting the original promise, generate a confirmation dialog - "Taking more time than expected. Do you want to wait?". On click of "ok", let the original promise resolve/reject on its own, otherwise on "cancel", let the new promise reject with an error. This way provides further more control.

Think if this was not implemented and the user is frustrated over the wait for longer operations, which undoubtedly seen at many places! And which is why I have brought this example into talk.

Indeed you need to do some more work to cancel the original promise like 1ex. using abortControl to stop waiting for the original promise, still it won't change the result if you don't do, as the new promise has taken the place.

While working with the RxJS Operators, there we deal with Observables which have a built-in time mechanism, “timeout(TIMEOUT_MS)”. It's relatively simple while delaying something using RxJS, where we don't have to rely on setTimeOut. But When using promises, we may require setTimeOut as described above.

Moreover, no question on best ever advantages for setTimeOut application in Debouncing & Throttling | setTimeOut wrapped with debounce function to limit the no. of requests to the server in case of continuous search input that hits api req on each input typed |?setTimeOut wrapped withThrottling function,? where a function is executed at a regular set of intervals (scrolling, resizing), regardless of how often an event is triggered.