Summary

  • O W3C publicou o primeiro rascunho de Web Workers em 23 de abril de 2009. A página podia iniciar um programa em ambiente paralelo separado e trocar mensagens com ele.
  • No exemplo dos números primos, o worker fazia a busca e enviava cada novo resultado para a página exibir enquanto ela continuava a responder às interações.

O botão está bem ali. Você clica, ele não responde. O navegador parece ocupado com uma conta que não pode interromper nem para dizer “recebi”. De repente, passado algum tempo, a página acorda e despeja as respostas atrasadas. É como um balcão cujo único atendente foi conferir o estoque no depósito e deixou a fila conversando com a parede.

O primeiro rascunho de Web Workers do W3C, publicado em 23 de abril de 2009, propôs tirar a conta do balcão. A especificação descrevia programas de fundo independentes dos que tratam cliques e outras ações da interface. Seu exemplo procurava números primos: o documento principal cria um worker, ele encontra números e manda resultados sucessivos, e a página os mostra. O balcão pode ouvir o cliente enquanto alguém calcula lá dentro.

A divisão é fácil de seguir. A página cria Worker com a URL de um arquivo de programa. O navegador executa esse arquivo em um ambiente paralelo distinto. Os dois lados conversam por postMessage e tratadores de mensagens. O worker tem a tarefa de calcular; a página controla o que aparece na tela. Quando chega um primo novo, o código da página atualiza o texto. O resultado atravessa um caminho explícito antes de se tornar algo visível para a pessoa.

O rascunho de dezembro de 2009 descreveu essa coordenação por mensagens como uma operação parecida com a de threads. A mensagem separa responsabilidades. A página pede, o worker relata, a página decide se ainda faz sentido mostrar a resposta. Se a pessoa mudou de tarefa no meio do cálculo, um resultado antigo precisa passar por essa decisão. Ter trabalhado muito não dá a um número o direito de tomar a tela de surpresa.

A escolha dos números primos expõe o problema com humor involuntário. Ninguém está esperando um servidor do outro lado do planeta, e a rede não está atrasada. A página fica muda porque o cálculo longo ocupa o lugar onde ela deveria processar gestos. Mover o laço para o worker deixa a interface disponível; quando chega uma nova resposta, ela atualiza o número. O leitor percebe andamento em vez de contemplar um botão em greve.

O pessoal do depósito também consome recursos. O texto do fim de 2009 avisava que workers tinham custo de inicialização e memória por instância. Como contraexemplo, imaginava criar um worker para cada pixel de uma imagem de quatro megapixels. Quatro milhões de auxiliares para quatro milhões de pontos fariam a reunião de equipe durar mais que a tarefa. Uma unidade de trabalho com começo, duração e resultado valia mais que essa multidão.

As versões seguintes detalharam os caminhos de volta. A versão candidata de 2012 distinguiu o worker dedicado do compartilhado. O dedicado se comunica com quem o criou por um canal implícito; o compartilhado aceita conexões de vários contextos da mesma origem por portas. O rascunho de 2015 explicou a criação de Worker, onmessage, postMessage e o MessagePort do modelo compartilhado. Mesmo num navegador, uma boa equipe precisa saber para quem mandar o recado.

Essa fronteira trata do lugar da execução. O armazenamento no navegador responde a outra pergunta: a qual janela ou origem pertencem os dados? Uma página pode guardar uma escolha no lugar adequado e pedir a um worker que faça uma busca custosa. As mensagens ligam uma coisa à outra. O cálculo tem seu local, a interface preserva seu compromisso com a pessoa e a resposta retorna com endereço.

O histórico de publicações do W3C vai do rascunho de 2009 às etapas de 2012 e 2015. Os números primos continuam uma boa demonstração porque simplificam a pergunta: a página consegue pensar sem parar de escutar? Com um trabalhador ao fundo e mensagens trazendo o resultado, a resposta finalmente cabia na própria tela.