r3tam blog

WebAssembly в 2026: состояние экосистемы, производительность и реальные кейсы

WebAssembly в 2026: состояние экосистемы, производительность и реальные кейсы

WebAssembly начинался как способ запускать C++ в браузере. В 2026 году это универсальный бинарный runtime, который выполняется в браузерах, на edge-узлах, в serverless-функциях и даже в пайплайнах AI-инференса. W3C ратифицировал Wasm 3.0 как формальный стандарт в сентябре 2025 года, WASI Preview 2 стабилен, а в июне 2026 вышла WASI 0.3 с нативным async. Экосистема перешла от стадии «можем ли мы?» к стадии «почему мы ещё не сделали это?».

В этой статье разберём, что реально работает в 2026 году: стандарты, производительность, инструменты, production-кейсы от Figma до Shopify, и — что не менее важно — когда WebAssembly не стоит использовать.

Стандарты и спецификации: Wasm 3.0, WASI 0.3 и Component Model

Сентябрь 2025 года стал поворотным моментом: W3C ратифицировал Wasm 3.0 как формальный стандарт. В феврале 2026 года вышла WASI 0.3.0 (Preview 3) — последняя версия WebAssembly System Interface с нативной поддержкой асинхронного I/O через futures и streams. Это закрыло последний крупный разрыв между Wasm и традиционными серверными runtime.

WASI Preview 2 (0.2), стабилизированный ещё в январе 2024, включает семь ключевых API: wasi:io, wasi:clocks, wasi:random, wasi:filesystem, wasi:sockets, wasi:cli и wasi:http. Все они реализованы через Component Model, что обеспечивает модульность, виртуализацию и языковую независимость.

Главное новшество WASI 0.3 — перенос async-примитивов из wasi:io в канонический ABI Component Model. То, что раньше требовало акробатики с pollables и input-streams, теперь работает «из коробки» на уровне бинарного формата. По словам разработчиков Bytecode Alliance, большинство изменений с 0.2 на 0.3 — чисто механические: сигнатуры стали короче и эргономичнее.

На горизонте — Component Model 1.0. Как рассказали Люк Вагнер и Алекс Крайтон на Wasm I/O 2026 в Барселоне, версия 1.0 будет включать только «лучшие части» текущего P3-спека. Стабильная обратная совместимость поддерживается начиная с P1: модули для P1 продолжают работать, для P2 — работают, и для P3 — тоже будут работать через адаптеры.

Производительность: почему cold start меняет правила игры

Главный технический аргумент в пользу Wasm в 2026 году — время холодного старта. Вот сравнение, которое приводит в своей статье молоджинский инженер Эсса Мамдани:

| Runtime | Cold start |

|---------|------------|

| AWS Lambda (Node) | ~350 ms |

| Cloudflare Workers (JS isolate) | ~5 ms |

| Fastly Compute@Edge (Wasm) | <1 ms |

| Wasmtime + pooling allocator | ~50 µs |

| WasmEdge AOT | ~30 µs |

Контейнер стартует за 50–500 ms, Node.js Lambda — за 200–400 ms, Wasm-модуль — за 1–5 ms. Потребление памяти на инстанс: ~1 MB у Wasm против 10+ MB у контейнера. В масштабах тысяч инстансов разница становится драматической: 10x плотность на один узел Kubernetes и near-instant горизонтальное масштабирование.

По скорости выполнения Wasm достиг 70–95% от нативного кода. На бенчмарках с SIMD, потоками и tail-call — обработка изображений, криптография, ML-инференс — результат часто превышает 90% от native. Wasmer 6.0 показывает 95% от native-скорости с приростом 30–50% к версии 5.0.

Ключевые техники оптимизации:

  • AOT-компиляция через LLVM — практически нулевой cold start
  • Pooling allocator — переиспользование памяти без фрагментации при тысячах инстансов
  • Pre-compilation (.cwasm) — артефакты AOT дают cold start в десятки микросекунд
  • Epoch-based interruption — принудительная остановка runaway-циклов в многопользовательских средах

Fastly Compute@Edge, например, предзагружает каждый .wasm в data plane и выделяет per-request инстансы, полностью исключая накладные расходы на компиляцию.

Экосистема runtime'ов: кто есть кто

Wasmtime — де-факто эталонный runtime от Bytecode Alliance. Получил статус Core Project, выходит ежемесячными релизами (до версии 45+ к середине 2026). Поддерживает Component Model как first-class citizen, pooling allocator, epoch-based interruption, асинхронность через Tokio. LTS-канал (каждый 12-й релиз) даёт два года поддержки безопасности.

