Hacker News Reader

Comment by yifanl | Hacker News Reader

No, it pretty much just does exactly that.

    const subtractNextDelay = () => {
      if (typeof remainingDelay === "number") {
        remainingDelay -= MAX_REAL_DELAY;
      } else {
        remainingDelay -= BigInt(MAX_REAL_DELAY);
      }
    };

View on HN

Oh yikes. Yeah; not ideal.

To be fair, this is what I expect of any delay function. If it needs to be precise to the millisecond, especially when scheduled hours or days ahead, I'd default to doing a sleep until shortly before (ballpark: 98% of the full time span) and then a smaller sleep for the remaining time, or even a busy wait for the last bit if it needs to be sub-millisecond accurate

I've had too many sleep functions not work as they should to still rely on this, especially on mobile devices and webpages where background power consumption is a concern. It doesn't excuse new bad implementations but it's also not exactly surprising

I guess the dream of programming the next heliopause probe in JavaScript is still a ways off hahaha! :)

But it appears that it is consistent with setTimeout’s behavior and therefore likely correct in the context it will be used.

At least if your definition of “correct” is “does the thing most similar to the thing I’m extending/replicating”. In fact you might believe it’s a bug to do otherwise, and JS (I’m no expert) doesn’t give a way to run off the event loop anyway (in all implementations). Although I’d be amused to see someone running even a 90 day timer in the browser. :)

I’ve think a very precise timeout would want a different name, to distinguish it from setTimeout’s behavior.

Reply on news.ycombinator.com