Хабрахабр

[Перевод] WebAssembly — это возвращение апплетов Java и Flash?

В последней статье по WebAssembly я сделал следующее утверждение:

В определённом смысле они правы, но с другой стороны сильно ошибаются. Некоторые сравнивают WebAssembly с Java-апплетами. В некотором смысле WebAssembly — иной способ выполнения того, для чего предназначалась JVM: это обычная виртуальная машина для кроссплатформенного ПО. Как-нибудь я напишу статью о различиях, но пока поговорим о сходстве.

Многие люди выразили заинтересованность в этой теме, так что давайте рассмотрим её подробнее! В этой статье сравним WebAssembly с тремя технологиями: Flash, Java-апплеты и немножко с PNaCL. Кроме того, статья сосредоточиться на использовании в вебе, хотя раньше мы рассматривали варианты использования WebAssembly в офлайне. Но о таком сравнении поговорим позже. Наконец, эта статья похожа на поедание тапаса [испанская закуска из множества разных компонентов — прим. пер.], здесь куча маленьких разделов. Мне кажется, она слегка коротковата, но в то же время я пытаюсь вести блог, а если продолжать её расширять, то это займёт вечность, так что извините.
Думаю, сравнение с Flash и Java-апплетами вполне естественно, когда вы встречаете такое описание WebAssembly:

Wasm разработан как переносимый вариант компиляции языков высокого уровня, таких как C, C++ и Rust, что позволяет развёртывать в интернете клиентские и серверные приложения. WebAssembly (сокращенно Wasm) — это формат двоичных инструкций для стековой виртуальной машины.

Это немного похоже на прошлые технологии. Вполне логично сравнить, как они связаны, и предположить небольшие различия между ними. Но WebAssembly значительно отличается по нескольким причинам.

Wasm победил

Первая причина отличий WebAssembly в том, что ему в итоге удалось добиться успеха, а предыдущим технологиям нет. Я имею в виду победу в специфическом смысле. Если сравнить количество Flash-приложений и количество приложений WebAssembly, то Wasm наверняка проиграет. Адептам WebAssembly придётся ещё немало поработать, чтобы распространить эту платформу.

Flash, Java-апплеты и PNaCL работали через плагины. Когда я говорю о победе WebAssembly, то имею в виду, что он стал частью веб-платформы. Их никогда не включили в стандарт, а это очень важно. В некотором смысле, они находились вне экосистемы веба.

Но просто указать на факт не значит объяснить его причины. В некотором смысле, такого объяснения достаточно. Здесь многие причины связаны друг с другом, но я пытаюсь разумно разделить их на отдельные пункты. В остальной части этой статьи попробуем разобраться, почему так произошло: почему WebAssembly удалось то, что не смогли сделать другие технологии.

Другие технологии не вписались в платформу

Помните это?

Или это?

Как насчёт такого?

У вас веб-страница с вырезанным из неё куском, а ваш апплет работал в этом фрейме. Апплет, созданный на этих технологиях, на самом деле не является веб-приложением. Эти платформы не взаимодействовуют с остальной платформой в браузере. Вы теряете все преимущества других веб-технологий: ни HTML, ни CSS, ни возможности интегрироваться в веб. Ну технически они могут, но на практике эти технологии использовались иначе.

Этого никогда не случится. Как же веб поддержит экосистему, которая с ним не интегрируется? Кроме игр, пользователи ненавидели Flash, а Java-апплеты были тяжёлыми и медленными. И пользователи в конечном итоге решительно отвергли её. Эти технологии не закрепились в веб-платформе.

По сути Wasm не отбирает у вас часть экрана. С другой стороны, WebAssembly гораздо ближе к JavaScript. Сейчас с помощью JavaScript, а в будущем и самостоятельно, он способен взаимодействовать с окружением. Он не создаёт свой собственный маленький закрытый мир. Он просто… вписывается в него.

Другие технологии принадлежали компаниям

Java принадлежала Sun Microsystems, Flash принадлежал Adobe. Почему это важно?

В целом веб работает на псевдо-консенсусной модели. Корпоративное влияние в интернете — сложная тема. У них есть сильная мотивация к получению прибыли, а не к улучшению интернета. С другой стороны, Java и Flash контролировались соответствующими компаниями. Зачем им это? И это частично привело к вышеупомянутой ситуации: данные компании не заботились о том, чтобы должным образом интегрироваться с остальной частью платформы. Мотивация совершенно перекошена. Намного лучше для бизнеса заблокировать свою платформу и полностью отказаться от остальной части интернета.

Она не продвигает чью-то конкретную платформу, а вместо этого представляет общие интересы широкого круга заинтересованных сторон, как корпоративных, так и индивидуальных. WebAssembly — совместная инициатива Mozilla, Google, Apple, Microsoft и других.

WebAssembly следовал веб-процессу