Wasmer — сфокусирован на edge и AI. Wasmer 6.0 достиг 95% от native-скорости. Wasmer Edge — собственный edge PaaS, конкурент Cloudflare Workers. Недавно представил Edge.js — JavaScript-совместимый runtime, работающий внутри Wasm-песочницы, с совместимостью с Node.js v24 (проходит 3592 из 3626 тестов). Интеграции с JS, Python, PHP.

WasmEdge — специализируется на AI-инференсе на edge. Работает на устройствах с 64 MB RAM. Поддержка ggml для запуска LLM, интеграция с ONNX Runtime. Используется в IoT и embedded-сценариях.

Fermyon Spin — после приобретения Akamai за нераскрытую сумму получил доступ к 4000+ edge-локациям. CNCF Sandbox-проект. HTTP-triggered функции с cold start <1 ms. Самый простой путь начать с server-side Wasm.

wasmCloud 2.0 (март 2026) — превратил WebAssembly в first-class Kubernetes citizen. Актор с 5 MB footprint заменяет 200 MB Alpine-контейнер. Нативная поддержка NATS, Component Model и WIT.

Extism — фреймворк для плагинных систем. Хост-агностичные SDK для JS, Python, PHP, Rust, Go. Используется там, где нужно выполнять пользовательский код с гарантиями изоляции.

Реальные кейсы: кто использует Wasm в production

Figma скомпилировала свой C++ rendering engine в Wasm через Emscripten. Результат — 3x более быстрая загрузка для всех размеров документов. Это был полноценный production-переход, а не proof of concept.

Google Sheets мигрировала свой вычислительный引擎 на WasmGC, добившись 2x ускорения пересчёта. Таблицы с миллионами ячеек теперь обрабатываются менее чем за секунду.

Shopify Functions позволяет мерчантам писать кастомную логику скидок и checkout'а на Rust, компилировать в Wasm и выполнять на edge с жёстким лимитом в 10 ms. Ни одна Node.js-функция не могла гарантированно уложиться в этот бюджет при масштабировании.

Akamai + Fermyon — после приобретения Fermyon, Akamai развернул serverless Wasm-функции на 4000+ edge-локаций. Финтех-кейс: 12 микросервисов мигрировали с EKS на Fermyon Spin, получив 10x больше функций на узел при радикально сниженной стоимости запроса.

Cloudflare Workers — 330+ глобальных локаций, нативный Wasm с самого запуска. Cloudflare Workers AI запускает Llama-3-8b на edge со speculative decoding, достигая 2–4x ускорения инференса.

Adobe Photoshop Web — использует Wasm для сложного рендеринга в браузере, деля C++ код между десктопом и веб-версией.

Vault-Tools — 45 инструментов обработки файлов, работающих полностью в браузере через Rust → Wasm. Ни одного бэкенда, ни одной Lambda, ни одного S3.

Wasmer Edge.js — полный Node.js v24-совместимый runtime внутри Wasm-песочницы. Построен за 2 недели с помощью Codex CLI (против оценки в 1 год инженерной работы). Запускает Next.js, Astro и любые другие фреймворки без модификаций.

Когда выбирать WebAssembly

Исходя из практического опыта команд, успешно внедривших Wasm в 2025–2026 годах, можно сформулировать чёткие критерии:

Выбирайте Wasm, если:

  • Вам критичен sub-millisecond cold start (edge-функции, burst-серверлесс, выполнение плагинов)
  • Нужна сильная изоляция между tenants (SaaS с пользовательским кодом)
  • Workload stateless или near-stateless
  • Примеры: A/B тесты на CDN-edge, пользовательские скрипты трансформации, языко-независимые плагины, middleware перед stateful-сервисами

Пропустите Wasm, если:

  • Вам нужна база данных или брокер сообщений внутри модуля
  • Требуется multi-threaded compute (WASI всё ещё не имеет нативной модели параллельных вычислений)
  • Workload сильно зависит от Linux-экосистемы (npm-нативные зависимости, kernel-модули)

Паттерн, который стабильно работает: Wasm на периметре, контейнеры в ядре. Тяжёлая оркестрация для stateful-нагрузок, лёгкие Wasm-runtime для burst-stateless-слоя.

Языки и инструменты

Rust остаётся безусловным лидером экосистемы. wasm-pack, wasm-bindgen и cargo component — стандартный стек. Инструментарий на годы опережает альтернативы.

