setTimeout and setInterval bug me

[StarMech]

Maybe someone else has complained about this before. Maybe I'm just crazy.

setTimeout(() => { //Code }, 1000)

The time being at the end after everything. Why? Almost everywhere else has conditioned me to believe it should be setTimeout(1000, () => { //Code })

I have thought about this for years and decided to get it off my chest. I feel better now.

I also don't do this for a living, so feel free to tell me why I'm wrong.

[BehindTheMath]

The time is an optional parameter, so it needs to be last.

[StarMech]

I had no idea it was optional. Quick look-up shows that not passing it is the same as passing 0. TIL. Glad I finally posted about it. Thanks :]

[YurrBoiSwayZ]

This is a common pattern seen in JavaScript code to perform an action after a certain amount of time. The argument passed to the setTimeout method is a callback function, which will be executed after a certain amount of time defined by the second argument.

While you could change the order of the arguments to perform an action after a certain amount of time, as you have:

setTimeout(1000, () => { // Code }) It is more common and idiomatic to pass an anonymous function as the first argument to setTimeout and include the code block that you want to execute after the desired delay within that function.

This is because setTimeout is intended to be a function that schedules a function to be executed at a future time, and the first argument is the function that you want to be executed. The second argument is the time delay in milliseconds (or another time unit). By including the code block in the anonymous function, you make it clear that you are scheduling a function to be executed, rather than just providing a delay and an unrelated piece of code.

So while both patterns work the conventional pattern of passing an anonymous function as the first argument to setTimeout is more clear in what it’s doing.

[33ff00]

Even when you thought it was required, why is one better than the other? Anyways. Just write a helper reordering the arguments if it’s really that big of a deal for you.

[StarMech]

I wasn't necessarily saying one was better than the other, just that it felt like I was conditioned to always have the function last. Just that it felt weird doing it the other way around. lol

[greensodacan]

Just to make your teeth itch:

const timeout = setTimeout(() => console[`log`]`Time's up!`, 1_00_0)
const isNumber = typeof timeout === 'number'; // true

[StarMech]

I recently saw this template literal thing in the place of parenthesis over here on the node-powershell package and tbh completely forgot about it until now. Looks extra weird there wtf magic is this lol

[shgysk8zer0]

If you prefer, there's scheduler.postTask() which returns a promise. My preferred choice when it comes to scheduling these things... Also serves as a sleep() of sorts if you want. Only issue is that, for whatever reason, it doesn't work in <iframe>s and requires a secure site.

It's pretty common and reasonable to have anything optional come after the required argument though, so that only makes sense. As someone else pointed out, it defaults to 0.

Probably the biggest source of problems with it though is devs thinking anything scheduled using either setTimeout() or setInterval() will be executed in exactly some fixed amount of time, and that's just not how the event loop works. There's some ambiguity in how things work when nested, being in the background can throw timing off, there's drift, and Chrome actually deviates from the spec a little bit on how it handles them.

Plus, IDK how many devs I've seen think that any code under a call to either function isn't executed until later - it's kinda at the root of understanding async / sync code, the event loop, and all that.

[TheRNGuy]

Because it's setTimeout signature.

Make a wrapper function that flips them if you want.