I’m trying to create a function that pauses execution for a specific amount of time in JavaScript. Currently I’m using this approach:
function waitFor(milliseconds) {
const startTime = new Date();
let currentTime = null;
do {
currentTime = new Date();
} while (currentTime - startTime < milliseconds);
}
This works but I wonder if there’s a more efficient or cleaner way to achieve this. I need the execution to actually stop in the middle of my function, not just schedule something to run later. What are the best practices for creating this kind of blocking delay in JavaScript?
I’ve worked with legacy sync codebases and yeah, there are rare cases where you actually need blocking delays - usually when dealing with old systems or specific hardware APIs. But your current implementation will max out CPU usage during the wait. If you absolutely can’t refactor to async/await, try performance.now() instead of new Date() for better precision. Also throw in some requestIdleCallback or small setTimeout calls in your loop so the browser can breathe. Honestly though, most times developers think they need sync delays, you can just restructure the calling code to work with promises instead.
Those basic delay methods work fine until you hit complex workflows with multiple delays and conditions. Then it becomes a mess.
I hit this exact issue building automation sequences that needed precise timing between API calls. All those nested async functions and promise chains? Absolute nightmare to maintain.
What fixed it for me was switching to an automation platform that handles timing naturally. You can build workflows with built-in delays, conditional pauses, and dynamic timing based on API responses or other triggers.
Instead of writing delay functions, you just drag and drop delay nodes between actions. Need a 5-second pause? Drop in a delay block. Need to wait for a condition? Add a conditional wait.
This kills the code complexity entirely. No more blocking threads or managing promise chains. The platform handles execution and timing automatically.
For JavaScript automation with proper delay handling, check out https://latenode.com
Your approach creates a “busy loop” that wastes CPU and blocks the main thread. I froze an entire web app doing this exact thing. The async/await solution mentioned above is definitely the way to go. But since you said you need actual blocking - if you’re in Node.js, try Atomics.wait() for true blocking delays. Just know it needs SharedArrayBuffer support and won’t work in browsers. That said, I’d really reconsider if you actually need blocking behavior. Every time I thought I needed synchronous delays, restructuring with promises was cleaner and easier to maintain. Plus the non-blocking approach stops users from thinking your app crashed when it hangs.
Your current approach freezes the entire browser tab and makes your app unresponsive. Don’t do that.
Use async/await with Promise-based delays instead - it’s the modern way to handle delays in JavaScript. Here’s how:
function delay(ms) {
return new Promise(resolve => setTimeout(resolve, ms));
}
async function myFunction() {
console.log('Before delay');
await delay(2000);
console.log('After delay');
}
This keeps your UI responsive and follows standard JavaScript practices. If you really need synchronous blocking behavior, you should rethink your architecture - JavaScript’s designed to be asynchronous.
just use setTimeout wrapped in a promise like everyone else said. your current approach will destroy performance and make everything lag horribly. i’ve made this mistake before - users absolutely hate when apps freeze up. the async approach looks intimidating at first, but it’s much better once you get the hang of it.
That busy loop you’re using kills performance. Had the same problem with real-time data processing - thought I needed sync delays between database calls. It’s not just CPU usage; you’re blocking the entire event loop. If you’re really stuck with sync behavior, try the sleep-sync package for Node.js. Uses native bindings for actual blocking without CPU spinning. But that’s last resort stuff. Most of the time, what looks like needing blocking delays is actually bad design. I’ve had better luck with state machines or queue-based approaches for timing stuff. Code stays cleaner and you dodge all the threading nightmares.