Bun 1.4 научился управлять браузером из коробки — тест показал 256 МБ на контейнер

Вышел Bun 1.4 — первый стабильный релиз после того самого переписывания рантайма с Zig на Rust. В заметках к релизу это упомянули почти вскользь, зато выкатили десяток новых API, включая Bun.WebView — встроенное управление браузером без Puppeteer и Playwright. Разработчик Саймон Уиллисон (Simon Willison) тут же попросил Claude Code собрать прототип JSON API для браузерной автоматизации и проверил, сколько памяти это реально требует.

Если вы пишете скрапер, тестируете фронтенд headless-браузером или собираете AI-агента, которому нужно «посмотреть» на страницу — это релиз, который стоит потрогать руками.

Что скрывается за тихим релизом Bun 1.4

Заметки к Bun 1.4 читаются как список из другой лиги: +1 517 тестов из тестового набора Node.js — самый большой скачок совместимости со времён Bun 1.0, свыше 2 900 исправленных багов, снижение простаивающей нагрузки на CPU в 5 раз, экономия памяти до 35% и старт на Linux на 50% быстрее.

При этом полностью переписанный на Rust движок (раньше это был Zig) в тексте релиза почти не выделен — как будто разработчики Bun решили не пугать пользователей громкими формулировками, а показать конкретные цифры.

Кроме Bun.WebView в 1.4 добавили Bun.Image, Bun.markdown, Bun.cron(), Bun.Terminal, флаги bun run --parallel и bun test --parallel, а также команды bun audit fix, bun dedupe и bun prune. Для тех, кто держит монорепы и CI-пайплайны на Bun, это уже само по себе повод обновиться.

Bun.WebView: браузер прямо в рантайме

Главная новинка для тех, кто занимается автоматизацией — Bun.WebView. Это API первого класса для управления браузером прямо из ядра Bun, без установки отдельных npm-пакетов вроде puppeteer-core.

Работает он двумя способами:

• на macOS — через нативный WebKit (тот же движок, что в Safari);
• на других системах — через управление локальным процессом Chromium по Chrome DevTools Protocol (CDP), тому же протоколу, на котором построены Puppeteer и Playwright.

Идея в том, чтобы дать разработчикам встроенный инструмент для задач, которые раньше требовали внешних зависимостей: сделать скриншот страницы, выполнить JavaScript в контексте загруженной страницы, получить результат обратно в Node/Bun-код.

Стоит отметить, что похожая идея уже существовала в экосистеме — например, пакет webview-bun с GitHub даёт биндинги к библиотеке webview для десктопных GUI-приложений (на Linux требует GTK 4 и WebkitGTK 6). Но Bun.WebView встроен в сам рантайм и заточен именно под автоматизацию, а не под создание приложений с интерфейсом.

Как устроен прототип JSON API

Уиллисон — автор CLI-инструмента shot-scraper, который умеет открывать страницы и выполнять на них JavaScript через командную строку. Естественным экспериментом стало попросить Claude Code (веб-версию агента) собрать аналог shot-scraper, но в виде HTTP-сервиса с JSON API — то есть открыть страницу и выполнить JS можно было бы обычным запросом, без установки CLI.

Логика такого сервиса простая и повторяет паттерн shot-scraper:

POST /run
{
  "url": "https://example.com",
  "javascript": "document.title"
}

Сервер открывает URL в headless-браузере через Bun.WebView, выполняет переданный JavaScript в контексте страницы и возвращает результат в JSON:

{
  "result": "Example Domain",
  "status": "ok"
}

Реализация сервера — на TypeScript, весь код Уиллисон опубликовал в отдельном репозитории. Основная цель эксперимента была не столько написать production-ready сервис, сколько проверить, сколько ресурсов требует такой подход на практике — особенно в контейнерах, где память на счету.

Сколько памяти нужно на самом деле

Уиллисон протестировал прототип с ограничениями по cgroups (механизм Linux для ограничения ресурсов процессов, на нём строится большинство контейнерных рантаймов). Результат: полноценный Chrome под управлением CDP укладывается в контейнер на 192–256 МБ, даже на сложных страницах.

