Hacker News Reader

Comment by whilenot-dev | Hacker News Reader

Agree, I wish every project would have that!

I still think the conclusion on "setTimeout is cursed"[0] is faulty:

> The setTimeout method in JavaScript is cursed when used with small values because the implementation may or may not actually wait the specified time.

The issue to me seems that performance.now()[1] returns the timestamp in milliseconds and will therefor round up/down. So 1ms errors are just within its tolerance.

[0]: https://github.com/immich-app/immich/pull/20655

[1]: https://developer.mozilla.org/en-US/docs/Web/API/Performance...

View on HN

JS is not a realtime language.

setTimeout() does not actually guarantee to run after the elapsed time. It merely gets queued for the next async execution window after that timer elapsed. Hence it can also be off by infinity and never get called - because JS is single threaded (unless you use a worker - which comes with its own challenges) and async windows only open if the main thread is "idle".

Usually, this is very close to the time you set via setTimeout, but it's very frequently slightly off, too.

setTimeout guarantees that the time provided is the time that has at least been elapsed, if it elapses at all - I think that is known to every JavaScript engineer out there.

Then there are also gotchas like these[0][1]:

> As specified in the HTML standard, browsers will enforce a minimum timeout of 4 milliseconds once a nested call to setTimeout has been scheduled 5 times.

Still, the issue is rather how to measure the elapsed time reliably, for unit-tests among other things.

[0]: https://developer.mozilla.org/en-US/docs/Web/API/Window/setT...

[1]: https://html.spec.whatwg.org/multipage/timers-and-user-promp... (first Note)

Indeed - I was a bit surprised by them mentioning this to be honest, since, as I understand it, this is kind of a widely accepted limitation of setTimeout - it's purely a 'best effort' timer. It's not intended to be something where "yes after exactly Xms it'll execute.

This isn't quite the whole picture. If called in a nested context, `setTimeout` callbacks get executed in the next execution window, or at least 4ms after the initial call, whichever is earlier. Similarly, I believe `setInterval` has a minimum interval that it can't run faster than.

See: https://developer.mozilla.org/en-US/docs/Web/API/Window/setT...

> JS is not a realtime language.

Is there even such a thing? You're at the mercy of the platform you're running on. And Windows, Linux, Mac, Android, and iOS are not realtime to begin with.

I guess if you're running on a realtime platform but in a VM like JS does, you can then take that property away, downgrading the "language" from being realtime. I wouldn't call that a language property still though, maybe my VM implementation doesn't make that downgrade after all.

Reply on news.ycombinator.com