DEV Community

Cover image for Clocks & Countdowns: Timing in CSS and JavaScript
Mads Stoumann
Mads Stoumann

Posted on

Clocks & Countdowns: Timing in CSS and JavaScript

The other day I needed a digital clock-component, so I quickly composed a simple JavaScript-method:



function uiDigitalClock(node) {
  const now = () => {
    node.textContent = new Date().toLocaleTimeString()
    requestAnimationFrame(now)
  }
  now()
}


Enter fullscreen mode Exit fullscreen mode

Somewhere I read that requestAnimationFrame should be better for performance than setInterval, but the method kept nagging me.

Under optimal conditions, requestAnimationFrame will trigger 60 times per second — which is 60 times more than the digital clock requires!

It cannot be good for performance to create a Date()-object 60 times per second!

So I tried with setInterval:



function interval(node){
  return setInterval(() => node.textContent = new Date().toLocaleTimeString(), 1000)
}


Enter fullscreen mode Exit fullscreen mode

Again, not much code, the visual result is the same — and only one Date()-object per second.

What about setTimeout()?



function timeout(node) {
  const now = () => {
    node.textContent = new Date().toLocaleTimeString()
    setTimeout(now, 1000)
  }
  now()
}


Enter fullscreen mode Exit fullscreen mode

It also works with a similar result, but with an annoying delay (setImmediate() is only in Node)

I then decided to rework the initial version to only trigger every second, as requestAnimationFrame() returns a timestamp:



function frame(node) {
  let last = 0;
  const render = now => {
    if (!last || now - last >= 1000) {
      last = now;
      node.textContent = new Date().toLocaleTimeString();
    }
    requestAnimationFrame(render);
  }
  window.requestAnimationFrame(render);
}


Enter fullscreen mode Exit fullscreen mode

With all 3 methods running, I happened to inspect the markup in Dev Tools, and noticed that I couldn't even expand the nodes, because they were being refreshed constantly, and looking like the old <blink>-tag!


Asking Bard for help

Still not really knowing which method to pick, I decided to ask Google Bard, to which it replied:

  • clock1 uses the setInterval() method, which creates a recurring timer that fires every 1000 milliseconds (1 second). This is the least performant method because it creates a new timer for each iteration, which can add up to a significant amount of overhead.

  • clock2 uses the setTimeout() method, which creates a single timer that fires after 1000 milliseconds. This is more performant than clock1 because it does not create a new timer for each iteration. However, it is still less performant than clock3 because the browser has to wait for the timer to fire before updating the text content.

  • clock3 uses the requestAnimationFrame() method, which is a more efficient way to request a repaint of the browser. The browser will only repaint the element when it is necessary, which can save a significant amount of CPU time.

Fine, I decieded to go with clock3 ... but then it hit me: "What about number-animations in CSS, using @property?

Jhey made a Pure CSS Stopwatch a while ago, so I decided to try something similar.



@property --seconds {
  syntax: "<integer>";
  initial-value: 0;
  inherits: false;
}
@property --minutes {
  syntax: "<integer>";
  initial-value: 0;
  inherits: false;
}
@property --hours {
  syntax: "<integer>";
  initial-value: 0;
  inherits: false;
}


Enter fullscreen mode Exit fullscreen mode

Then, in an <ol>-tag, I added a <li>-tag for each time-unit.

To use the value of the @property-declaration, you need to use a CSS counter, so for seconds it's:



.seconds {
  animation: seconds 60s steps(60, end) infinite;
  animation-delay: var(--delay-seconds, 0s);
  counter-reset: seconds var(--seconds);
  &::after { content: counter(seconds, decimal-leading-zero) ' '; }
}


Enter fullscreen mode Exit fullscreen mode

To animate the seconds, a keyframe is needed:



@keyframes seconds { 
  from { --seconds: 0;}
  to { --seconds: 60; }
}


Enter fullscreen mode Exit fullscreen mode

For minutes, it's almost the same, but the animation takes 60 times longer (60 x 60 = 3600):



animation: minutes 3600s steps(60, end) infinite;


Enter fullscreen mode Exit fullscreen mode

And for hours, we need to multiple that number with 24:



animation: hours 86400s steps(24, end) infinite;


Enter fullscreen mode Exit fullscreen mode

Yay! We have a working CSS Clock ... but it only works at midnight, since both hours, minutes and seconds start at 0 (zero).

So what to do? I could easily update the properties from JavaScript, after having created an initial Date()-object.

But then the animations would be wrong, as they would run for the same amount of times (60 seconds for seconds), even if the actual amount of seconds were less than that.

I asked for help on Twitter — and to my luck, Temani Afif and Álvaro Montoro replied! The solution was to use a negative animation-delay.

So, with a bit of JavaScript to set the current time and calculate the delays:



const time = new Date();
const hours = time.getHours();
const minutes = time.getMinutes();
const seconds = time.getSeconds();

// Delays
const HOURS = -Math.abs((hours * 3600) + (minutes * 60) + seconds);
const MINS = -Math.abs((minutes * 60) + seconds);
const SECS = -Math.abs(seconds);


Enter fullscreen mode Exit fullscreen mode

... we can update the CSS Properties specified earlier, for example:



node.style.setProperty(`--delay-seconds`, `${seconds}s`);


Enter fullscreen mode Exit fullscreen mode

