Guia completo de sleep() em JavaScript 2025: durma como um Jedi

Introdução: por que o JavaScript não tem um sleep() normal?

Olá, colegas desenvolvedores! Se você já migrou para JavaScript vindo do Python, PHP ou Java, com certeza já se perguntou: "Cadê meu querido sleep(1) para fazer o programa dormir por um segundo?". E, ao fuçar na documentação, descobriu com surpresa que essa função não existe no JavaScript puro.

Isso não é um bug, é uma feature. JavaScript é uma linguagem single-thread que opera no Event Loop. Se simplesmente bloqueássemos a thread por um segundo, a interface inteira congelaria, os cliques parariam de ser processados, animações e requisições seriam interrompidas. Um sleep() bloqueante é um antipadrão para a web.

Mas isso não significa que não podemos fazer uma pausa. A pergunta "What is the JavaScript version of sleep()?" no Stack Overflow já acumulou centenas de milhares de visualizações, e em 2025 temos todo um arsenal de soluções — das mais simples às mais sofisticadas.

Neste artigo (especialmente para o portal educacional pythonlib.ru), vamos explorar todas as formas legais de fazer o JavaScript "dormir", seus prós e contras, e definir as melhores práticas para cada situação.

A forma mais correta: async/await e Promises

A partir do ES2017, o JavaScript ganhou assincronidade turbinada com async/await. Se você quer fazer uma pausa sem bloquear a thread principal, precisa de uma função que retorne uma Promise resolvida após um determinado tempo.

Aqui está nossa sleep() personalizada para 2025:

// Função de delay universal\nfunction sleep(ms) {\n    return new Promise(resolve => setTimeout(resolve, ms));\n}\n\n// Como usar\nasync function demo() {\n    console.log('Começando...');\n    await sleep(2000); // Aguarda 2 segundos\n    console.log('2 segundos se passaram!');\n}\n\ndemo();\n

Este é um sleep não bloqueante. Enquanto await sleep(2000) é executado, o resto do código (event handlers, outras funções assíncronas) continua rodando. O Event Loop não dorme — ele apenas adia a execução das próximas linhas até que a Promise seja resolvida.

Por que essa é a melhor prática?

\n
• Não bloqueia a UI — a interface permanece responsiva.
\n
• Sintaxe padrão — lê-se como código síncrono comum.
\n
• Ideal para Node.js — o servidor não trava.
\n
• Suporte universal — navegadores modernos e Node.js 8+.
\n

O clássico setTimeout()

Antes da era async/await, usávamos setTimeout(). Ele ainda é válido e útil, mas exige callbacks, o que pode levar ao "callback hell".

console.log('Início');\nsetTimeout(() => {\n    console.log('1.5 segundos se passaram');\n}, 1500);\nconsole.log('Fim (executado imediatamente)');\n

A saída no console será: Início, depois Fim (instantaneamente), e só então 1.5 segundos se passaram. Isso não é exatamente um sleep() no sentido clássico, mas para cenários simples é perfeito.

Quando usar setTimeout?

\n
• Quando você precisa executar uma ação uma única vez após um intervalo.
\n
• Em animações (por exemplo, iniciar um efeito após 300 ms).
\n
• Em scripts simples sem lógica complexa.
\n

Sleep bloqueante (e por que você nunca deve fazer isso)

Sim, tecnicamente você pode congelar a thread com um loop vazio. Mas isso é puro mal.

function blockSleep(milliseconds) {\n    const start = Date.now();\n    while (Date.now() - start < milliseconds) {\n        // Vazio — o processador esquenta, a aba trava\n    }\n}\n\nconsole.log('Início');\nblockSleep(3000);\nconsole.log('3 segundos se passaram (mas o navegador travou)');\n

Este código faz exatamente o que você pede: interrompe a execução