Корпоративная принадлежность также означает, что эти технологии никогда не следовали процессу, который мы используем для стандартизации веба. Процесс принятия веб-стандартов хорошо отлажен, но эти технологии были слишком большими и работали немного иначе. В отличие от них, WebAssembly следовал стандартной процедуре, принятой для веб-технологий.

Его исполнение вышло достаточно качественным и продемонстрировало возможности технологии, хотя там ничего фантастического. Сначала был создан asm.js как доказательство, что мы можем делать с вебом впечатляющие вещи. «Не ломайте интернет» — очень, очень важное правило для разработчиков браузеров. Главный козырь asm.js был в том, что это просто код JavaScript: он полностью совместим с существующей экосистемой.

После нахождения определённого консенсуса вокруг asm.js все собрались вместе, чтобы воплотить в реальность WebAssembly. WebAssembly был улучшенной разновидностью asm.js. Теперь это спецификация W3C, которая соответствует веб-стандартам, а не противоречит им. Поскольку это не просто JavaScript, ему следовало пройти весь процесс для реализации в браузерах, и он его прошёл.

Следствие: другие технологии были слишком большими и нестабильными

Ещё одна причина, по которой Wasm преуспел: он крошечный. Wasm использует подход других веб-технологий: начните с малого и укрупняйтесь на этой основе. Сохраняйте обратную совместимость. Прошлые технологии также не следовали этой конкретной социальной конвенции. Для Flash и Java-апплетов загружалась конкретная среда выполнения, поэтому совместимость не требовалась. PNaCl построен поверх совершенно нестабильного кода LLVM IR. Его собирались сделать стабильным подмножеством, но при изменении LLVM произошло бы расхождение, что не очень хорошо.

Вы можете представить, чтобы четыре производителя браузеров полностью определили спецификации JVM, а затем согласились с этой семантикой навсегда? Эти технологии также слишком громоздки, чтобы когда-то надеяться на стабилизацию. Для всего LLVM-IR? Для всего ActionScript, который сам по себе похожий, но отличающийся вариант ECMAScript?

Это сделка «всё или ничего», а здесь безопасная ставка «ничего». Крупные технологии вносят в ситуацию недопустимый риск. Это в основном математика и вызов JavaScript. С другой стороны, WebAssembly почти ничего не делает. То есть тут гораздо проще договориться.

Следствие: другие технологии требует целой отдельной виртуальной машины

В этой статье я не упомянул Dart, но он тоже сюда вписывается. У предложения «Давайте просто поместим JVM в каждый браузер» главная проблема в том, что в браузере уже есть среда выполнения для JavaScript. Даже одну среду выполнения достаточно сложно поддерживать, не говоря уже о двух. И как вы их интегрируете?

Хотя вы можете реализовать свою собственную виртуальную машину WebAssembly — так часто делают при офлайновом использовании WebAssembly, но для браузеров затраты на обслуживание намного, намного ниже. C другой стороны, WebAssembly разработан как небольшое расширение существующих виртуальных машин JavaScript.

Другие технологии слишком специфичны

WebAssembly фундаментально независим от языка. Flash и Java-апплеты создавались в первую очередь для запуска ActionScript и Java. Они глубоко привязаны к своей относительной семантике. Даже PNaCl в какой-то степени страдает от этого: LLVM реально приспособлен для C-подобных языков, хотя и не совсем в той же мере.

У нас уже есть JavaScript. Действительно ли мы хотим выбрать один язык для всего интернета? Четвёртый? Когда-нибудь представим третий язык? Независимый подход значительно лучше в долгосрочной перспективе.

У Wasm строгий подход к безопасности

Java-апплеты и Flash были настоящим кошмаром для безопасности. Даже если и предпринимались попытки их обезопасить, в реальности постоянно возникали проблемы.

Здесь отсутствуют некоторые функции обычного ассемблера, которые могут привести к уязвимостям, вроде разрушения стека. С другой стороны WebAssembly опять получал бонусы от JavaScript VM: все усилия по изоляции её песочницы относятся также к Wasm. Wasm безопасно работает с памятью, что очень важно!

Спецификации включают инструкции, как проводить такую валидацию. Кроме того, WebAssembly изначально разработан с мыслью о валидации: он полностью типизирован, а программы можно проверить без запуска кода. Это весьма полезно!

Вывод

Хочу сказать об этой статье следующее: она написана с точки зрения разработчика. Но разработчики важны, ведь они контролируют веб. Технология должна соответствовать их целям — это так же важно, как как удобство для конечных пользователей. В будущей статье я попробую проанализировать проблемы с точки зрения пользователей. Писать придётся немало!

Подводя итоги:

  • Другие технологии не были интегрированы в веб-платформу, и этому мешали коммерческие интересы.
  • Другие технологии требовали слишком многого: многим приходилось жертвовать в реализации.
  • У Wasm действительно хорошая изоляция в песочнице и валидация, чего у других просто не было.
Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»