Firefox в webassembly: браузер внутри браузера

Запустить полноценный Firefox прямо в веб-странице — звучит как задачка из категории «а что если скрестить ёжика с ужом». Но именно это и сделали в Puter Labs. Берём движок Gecko, компилируем его в WebAssembly — и получаем браузер, работающий внутри другой веб-страницы.

Выглядит как фокус, но за этим стоит серьёзная инженерия.

Как это устроено

Идея простая на словах: берём код на C++, компилируем в WebAssembly — формат инструкций, который понимает браузер. Получается что-то вроде портативной виртуальной машины внутри браузера.

КОМПИЛЯЦИЯ FIREFOX В WASM
──────────────────────────
  Firefox (C++)  ──▶ Emscripten  ──▶  WebAssembly
                    компилятор        бинарный код
                         │
                         ▼
  ┌─────────────────────────────────────┐
  │      Веб-страница                   │
  │  ┌─────────────────────────────┐    │
  │  │   Firefox (WASM-модуль)     │    │
  │  │                             │    │
  │  │  ┌─────┐    ┌──────────┐   │    │
  │  │  │Gecko│    │ WebGL    │   │    │
  │  │  │движок│   │рендеринг│   │    │
  │  │  └─────┘    └──────────┘   │    │
  │  └─────────────────────────────┘    │
  └─────────────────────────────────────┘

На практике каждая из этих задач потребовала отдельного решения. Браузер — это не просто движок рендеринга. Там сетевые запросы, файловая система, доступ к устройствам. В демо Puter эта проблема решена через Wisp — прокси-сервер на WebSocket, который пропускает трафик через себя. Получается изолированная песочница: гостевая страница загружается через прокси, а не напрямую.

Для рендеринга используется WebGL. Это позволяет выводить интерфейс Firefox прямо на canvas браузера.

Зачем это нужно

Честный ответ: пока ниша применения не определена. Это демонстрация, proof of concept — показать, что так вообще можно.

Возможные сценарии использования:

• Изолированные среды для тестирования. Можно запустить Firefox любой версии прямо на странице, не устанавливая ничего. Удобно для QA-инженеров, которым нужно проверить баг в конкретной версии.
• Демо и презентации. Вместо скриншотов — живой браузер, с которым можно взаимодействовать.
• Исследования и анализ. Можно изучать поведение страниц в «чистом» Firefox без влияния расширений и настроек системы.
• Архивная совместимость. Запускать старые версии браузеров для проверки старых сайтов.

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

Ограничения: честный взгляд

WebAssembly работает медленнее нативного кода. Firefox, скомпилированный в WASM, — это не та скорость, к которой привыкли пользователи настольного браузера. JIT-компиляция экспериментальная, местами с багами.

ПРОИЗВОДИТЕЛЬНОСТЬ: СРАВНЕНИЕ
──────────────────────────────
  Нативный Firefox  ████████████████████  100%
                                       
  Firefox в WASM    ████████░░░░░░░░░░░░   30-50%
  (эксперимент)     (оценка, зависит от задачи)

  ───▶  В 2-3 раза медленнее в CPU-bound задачах
        когда компьютер «думает», а не «рисует»
  ───▶  Память: требуется больше для WASM-рантайма
        среда выполнения, которая запускает WebAssembly-код

Память — отдельная история. WebAssembly работает в ограниченном адресном пространстве. Для сложных страниц с тяжёлыми фреймворками это может стать узким местом.

Совместимость с веб-стандартами тоже не стопроцентная. Не всё, что работает в нативном Firefox, будет работать здесь. Это логично для эксперимента, но стоит учитывать.

Что это значит для веба

WebAssembly появился в 2017 году и поначалу использовался для ускорения тяжёлых вычислений в браузере: игр, видеокодирования, научных расчётов. Потом начался перенос десктопных приложений: SQLite, Python, даже Photoshop.

Теперь дошла очередь до браузеров. И это не просто фантазия — это демонстрация того, что границы «веб-приложения» размываются.

Через несколько лет, вероятно, будем запускать полноценные IDE, почтовые клиенты, CAD-системы в одну строку JavaScript на любом сайте. Без установки. Без зависимостей от операционной системы.

Firefox в WebAssembly — это не замена привычному браузеру. Это окно в будущее, где приложения живут в сети, а не на диске.

Моя оценка

Я вижу в этом не столько готовый продукт, сколько индикатор направления. Возможный вопрос: «А что насчёт Chromium?» — ответ: да, это тоже возможно. Но сама возможность — уже прорыв.

Меня зацепило другое: Wisp-прокси и архитектура песочницы. Это значит, что изоляция работает не только на уровне браузера, но и на уровне сети. Можно контролировать, к каким доменам обращается «гостевой» браузер.

Для разработчиков AI-агентов это особенно значимо. Модели, которые «читают» веб-страницы, часто страдают от несовместимости с динамическим контентом. Полноценный браузер в песочнице — это другой уровень надёжности.

Попробовать демо стоит хотя бы ради любопытства. Поиграйтесь, посмотрите на скорость, на ограничения. Это помогает чувствовать, куда катится платформа.

Выводы

Firefox в WebAssembly — это не про замену обычного браузера, а про новый класс веб-приложений и новые способы изоляции, тестирования и автоматизации.

Сильная сторона эксперимента — архитектура: браузер, рендеринг и сеть разделены, а песочница даёт контроль над поведением гостевой среды.

Слабое место — производительность и ограниченная совместимость. Но для proof of concept это не минус, а честная граница возможностей.

Ссылки

• Firefox in WebAssembly — Puter Labs — первичный источник
• Emscripten Toolchain — компилятор для переноса кода в WebAssembly
• Wisp — WebSocket Proxy — прокси-сервер для сетевой изоляции