Remember how careful we all were of the DOM ready event a few years ago? Writing JavaScript code outside of a $(document).ready() callback was sacrilege. An offense of the highest order.

Then about two years ago somebody went “Whoa whoa, wait a minute. We don’t need all of that DOM ready nonsense. We can just put our JavaScript at the bottom”

And everyone was like, “Haha silly us, thinking that script tags belong in the header. They can go anywhere!”

Nowadays, no JavaScript ever goes in a $(document).ready() callback. Our scripts’ hair flows in the wind as they ride through the glen firing arrows into the sunset. Khem.

Anyway, the point is. We’ve all but forgotten about the DOM ready event. By the time our scripts run, the whole DOM is already there and we don’t have to worry about accessing elements that don’t exist.

That is, until we start rendering our elements with JavaScript.

Building DOM with JS can mess things up

In an ideal world, you’d wholly rely on your fancy framework to build the DOM. Backbone, Angular, CanJS, React, anything really. They’re all smart enough to keep you from doing stupid things.

But sometimes you’re still going to do something stupid. Like, you’ll have some init code that needs an element for some reason or another. In my case, I needed to set its width based on some stuff in local storage.

However, for whatever reason deep inside your legacy code, your init function gets called before the element you need is rendered. This can happen because you’re doing ugly things with your framework, like, setTimeout(foo, 100); // this solves a render loop conflict. Or as often happens, the element depends on a different component, and your framework decides on the wrong order of rendering.

Frameworks are fickle like that. They really really like to pretend everything renders at the same time, but in reality it renders in a loop.

And then you’re tempted to write something like this:

   function try () {
     if (!$("#element").size()) {
       setTimeout(try, 500); // give everything some time to render
     } 
   }

And it works. It really does. As long as you keep looking at it.

But modern browsers are tricky. When the tab isn’t in focus, or your user’s computer is running slow, or whatever, that timeout won’t have enough time.

You see, browsers these days are trying desperately to conserve batteries and generally be nice to computers. When a tab isn’t in focus, the JavaScript slows down. Timeouts start acting funny, and you should forget all about any rendering happening.

You’ll notice this easiest when switching to your app’s tab. It shows the old content. Then flashes. Then re-renders.

Really really really annoying for testing because you can no longer browse HackerNews while your app takes its 20 seconds to reload. But really useful for users.

Please don’t ask why the app I’m working on takes 20 seconds to reload.

But anyway, you’ve hit upon the problem of DOM elements not being there when your code needs them. No matter how long the delay in that setTimeout, the element still isn’t there.

“A-ha! DOM ready! I need the DOM ready!”, you think.

Nope. The DOM is long since ready by the your script runs. I’ve tried that.

Turns out what you’re looking for is requestAnimationFrame. It’s normally used to make animation less jittery because it syncs your JavaScript’s rendering with the browser’s rendering. Normally about 60 hertz.

But it’s also how the browser tells your code that it’s still waiting. That things haven’t been rendered because the user isn’t there and there’s nobody to look at your stuff.

So instead of that setTimeout, you should do something like this:

  function try() {
    if (!$("#element").size()) {
      window.requestAnimationFrame(try);
    }else {
       $("#element").do_some_stuff();
     }
  };

Yup, no timeouts. At first glance it looks like this code is going to poll the DOM every 60th of a second to see if the element is there yet.

But in practice it only ever retries once. Because no matter what, by the next render frame, whether it comes in a 60th of a second, or a minute, the element will have been rendered.

And that’s how you properly wait for DOM elements to show up in modern browsers. I nearly tore my hair out before I figured it out.

Learned something new? Want to improve your skills?

Join over 10,000 engineers just like you already improving their skills!

Here's how it works 👇

Leave your email and I'll send you an Interactive Modern JavaScript Cheatsheet 📖right away. After that you'll get thoughtfully written emails every week about React, JavaScript, and your career. Lessons learned over my 20 years in the industry working with companies ranging from tiny startups to Fortune5 behemoths.

PS: You should also follow me on twitter 👉 here.
It's where I go to shoot the shit about programming.