Now, we have a working digital CSS clock — compare it with the other methods here:

If you inspect the markup in Dev Tools, you'll see that the CSS-version isn't re-writing DOM-content.


Countdown

After this, I decided to revisit an old Codepen of mine, a multilanguage countdown, and make a CSS-only-version:

You can play around with the locale in the JS-code, if you want it in another language:

CSS Countdown

But what about performance? CSS might not be blocking the main thread like JavaScript, but can we be sure it's using the GPU instead of the CPU?

There's an old trick for that:



.useGpu {
  transform: translateZ(0);
  will-change: transform;
}


Enter fullscreen mode Exit fullscreen mode

Then, in Dev Tools, go to "Layers":
Layers

See how the "countdown" now has it's own rendering-layer? Not sure if this is still applicable, but guess it doesn't hurt to add.


Leaving a Browser Tab

I haven't had any issues with the CSS-only clock when I leave a browser-tab and return. Maybe I haven't been waiting long enough! But should you encounter any issues, recalculate the clock's delays using this event:



document.addEventListener('visibilitychange', () => {
  if (!document.hidden) { ... }
})


Enter fullscreen mode Exit fullscreen mode

Analog Clock

As a bonus – here's an analog clock, I did a while ago:


And now it's time (pun intended), to end this article!

Cover image by DALL·E.

Top comments (35)

Collapse
 
alvaromontoro profile image
Alvaro Montoro

Nice article.

It's funny how the setTimeout solution is clearly running slower than the others in the demo. It gets behind in just a few seconds.

Collapse
 
madsstoumann profile image
Mads Stoumann

Thank you! I think stable timing in JS is difficult — once I tried to make a drum sequencer, but the timing was off after random amounts of time!

Collapse
 
alvaromontoro profile image
Alvaro Montoro

Have you tried using requestAnimationFrame but tracking the dates with counters, only calling Date() after X ticks to make sure the clock is on time? I think that may be the most accurate (and efficient?) of all the methods.

Thread Thread
 
madsstoumann profile image
Mads Stoumann • Edited

No, but good idea! For the drum-sequencer, I think I ended up using the AudioContext as the “timing source of truth”.

Collapse
 
peerreynders profile image
peerreynders

You have to take the drift of the setTimeout() into account when you schedule the next frame. See:

JavaScript counters the hard way - HTTP 203 - YouTube

You’ve seen loads of counter tutorials online, but they’re all a bit wrong… or at least most of them are. Jake and Surma dissect different techniques and ide...

favicon youtube.com
Thread Thread
 
madsstoumann profile image
Mads Stoumann

Interesting to use performance.now, I’ve only seen that used in testing. Thanks for sharing!

Collapse
 
wraith profile image
Jake Lundberg

Really nice article. I never would have thought to try using CSS for this, very creative.

Keep up the awesome work!

Collapse
 
madsstoumann profile image
Mads Stoumann

Thank you!

Collapse
 
hugaidas profile image
Victoria • Edited

This is very inspiring, how we can make performant components without moment.js, thank you for sharing! I will try to implement this by myself. But I have a question - why did u decide to consult with Bard? Is it better than chapt GPT?

Collapse
 
madsstoumann profile image
Mads Stoumann

Thank you! Bard: No particular reason, just trying it out, comparing code-suggestions with chatGPT etc.

Collapse
 
hugaidas profile image
Victoria

Okay, got it! :)

Collapse
 
tqbit profile image
tq-bit

Great article. One of these days, we'll have a CSS-only frontend framework out there.

Collapse
 
madsstoumann profile image
Mads Stoumann

Thank you!

Collapse
 
leomiguelb profile image
Leo

hopefully...

Collapse
 
artydev profile image
artydev

Really nice thank you

Collapse
 
attallah1981 profile image
attallah guehiri

جيد جدا

Collapse
 
madsstoumann profile image
Mads Stoumann

شكرا لك!

Collapse
 
madsstoumann profile image
Mads Stoumann

Hope Apple Translate did it properly 😉

Collapse
 
ademagic profile image
Miko

Really insightful and well broken down. Thanks!

Collapse
 
madsstoumann profile image
Mads Stoumann • Edited

Thank you!

Collapse
 
codewithahsan profile image
Muhammad Ahsan Ayaz

This is awesome 💖 Loved your writing style and presenting your analysis throughout, like a journey. This is definitely something I can use for focusdoro.app
Kudos!

Collapse
 
madsstoumann profile image
Mads Stoumann

Thank you! Happy to hear that!

Collapse
 
jonathanbolibenga01 profile image
jonathan

J'ai aimé votre article je me suis exercer à faire la même chose... Merci beaucoup

Collapse
 
madsstoumann profile image
Mads Stoumann

Merci

Collapse
 
jonathanbolibenga01 profile image
jonathan

Vous êtes un dev front-end ?

Thread Thread
 
madsstoumann profile image
Mads Stoumann • Edited

Yes, since 1995 — when it was called "webmaster / web-developer" 😂

Thread Thread
 
jonathanbolibenga01 profile image
jonathan

Moi je débuté cette année avec JavaScript du côté back-end

Collapse
 
zirkelc profile image
Chris Cook

You got a nice writing style! :-)

Collapse
 
madsstoumann profile image
Mads Stoumann

Happy to hear that, thank you!