Como criar linhas de execução na Web com workers do módulo

Agora é mais fácil mover tarefas pesadas para as linhas de execução em segundo plano com os módulos JavaScript em workers da Web.

Jason Miller

O JavaScript é de linha de execução única, o que significa que ele só pode realizar uma operação por vez. Isso é intuitivo e funciona bem para muitos casos na Web, mas pode se tornar problemático quando precisamos realizar tarefas pesadas, como tratamento de dados, análise, computação ou análise. À medida que aplicativos cada vez mais complexos são disponibilizados na Web, há uma necessidade maior de processamento multithread.

Na plataforma da Web, a principal primitiva para threading e paralelismo é a API Web Workers. Os workers são uma abstração leve sobre as linhas de execução do sistema operacional que expõem uma API de transmissão de mensagens para comunicação entre linhas de execução. Isso pode ser imensamente útil ao realizar computações caras ou operar em grandes conjuntos de dados, permitindo que a linha de execução principal seja executada sem problemas enquanto realiza as operações caras em uma ou mais linhas de execução em segundo plano.

Veja um exemplo típico de uso de worker, em que um script de worker detecta mensagens da linha de execução principal e responde enviando as próprias mensagens:

page.js:

const worker = new Worker('worker.js');
worker.addEventListener('message', e => {
  console.log(e.data);
});
worker.postMessage('hello');

worker.js:

addEventListener('message', e => {
  if (e.data === 'hello') {
    postMessage('world');
  }
});

A API Web Worker está disponível na maioria dos navegadores há mais de dez anos. Isso significa que os workers têm excelente suporte do navegador e são bem otimizados, mas também que eles são muito anteriores aos módulos JavaScript. Como não havia um sistema de módulos quando os workers foram projetados, a API para carregar código em um worker e compor scripts permaneceu semelhante às abordagens de carregamento de script síncrono comuns em 2009.

Histórico: workers clássicos

O construtor Worker usa um URL de script clássico, que é relativo ao URL do documento. Ele retorna imediatamente uma referência à nova instância de worker, que expõe uma interface de mensagens e um método terminate() que interrompe e destrói o worker imediatamente.

const worker = new Worker('worker.js');

Uma função importScripts() está disponível nos workers da Web para carregar mais código, mas ela pausa a execução do worker para buscar e avaliar cada script. Ele também executa scripts no escopo global, como uma tag <script> clássica, o que significa que as variáveis em um script podem ser substituídas pelas variáveis em outro.

worker.js:

importScripts('greet.js');
// ^ could block for seconds
addEventListener('message', e => {
  postMessage(sayHello());
});

greet.js:

// global to the whole worker
function sayHello() {
  return 'world';
}

Por isso, os workers da Web sempre tiveram um efeito desproporcional na arquitetura de um aplicativo. Os desenvolvedores precisaram criar ferramentas e soluções alternativas inteligentes para possibilitar o uso de workers da Web sem abrir mão das práticas modernas de desenvolvimento. Por exemplo, bundlers como o webpack incorporam uma pequena implementação de carregador de módulo no código gerado que usa importScripts() para carregamento de código, mas envolve módulos em funções para evitar colisões de variáveis e simular importações e exportações de dependências.

Inserir workers do módulo

Um novo modo para workers da Web com os benefícios de ergonomia e desempenho dos módulos JavaScript está sendo lançado no Chrome 80, chamado de workers de módulo. O construtor Worker agora aceita uma nova opção {type:"module"}, que muda o carregamento e a execução do script para corresponder a <script type="module">.

const worker = new Worker('worker.js', {
  type: 'module'
});

Como os workers de módulo são módulos JavaScript padrão, eles podem usar instruções de importação e exportação. Como em todos os módulos JavaScript, as dependências são executadas apenas uma vez em um determinado contexto (linha de execução principal, worker etc.), e todas as importações futuras fazem referência à instância do módulo já executada. O carregamento e a execução de módulos JavaScript também são otimizados pelos navegadores. As dependências de um módulo podem ser carregadas antes da execução do módulo, o que permite que árvores de módulos inteiras sejam carregadas em paralelo. O carregamento de módulos também armazena em cache o código analisado, o que significa que os módulos usados na linha de execução principal e em um worker só precisam ser analisados uma vez.

