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.
Continue reading about How to wait for DOM elements to show up in modern browsers
Semantically similar articles hand-picked by GPT-4
- Arcane JavaScript knowledge still useful
- I was wrong about AngularJS
- A lesson about client-side templating
- Building an interactive DOM benchmark, preliminary results
- Just for fun 👉 React vs. jQuery vs. Svelte, same 🐱 app
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️