Это заметно меньше, чем принято закладывать под классические связки с Puppeteer или Playwright, где headless-Chrome в контейнерах часто требует 512 МБ и выше с запасом на пиковые нагрузки. Если цифры подтвердятся на более широком наборе сайтов, это открывает возможность гонять браузерную автоматизацию на дешёвых serverless-инстансах или в плотных Kubernetes-кластерах без переплаты за память.

Подводные камни

Стоит помнить, что это ранний прототип, а не готовое решение для продакшена. Несколько моментов, на которые стоит обратить внимание перед тем, как тащить Bun.WebView в боевой код:

• Разное поведение на macOS и Linux. На macOS используется нативный WebKit, а на Linux/Windows — CDP-управление Chromium. Это два разных движка рендеринга, и страница технически может вести себя по-разному между окружениями — стоит закладывать тесты на обеих платформах, если сервис должен работать одинаково везде.
• Rust-переписывание ещё «молодое». Это первый стабильный релиз после смены Zig на Rust под капотом. Даже при 2 900+ исправленных багах и добавленных тестах из Node.js test suite, стоит закладывать время на регрессионное тестирование перед миграцией критичных сервисов.
• Память протестирована не на всём вебе. Цифры 192–256 МБ получены на наборе сложных страниц, но не на репрезентативной выборке всего интернета. Тяжёлые SPA с бесконечным скроллом или множеством WebGL-канвасов могут вести себя иначе.
• CDP — это внешняя зависимость от Chromium. Даже при встроенном API реальная работа всё ещё делается локальным процессом Chromium, который нужно доставить в контейнер — это добавляет вес образу, даже если сам рантайм память экономит.

Что попробовать дальше

Если вы уже используете Bun в проекте, обновление до 1.4 стоит сделать хотя бы ради снижения CPU и памяти в холостом режиме — это бесплатный выигрыш без изменения кода. Для тех, кто пишет скраперы, тестирует фронтенд или собирает агентов с доступом к браузеру, имеет смысл:

1. Поднять Bun 1.4 в тестовом окружении и сравнить время старта и потребление памяти с текущим стеком на Puppeteer/Playwright.
2. Протестировать Bun.WebView на своём наборе целевых страниц — особенно если это сложные SPA, а не статичный HTML.
3. Замерить память в контейнере через cgroups-лимиты, как это сделал Уиллисон, прежде чем закладывать бюджет в infra-конфиги.
4. Присмотреться к остальным новинкам релиза — Bun.cron() и bun run --parallel могут упростить пайплайны без дополнительных зависимостей.

FAQ

Что такое Bun.WebView и зачем он нужен?

Это встроенный в Bun 1.4 API для управления браузером — загрузки страниц и выполнения JavaScript в их контексте. На macOS работает через нативный WebKit, на других системах — через CDP-управление локальным Chromium. Заменяет часть задач, которые раньше требовали Puppeteer или Playwright.

Сколько памяти нужно для Bun.WebView в продакшене?

По тестам с cgroups-ограничениями — от 192 до 256 МБ на контейнер для полноценного Chrome даже на сложных страницах. Точная цифра зависит от сайтов, с которыми вы работаете.

Bun 1.4 действительно переписан на Rust?

Да, рантайм переписан с Zig на Rust, хотя в официальных заметках к релизу это упомянуто без акцента — упор сделан на конкретные метрики: снижение CPU, памяти и время старта.

Чем Bun.WebView отличается от webview-bun с GitHub?

webview-bun — это сторонний пакет для создания десктопных GUI-приложений на базе библиотеки webview, требующий GTK 4 и WebkitGTK 6 на Linux. Bun.WebView встроен в сам рантайм Bun и предназначен для браузерной автоматизации, а не для интерфейсов приложений.

Стоит ли обновляться на Bun 1.4 прямо сейчас?

Если критичны стабильность и время на регрессионное тестирование — разумно сначала прогнать проект в тестовом окружении, учитывая, что это первый стабильный релиз после смены языка рантайма. Для новых или некритичных проектов обновление можно делать сразу ради выигрыша по памяти и CPU.

Источники

• Simon Willison: A shot-scraper-style JSON API on Bun 1.4's new Bun.WebView