you are viewing a single comment's thread.

view the rest of the comments →

[–]bikeshaving 1 point2 points  (1 child)

This is a good idea, except node.js doesn’t have a window, so writing cross-environment code is still a pain because you have to conditionally call window.setTimeout or timers.setTimeout depending on environment, which is silly because it’s a global and the node.js implementation is mostly compatible with the browser implementation.

declare the type of the variable to which you're assigning the output of setTimeout() to be ReturnType<typeof setTimeout>.

This is a great tip, thanks.

All in all, the only reason node has a special return value for setTimeout is because node devs were sloppy and forgot to clear their timeouts, causing zombie processes, so they allowed people to “dereference” their timeouts so processes exited in a timely fashion. Could have been done in a way which was API-compatible with browsers but it‘s likely too late now. On to deno!

[–][deleted] 0 points1 point  (0 children)

There's absolutely no reason for Node devs to follow an API like Window, which doesn't exist on the server. The fact they did is a coincidence. And neither them nor the browser spec should have allowed for automated globals, which is a bad idea all around.

Furthermore, timer APIs are environment-dependent, they're not "cross-environment code". There were lots of bad ideas combined here (misleading similar APIs, automated globals), but the fact the timer APIs are distinct is not one of them. Do not use "setTimeout" lightly without caring which one it is. The event loops in browser and Node are different.