A mudança para módulos JavaScript também permite o uso da importação dinâmica para o carregamento lento de código sem bloquear a execução do worker. A importação dinâmica é muito mais explícita do que usar importScripts() para carregar dependências, já que as exportações do módulo importado são retornadas em vez de depender de variáveis globais.

worker.js:

import { sayHello } from './greet.js';
addEventListener('message', e => {
  postMessage(sayHello());
});

greet.js:

import greetings from './data.js';
export function sayHello() {
  return greetings.hello;
}

Para garantir um ótimo desempenho, o método importScripts() antigo não está disponível nos workers de módulo. Mudar os workers para usar módulos JavaScript significa que todo o código é carregado no modo estrito. Outra mudança importante é que o valor de this no escopo de nível superior de um módulo JavaScript é undefined, enquanto nos workers clássicos o valor é o escopo global do worker. Felizmente, sempre houve um self global que fornece uma referência ao escopo global. Ele está disponível em todos os tipos de workers, incluindo service workers, e no DOM.

Pré-carregar workers com modulepreload

Uma melhoria significativa de desempenho que vem com os workers de módulo é a capacidade de pré-carregar workers e as dependências deles. Com os workers de módulo, os scripts são carregados e executados como módulos JavaScript padrão, o que significa que eles podem ser pré-carregados e até pré-analisados usando modulepreload:

<!-- preloads worker.js and its dependencies: -->
<link rel="modulepreload" href="worker.js">

<script>
  addEventListener('load', () => {
    // our worker code is likely already parsed and ready to execute!
    const worker = new Worker('worker.js', { type: 'module' });
  });
</script>

Os módulos pré-carregados também podem ser usados pela linha de execução principal e pelos workers de módulo. Isso é útil para módulos importados em ambos os contextos ou nos casos em que não é possível saber com antecedência se um módulo será usado na linha de execução principal ou em um worker.

Antes, as opções disponíveis para pré-carregar scripts de worker da Web eram limitadas e não necessariamente confiáveis. Os workers clássicos tinham o próprio tipo de recurso "worker" para pré-carregamento, mas nenhum navegador implementou <link rel="preload" as="worker">. Como resultado, a principal técnica disponível para pré-carregar workers da Web era usar <link rel="prefetch">, que dependia inteiramente do cache HTTP. Quando usado em combinação com os cabeçalhos de armazenamento em cache corretos, isso possibilitou evitar que a instanciação do worker precisasse esperar para fazer o download do script do worker. No entanto, ao contrário de modulepreload, essa técnica não era compatível com o pré-carregamento de dependências ou a pré-análise.

E os workers compartilhados?

Os workers compartilhados foram atualizados com suporte a módulos JavaScript a partir do Chrome 83. Assim como os workers dedicados, a criação de um worker compartilhado com a opção {type:"module"} agora carrega o script do worker como um módulo, em vez de um script clássico:

const worker = new SharedWorker('/worker.js', {
  type: 'module'
});

Antes do suporte aos módulos JavaScript, o construtor SharedWorker() esperava apenas um URL e um argumento name opcional. Isso vai continuar funcionando para o uso de workers compartilhados clássicos. No entanto, a criação de workers compartilhados de módulo exige o uso do novo argumento options. As opções disponíveis são as mesmas de um worker dedicado, incluindo a opção name, que substitui o argumento name anterior.

E o service worker?

A especificação do service worker já foi atualizada para aceitar um módulo JavaScript como ponto de entrada, usando a mesma opção {type:"module"} que os workers de módulo. No entanto, essa mudança ainda não foi implementada nos navegadores. Quando isso acontecer, será possível instanciar um service worker usando um módulo JavaScript com o seguinte código:

navigator.serviceWorker.register('/sw.js', {
  type: 'module'
});

Agora que a especificação foi atualizada, os navegadores estão começando a implementar o novo comportamento. Isso leva tempo porque há algumas complicações extras associadas à inclusão de módulos JavaScript no service worker. O registro do service worker precisa comparar os scripts importados com as versões anteriores em cache ao determinar se um upgrade deve ser acionado. Isso precisa ser implementado para módulos JavaScript quando usados para service workers. Além disso, os service workers precisam ser capazes de ignorar o cache para scripts em determinados casos ao verificar se há atualizações.

Recursos adicionais e mais informações