WASI P3 почти вышел — он добавит нативную асинхронность в WebAssembly System Interface (WASI) и Component Model. Но Bytecode Alliance уже смотрит дальше: цель — стабильный, формально специфицированный Component Model 1.0. На февральском Bytecode Alliance Plumbers Summit Люк Вагнер и Алекс Кричтон набросали дорожную карту, а в марте на Wasm I/O 2026 в Барселоне Вагнер расширил видение.
Напомним разницу. Component Model — это слой поверх WebAssembly, который описывает, как бинарники упаковываются, линкуются и обмениваются данными: типы, формат, IDL, соглашения о вызовах. WASI — это стандартные API для доступа к файлам, сокетам, часам, рандому. Они работают в связке. Вагнер сравнил это с микроядром: Component Model — вездесущее микроядро, WASI — сервисы ОС поверх него. Уже сейчас и WASI, и Component Model вовсю используются в продакшене, и обратная совместимость поддерживается: P1 и P2 работают.
Чтобы дойти до 1.0, нужно сделать работу в пяти областях.
Первое — ABI. Сейчас все компоненты обязаны экспортировать функцию cabi_realloc, что ведёт к фрагментации кучи и проблемам с аллокаторами. Планируется ленивый ABI: кали возвращает непрозрачные индексы (i32), а когда вызывающий готов разместить значение в памяти, он дёргает статическую встроенную функцию. Это позволяет zero-copy форвардить данные, отбрасывать неиспользуемое и чистит логику транскодинга строк. Переход будет опциональным и неломающим: в релизе 0.3.x появится флаг, а в 1.0 станет умолчанием. Адаптер сконвертирует старые компоненты. Туда же зашивают multivalue returns и контекст ошибки в каждом результате. Загвоздка: LLVM пока не поддерживает multivalue на уровне C ABI.
Вторая область — браузеры. Без нативной поддержки как минимум в двух движках 1.0 не случится. Пока jco транслирует компоненты в обычный Wasm и JavaScript клей — это работает, но нативно будет быстрее. Эксперименты Райана Ханта из Mozilla показали до 2x ускорения на DOM-операциях. Для сбора данных jco теперь эмитит строку "use components" в сгенерированном клее. Mozilla и Chrome следят: команда Mozilla показывала результаты, Chrome V8 завёл issue на оценку реализации.
Третье — упрощение реализации. Спецификацию для 1.0 урежут до «лучших частей»: не нужно будет тащить всё из P3. Помогут два C ABI, выраженные в заголовочных файлах wit-bindgen: гостевой (для тулчейнов через wasm-component-ld) и хостовый (для рантаймов через утилиту lower-components, которая «схлопывает» составной компонент в один модуль с multi-memory).
Четвёртое — экосистема. Нужна документация, стабильная поддержка P3 в Rust, LLVM, CPython (отслеживается в awesome-wasm-components), больше тулов вроде jco, wac, wkg. Отдельно — record/replay отладка: инструментационные компоненты записывают WIT-вызовы в формате WAVE и позволяют воспроизводить их без оригинального хоста.
Пятое — закрытие пробелов в WIT. Нужны опциональные импорты, колбэки (для addEventListener), субтайпинг ресурсов и функций, улучшенные имена импортов, геттеры/сеттеры, map-тип (над ним уже работает Yordis Prieto), и runtime-инстанциация. Не всё попадает в 1.0, часть уйдёт в 1.x.
Параллельно Сай Брэнд на Summit рассказал о cooperative threads и stream splicing. Первые реализованы на уровне Component Model, под WASI — Rust-компонент с std::thread::spawn получит их автоматически. LLVM-патчи уже легли, wisi-libc почти готов, Wasmtime работает под флагом. Stream splicing — возможность врезать один стрим в другой без копирования — тоже выйдет в раннем P3-релизе.
Алекс Кричтон описал пайплайн: каждая стадия даёт фидбек для предыдущей. Bytecode Alliance контролирует не всё — LLVM, Rust, CPython имеют свои циклы. LLVM выходит раз в полгода, Rust стабилизирует изменения за девять недель.
Хотите помочь? WASI P3 почти здесь. Работа над Component Model 1.0 продолжается.