Bun 1.4 traz Bun.WebView e dispensa Puppeteer para automação de browser

O lançamento do Bun 1.4, primeira versão estável desde a controversa reescrita de Zig para Rust↳Rust7 conteúdosDesmistificando Rust: a linguagem segura e rápida que você precisa conhecerDev (Back & Front) · out 2024Como criar seu primeiro Programa em Rust com Solana PlaygroundDev (Back & Front) · mai 2026Rust no ranking: a segurança de memória perdeu a guerra corporativa?Marketing Tech · abr 2026Ver tudo em Dev (Back & Front) →, veio recheado de novidades: Bun.Image, Bun.markdown, Bun.cron(), Bun.Terminal, bun run --parallel, bun audit fix e mais de 2.900 correções, segundo as notas de release. Mas a adição que mais chamou atenção de quem trabalha com automação e coleta de dados foi o Bun.WebView: suporte de primeira classe a automação de browser embutido no core do Bun.

Simon Willison, em post no seu blog em 20 de agosto de 2026, colocou o recurso à prova construindo uma API HTTP de ~150 linhas de TypeScript e zero dependências que replica o comportamento do seu CLI shot-scraper. O resultado mostra algo relevante para o dia a dia: dá para carregar uma página, rodar JavaScript arbitrário nela e tirar screenshots sem instalar Puppeteer ou Playwright.

Como o Bun.WebView funciona por baixo

O Bun.WebView não reinventa o motor de renderização. Ele usa dois backends dependendo do sistema:

• No macOS, controla o WebKit nativo do sistema (o mesmo motor do Safari).
• Em outras plataformas, controla um processo local do Chromium via Chrome DevTools Protocol (CDP), o mesmo protocolo que Puppeteer e Playwright usam por baixo dos panos.

A diferença é onde mora a orquestração. Em vez de uma biblioteca Node inteira mediando a conversa com o browser, o Bun embute essa camada no próprio runtime. Para o dev, isso significa um import a menos no package.json e um node_modules bem mais magro, sem o download de centenas de MB de binário de browser que o Playwright costuma arrastar.

Vale o alerta: o recurso é experimental. API experimental no Bun tem histórico de mudar entre releases menores, então não é candidato a produção crítica ainda.

O protótipo: uma tab por requisição

O servidor que Willison montou (com ajuda do Claude Code for web, como ele registra no post) expõe três rotas:

• /javascript — carrega uma URL, executa um trecho de JS na página e devolve o retorno como JSON.
• /screenshot — captura a página em PNG, JPEG ou WebP.
• /healthz — checagem de saúde do serviço.

O desenho de concorrência é o ponto interessante: o serviço cria uma aba de browser nova por requisição. Isso isola cada chamada (uma página pesada não contamina a próxima) e permite processar requisições em paralelo, com resultados e erros sempre serializados como JSON. É o padrão que faz sentido para um serviço de scraping ou de teste de integração, onde cada job precisa de um contexto limpo.

Na prática, um cliente faria algo como enviar { "url": "https://exemplo.com", "javascript": "document.title" } para /javascript e receber o título da página de volta. Para quem já usa o shot-scraper na linha de comando, a semântica é familiar, só que agora exposta como serviço HTTP e rodando sobre o runtime do Bun.

O número que importa: RAM

Willison declarou que parte da motivação era medir quanta memória um serviço desses consome, já que rodar um Chrome completo nunca é barato. Testando com cgroups, ele chegou a um container de 192MB a 256MB para dar conta de um Chrome inteiro contra páginas complexas.

Esse número é o dado mais útil do experimento para quem vai dimensionar infraestrutura. Rodar automação de browser em containers pequenos é notoriamente arriscado (o Chrome adora estourar OOM em páginas gordas), e ter uma faixa concreta como referência ajuda a definir limites de container antes de o serviço começar a morrer em produção. Ainda assim, é uma medição pontual: páginas mais pesadas, muitas abas concorrentes ou vazamentos do processo podem empurrar esse teto para cima.

O que isso muda para quem constrói no Brasil

Para times brasileiros que fazem scraping, monitoramento de páginas ou testes de integração de frontend, o apelo é direto: menos dependências e menos superfície de build. Manter uma stack de Playwright atualizada, com o binário de browser certo para cada ambiente de CI, é uma dor conhecida. Uma solução embutida no runtime reduz esse atrito.

Há também o ângulo de custo de infra: serviços de scraping tendem a rodar em containers efêmeros, e cada dependência a menos e cada MB de imagem a menos contam quando se escala horizontalmente. A faixa de 192MB a 256MB por instância dá um ponto de partida para calcular quantas réplicas cabem num plano de cloud.

Mas cabe o ceticismo de sempre. Playwright e Puppeteer não são pesados à toa: entregam APIs maduras de espera por seletores, interceptação de rede, emulação de dispositivos, auto-wait e um ecossistema enorme de plugins (stealth, por exemplo). O Bun.WebView é, hoje, uma primitiva de baixo nível para carregar página, rodar JS e tirar foto. Fluxos complexos de automação (login com múltiplos passos, esperar por requisições XHR específicas, lidar com anti-bot) provavelmente vão exigir muito código manual que essas bibliotecas já resolvem.

Quando NÃO vale a pena

• Produção crítica agora: sendo experimental, a API pode mudar. Não amarre um pipeline de negócio a ela ainda.
• Automação complexa: se você já depende de recursos avançados do Playwright (traces, auto-wait, network mocking), migrar para uma primitiva mais crua é regressão, não ganho.
• Cross-browser real: o comportamento difere entre o WebKit do macOS e o Chromium via CDP em Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps →. Testar em macOS e rodar em Linux pode gerar surpresas de renderização.

Para quem quer uma prova de conceito rápida de coleta de dados ou um serviço interno de screenshots rodando sobre Bun, porém, o experimento de Willison mostra que já dá para fazer isso hoje com pouquíssimo código. O código-fonte do servidor está referenciado no post original, e é um bom ponto de partida para adaptar as três rotas às suas necessidades. Vale acompanhar a evolução do Bun.WebView nas próximas releases antes de apostar mais fichas nele.

Fonte: Simon Willison