Рабочая группа по стандартизации технологии WebAssembly, сформированная при организации W3C из представителей проектов Chrome, Edge, Firefox и WebKit, сделала заключение, что бинарный формат и начальный WebAssembly API достигли уровня MVP (минимально жизнеспособный продукт), что даёт разработчикам браузеров зелёный свет на включение WebAssembly по умолчанию. WebAssembly предоставляет не зависящий от браузера универсальный низкоуровневый промежуточный код для выполнения в браузере приложений, скомпилированных из различных языков программирования.

Участники рабочей группы согласились, что архитектура WebAssembly достигла уровня, при котором её дальнейшее развитие невозможно без реального внедрения и начала широкого использования в приложениях. С WebAssembly теперь снята метка "Browser Preview", а все дальнейшие изменения JavaScript API и бинарного формата будут производиться с учётом сохранения обратной совместимости. Следующим шагом станет разработка спецификаций, которые послужат основой для будущего утверждения WebAssembly в качестве web-стандарта. Mozilla планирует включить WebAssembly по умолчанию в выпуске Firefox 52, намеченном на 7 марта. В Chrome включение WebAssembly без привязки к флагу "chrome://flags#enable-webassembly" ожидается в выпуске 57.

Напомним, что по своим задачам WebAssembly во многом напоминает PNaCl (Portable Native Client) и Asm.js. Основное отличие от Asm.js состоит в том, что WebAssembly является бинарным форматом, не завязанным на JavaScript и позволяющим выполнять в браузере низкоуровневый промежуточный код. В отличие от PNaCl, промежуточный код WASM не является машинным кодом и не изолирован в отдельной виртуальной машине, а выполняется с похожим на JavaScript уровнем изоляции. Среди основных задач WebAssembly выделяется обеспечение переносимости между браузерами, предсказуемость поведения и идентичности выполнения кода на разных платформах. Использование WebAssembly также позволит существенно сократить размер приложений, благодаря компактному промежуточному коду, и увеличить скорость декодирования.

Из особенностей WebAssembly, позволяющих добиться более высокой производительности, по сравнению с JavaScript, выделяется:

  • Более компактное представление WebAssembly позволяет сократить время загрузки, по сравнению с загрузкой даже сжатого JavaScript;
  • Декодирование WebAssembly занимает значительно меньше времени по сравнению с парсингом исходных текстов JavaScript;
  • Компиляция и оптимизация выполняются быстрее, так как WebAssembly ближе к машинному коду и уже прошёл стадии оптимизации на этапе компиляции разработчиком;
  • Не требуется выполнение операции повторной оптимизации, учитывающей статистику о переменных, полученную при выполнении приложения, так как в WebAssembly изначально присутствует информация о типах, которую JavaScript вынужден вычислять на ходу в зависимости от контекста;
  • Выполнение WebAssembly занимает меньше времени так как можно обойтись без хитростей и приёмов, которые должен использовать разработчик для повышения производительности JavaScript. Кроме того бинарный формат WebAssembly значительно ближе к машинному коду;
  • В WebAssembly не требуется применение сборщика мусора, так как применяется явное управление памятью.

Для разработчиков подготовлен работающий инструментарий для компиляции модулей WebAssembly из кода на языках C/C++. Например, для компиляции С/C++/asm.js в WebAssembly можно использовать Emscripten или созданный на его основе специальный компилятор Binaryen. Для преобразования тестового формата в бинарный поставляется транслятор WABT. Для компиляции приложений в WebAssembly может быть использован инструментарий Emscripten.

Источник: http://www.opennet.ru/opennews/art.shtml?num=46117