Массовое внедрение WebAssembly пока не стало реальностью.
Настоящий переломный момент для WebAssembly — а именно его способность доставлять облегченный код на любое количество конечных точек с задержкой в миллисекунды — зависит от доработки модели компонентов.
«Настоящий переломный момент для WebAssembly — а именно его способность доставлять облегченный код на любое количество конечных точек с задержкой в миллисекунды — зависит от доработки модели компонентов».
Стандартизация модели компонентов позволит WebAssembly заменить контейнеры в тех областях, где они обычно сталкиваются с трудностями, независимо от того, используется ли Kubernetes. Wasm лучше подходит для периферийных устройств, бессерверных сред и событийно-ориентированных развертываний, которые требуют одновременной отправки обновлений на неограниченное количество конечных точек.
Действительно, WebAssembly вышел далеко за пределы браузера. Он демонстрирует свою зрелость благодаря надежному производственному использованию на серверах, в CDN и бэкэнд-сервисах, а также широкой применимости.
Хотя ядро WebAssembly намеренно является низкоуровневым и сложным для прямого использования, недавняя работа над спецификацией позволяет создавать абстракции более высокого уровня. Типы ссылок и типы интерфейсов позволяют компонентам предоставлять значимые API без необходимости для разработчиков понимать внутреннее устройство WASM, что делает технологию более доступной для инженеров.
Во время доклада «На пути к Component Model 1.0» на конференции Wasm I/O в Барселоне на прошлой неделе Люк Вагнер из Fastly рассказал о работе по упрощению внедрения так называемой Component Model, включая стимулирование реализации в нативных браузерах и устранение нескольких оставшихся пробелов в функциональности.
«Для обеспечения удобства разработчиков, когда все просто «работает», требуются основанные на стандартах решения скоординированных проблем… таких как то, как стандартная библиотека выполняет ввод-вывод или как несколько модулей объединяются и связываются во время выполнения».
Хотя технические усовершенствования, такие как отладка и многопоточность, важны, «ключевым фактором» для широкого внедрения Wasm является отсутствие поддержки на верхнем уровне в популярных языках и фреймворках, сказал Вагнер.
Для достижения «просто работающего» опыта разработчика требуются основанные на стандартах решения скоординированных проблем, таких как то, как стандартная библиотека выполняет ввод-вывод или как несколько модулей объединяются и связываются во время выполнения. Чтобы решить эту проблему, стратегия включает два уровня: компонентную модель, которая предоставляет базовые решения для вычислений и виртуализации, и WASI, которая определяет модульные стандартные API для различных типов ввода-вывода, сказал Вагнер.
«Я собираюсь заявить, возможно, вызывая споры, что отсутствие поддержки на верхнем уровне для всех популярных языков, инструментов, факторов и фреймворков, чтобы Wasm мог просто работать как внутри, так и вне браузера, сдерживает внедрение Wasm», — сказал Вагнер.
Вагнер отметил, что в WebAssembly Preview 2 был выделен уровень модели компонентов, а в готовящемся Preview 3 он будет расширен для обработки параллелизма с помощью асинхронных функций, строк и фьючерсов. Эта функция параллелизма станет важной вехой на пути к завершению модели компонентов.
Также планируется переход от «активного» выделения памяти к «ленивому» API для уменьшения фрагментации кучи и повышения производительности за счет инверсии потока управления. Среди других запланированных улучшений для версии 1.0 — поддержка возврата нескольких значений, добавление значений контекста ошибок и введение опции GC API для языков, использующих память с сборщиком мусора, сказал Вагнер.
«В Preview 3 мы расширяем модуль Wasm, чтобы дать ответы на многие вопросы о параллелизме. И в рамках этого рассматриваем асинхронные функции, строки и фьючерсы как концепции первого класса», — сказал Вагнер. «Таким образом, этот ленивый API дает много преимуществ. Но как изменить API, сохранив ту важнейшую стабильность, о которой я только что упомянул?»
Между тем, компонентная модель предоставляет основанные на стандартах ответы на открытые вопросы, обеспечивая «поддержку на всех уровнях, так что хост может просто работать», — сказал Вагнер. «У нас есть предварительная версия, которая выйдет очень скоро, за которой последуют кооперативные потоки и минорный релиз, дающий нам ответы на ряд сложных вопросов о параллелизме», — сказал Вагнер.
Чтобы стимулировать нативную поддержку браузеров, Вагнер выделил JCO — инструмент, который транслирует компоненты в JavaScript и базовый WebAssembly, который работает в современных браузерах. Нативная поддержка обеспечит повышение производительности за счет отказа от связующего кода JS и возможности прямых вызовов из Wasm в код браузера.
Вагнер завершил свое выступление призывом к сообществу создавать пулл-реквесты, которые помогут упростить модель компонентов путем создания общих инструментов вокруг гостевых и хост-API. Проекту также нужны вклады в виде дополнительной документации, чтобы идти в ногу с коммитами.
Также необходимы вклады в разработку инструментов для интеграции в основной проект и межъязыковых инструментов, а также устранение ключевых пробелов в выразительности с помощью таких функций, как опциональные импорты, обратные вызовы, подтипы и многое другое, сказал Вагнер.
«Итак, я прошу всех здесь присутствующих использовать Preview 3 после его выпуска, использовать JCO для упрощения работы веб-разработчиков с Wasm», — сказал Вагнер. «И если какой-либо из упомянутых мной многочисленных проектов Bytecode Alliance вам показался интересным, пожалуйста, присоединяйтесь к нам и поздоровайтесь с нами в Bytecode Alliance на Zulip, а также можете прочитать и обсудить спецификацию модели компонентов в репозитории GitHub».
Подписывайтесь на наш канал в Телеграм
⚡ Подписаться