Kotlin/Wasm — самый активно развивающийся JVM-adjacent toolchain. JetBrains довела компилятор до Beta (сентябрь 2025). Compose for Web (Beta) показывает 3x производительность против Kotlin/JS в UI-нагрузках. WasmGC поддерживается всеми браузерами с декабря 2024. Важный нюанс: браузерная история готова к production, серверная (WASI) — на 12–18 месяцев от production-уверенности.

Python через Pyodide (CPython, скомпилированный в Wasm) значительно повзрослел. В апреле 2026 появились 100 KB Python→Wasm компиляторы, позволяющие запускать скрипты обработки данных на edge без 200 MB контейнера.

Go — компилируется в Wasm, но без поддержки goroutines в браузере (требуется WASI). Хорош для server-side сценариев.

JavaScript через JCO — jco transpile конвертирует любой Wasm component в JavaScript-glue, работающий в любом браузере без нативной поддержки Component Model.

Инструменты сборки: wasm-pack для Rust, wit-bindgen для генерации биндингов по WIT-интерфейсам, jco для JavaScript-экосистемы.

Будущее: Component Model 1.0, Threading и что дальше

После релиза WASI 0.3 основные усилия Bytecode Alliance направлены на Component Model 1.0. Стабильная спецификация ожидается в 2027 году. Ключевые элементы дорожной карты:

  • Нативная поддержка Component Model в браузерах — сейчас jco transpile делает компоненты работоспособными в любом браузере, но нативная реализация упростит спецификацию и улучшит производительность
  • Threading (shared-everything-threads) — следующая критическая фича для server-side Wasm
  • Memory64 — поддержка 64-битной адресации для large model deployment
  • WASI 1.0 — после Component Model 1.0, будет выпущен как зависимый стандарт

На уровне экосистемы: Kubernetes + Wasm становится мейнстримом через SpinKube, wasmCloud 2.0 и WasmEdge RuntimeClass. Базы данных (PostgreSQL, SQLite) начинают поддерживать Wasm UDF. AI-инференс на edge через Wasm + WebGPU — ещё один растущий кластер применений.

Заключение

WebAssembly в 2026 году — это не «убийца Docker» и не «браузерная игрушка». Это легитимная часть cloud-native стека для конкретного класса нагрузок: edge-серверлесс, плагинные системы, многопользовательское выполнение функций. Стандарты стабильны (Wasm 3.0, WASI 0.2/0.3), инструментарий зрел (Wasmtime 45+, Wasmer 6.0, Spin + Akamai), а production-кейсы от Figma, Google, Shopify и Adobe — не единороги, а репрезентативная выборка.

Рекомендация: выберите один низкорисковый высокотрафиковый сервис в вашем стеке — API-шлюз, auth-мидлварь, трансформер данных — и портируйте его в WASI 0.2 компонент. Задеплойте на Wasmtime или Spin. Измерьте cold start и memory footprint. Результаты вас удивят.

Часто задаваемые вопросы

Что такое WebAssembly в 2026 году?

WebAssembly — это универсальный бинарный runtime, работающий в браузерах, на edge-узлах, в serverless-функциях и IoT-устройствах. Поддерживает языки Rust, C/C++, Kotlin, Go, Python и JavaScript. Скорость выполнения — 70–95% от нативного кода.

Что такое WASI?

WebAssembly System Interface — стандартизированный набор API для доступа Wasm-модулей к системным возможностям: файловая система, сокеты, HTTP, часы, энтропия, CLI. WASI 0.2 (Preview 2) стабилен с 2024 года, WASI 0.3 (Preview 3) вышел в июне 2026 с нативным async.

Стоит ли мигрировать микросервисы на Wasm?

Только stateless-часть на периметре. Stateful-сервисы (базы данных, брокеры сообщений) остаются в контейнерах. Wasm оптимален для edge-функций, плагинов и serverless с жёсткими требованиями к cold start.

Какие языки поддерживаются?

Rust (лидер), C/C++ (через Emscripten), Kotlin (WasmGC, Beta), Go (WASI), Python (Pyodide), JavaScript (через JCO). Список постоянно растёт.

Сколько это стоит?

Бесплатно и открыто. Все основные runtime (Wasmtime, Wasmer, WasmEdge) — open source. Edge-платформы (Cloudflare Workers, Fastly Compute, Akamai EdgeWorkers) тарифицируются за запросы, обычно дешевле Lambda за счёт более высокой плотности на узел.