DEV Community

Cover image for You don't need to set the time-out
Ndimah Tchougoua
Ndimah Tchougoua

Posted on

You don't need to set the time-out

I know timers has been for a while a feature that a lot of folks use in their day-to-day tasks. In the JavaScript world, timers are often implemented with the setTimeout or setInterval functions, the bad news for you if you are doing it is that it's not a good practice and I will try to explain why.

Before I begin to explain my thought, I have a question for you: can you use a watch giving the wrong time ?

If your answer is yes, I'm sorry to have wasted your precious time because this article does not belong to you.

On the other hand, if your answer is negative, I will explain why using setTimeout or setInterval is like using a damaged watch to get the time.

The problem with these functions

To begin, let's consider the following snippet

 function test() {
   let i = 0;
   setTimeout(() => console.log("hello"), 0);
   while (i < 5) {
     console.log("number ", i);
     i += 1;
  }
  console.log("world");
Enter fullscreen mode Exit fullscreen mode

if you run this snippet in your browser console, you will have the following result

output of the execution, showing how set Timeout has low priority

This behavior is due to the fact that setTimeout is adding the callback in the browser's queue so that it should process it once it is idle (does not have a task to do) in other words the callback passed to the setTimeout has low priority

Now, knowing this, I imagine that it will be hard for you to implement timers using the setTimeout function because you can have 2 or even 10 ticks (depending on how busy your browser is) at the same time. This will be a nightmare to debug, but do we have a better solution ?

A way to avoid these functions

To provide a better way of implementing timers, we should use requestAnimationFrame function because it tells the browser to execute a callback before the next paint (in other words before any change in the UI occurs)

The difference here is pretty subtle, so it's better to understand it through the code. Let's take back our previous snippet and tweak it a little bit to compare setTimeout and requestAnimationFrame

function testWithAnimationFrame() {
  let i = 0;
  setTimeout(() => console.log("hello"), 0);
  requestAnimationFrame(() => console.log("tell me the next paint"));
  while (i < 5) {
    console.log("number ", i);
    i += 1;
  }
  console.log("world");
}
Enter fullscreen mode Exit fullscreen mode

In this example, we can see that when running on Chrome, the setTimeout runs before requestAnimationFrame (though in some rare cases the inverse happens)

screenshot showing how set timeout has priority over request animation frame when no painting is happening in Chrome

But if you run it on Firefox, this will be the output

screenshot showing how request animation frame has priority over set timeout when no painting is happening in Firefox

This can seem confusing but if you pay a bit of attention, you will realize that no painting is happening during the execution, so how this scenario is handled depends on the browser.

Now if we can tweak our snippet to make the browser repaint the page, let's see what will happen

function testWithAnimationFrame2() {
  let i = 0;
  setTimeout(() => console.log("hello"), 0);
  requestAnimationFrame(() => console.log("tell me the next paint"));
  while (i < 5) {
    console.log("number ", i);
    i += 1;
    document.body.style.backgroundColor = "red";
  }
  console.log("world");
}
Enter fullscreen mode Exit fullscreen mode

Here is the output on Chrome

screenshot showing how request animation frame has priority over set timeout when a painting occurs in Chrome

And here is the output in Firefox

screenshot showing how request animation frame has priority over set timeout when a painting occurs in Firefox

As you can see in the logs, when the browser in making changes in the UI, the requestAnimationFrame function will always have priority over other scheduled callbacks.

Because on the web, we are constantly performing repaints, requestAnimationFrame is an obvious choice to implement timers.

Understanding the requestAnimationFrame function

The function only takes a callback as parameter. To provide context to the callback, it should take a timestamp indicating the time at which the previous frame has ended based on the time of the initial rendering of the page.

The function will return an integer representing the request's identifier, this can be useful if you wish to cancel the request with the cancelAnimationFrame function.

A simple implementation of a Stopwatch in JavaScript

To implement a stopwatch, there are some requirements:

  • We should know after which amount of time it should tick (generally a second)
  • We should know the delay of time after which the stopwatch should stop ticking
  • The ticking intervals should be lesser than the delay

Taking all these requirements in considerations, the following code snippet will create a stopwatch for you

Outro

I know it might have been a long read but believe that you have enjoyed it. Anyway, if you have any questions or if you have any suggestion, feel free to reach me out.

Thank you for reading it and goodbye 👋

Top comments (0)