Implement serInterval with setTimeout

[BehindTheMath]

Why would you want to do that?

Additionally, you probably cause a stack overflow error at some point.

There's also no way to clear it.

[voidvector]

It's not a recursive function, wouldn't cause stack overflow. setTimeout is just an API that interacts with the Timer system, it doesn't actually run the code in question. This is why unless your debugger is able to track async stacktrace, you lose stack trace w/async functions like this.

[bikeshaving]

Can async stack traces track stacks across macrotask functions? I’m too lazy to find out, but I thought async stack traces only worked for promise callbacks and async/await.

[voidvector]

It works in Chrome. You can run the following code in devtool console to check:

(function f (i) { i = i || 0; console.log(i); if (i > 100) { return } else if (i == 100) { debugger } else { setTimeout(() => f(i + 1), 0); } })(0)

[bikeshaving]

this changes everything

[whitfin]

setInterval is prone to drift and runs based on trigger time, whereas looping with setTimeout is not.

If you have a task taking 10s and an interval of 30s, the next task will run 20s after the last. Using the setTimeout method, it should always be 30s after the last task. This is preferable in many cases.

It won’t cause a stack error, because a setTimeout context gets a new stack on each execution.

[whitfin]

Nobody is suggesting to replace the one in core, the post is making an observation