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()
}
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)
}
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()
}
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);
}
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;
}
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) ' '; }
}
To animate the seconds, a keyframe is needed:
@keyframes seconds {
from { --seconds: 0;}
to { --seconds: 60; }
}
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;
And for hours, we need to multiple that number with 24:
animation: hours 86400s steps(24, end) infinite;
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);
... we can update the CSS Properties specified earlier, for example:
node.style.setProperty(`--delay-seconds`, `${seconds}s`);
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:
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;
}
Then, in Dev Tools, go to "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) { ... }
})
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 (34)
Nice article.
It's funny how the
setTimeoutsolution is clearly running slower than the others in the demo. It gets behind in just a few seconds.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!
Have you tried using
requestAnimationFramebut tracking the dates with counters, only callingDate()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.No, but good idea! For the drum-sequencer, I think I ended up using the AudioContext as the “timing source of truth”.
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...
Interesting to use
performance.now, I’ve only seen that used in testing. Thanks for sharing!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?
Thank you! Bard: No particular reason, just trying it out, comparing code-suggestions with chatGPT etc.
Okay, got it! :)
Really nice article. I never would have thought to try using CSS for this, very creative.
Keep up the awesome work!
Thank you!
Great article. One of these days, we'll have a CSS-only frontend framework out there.
hopefully...
Thank you!
J'ai aimé votre article je me suis exercer à faire la même chose... Merci beaucoup
Merci
Vous êtes un dev front-end ?
Yes, since 1995 — when it was called "webmaster / web-developer" 😂
Moi je débuté cette année avec JavaScript du côté back-end
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!
Thank you! Happy to hear that!
Really insightful and well broken down. Thanks!
Thank you!
جيد جدا
شكرا لك!
Hope Apple Translate did it properly 😉
Really nice thank you
You got a nice writing style! :-)
Happy to hear that, thank you!
Absolutely fabulous !
Thank you!
Nice article.
This clock turned out amazing.
Thank you!
I learned how pseudo elements can really make your website pop.