[Перевод] WebAssembly — это возвращение апплетов Java и Flash?
В последней статье по WebAssembly я сделал следующее утверждение:
Некоторые сравнивают WebAssembly с Java-апплетами. В определённом смысле они правы, но с другой стороны сильно ошибаются. Как-нибудь я напишу статью о различиях, но пока поговорим о сходстве. В некотором смысле WebAssembly — иной способ выполнения того, для чего предназначалась JVM: это обычная виртуальная машина для кроссплатформенного ПО.
Многие люди выразили заинтересованность в этой теме, так что давайте рассмотрим её подробнее! В этой статье сравним WebAssembly с тремя технологиями: Flash, Java-апплеты и немножко с PNaCL. Кроме того, статья сосредоточиться на использовании в вебе, хотя раньше мы рассматривали варианты использования WebAssembly в офлайне. Но о таком сравнении поговорим позже. Наконец, эта статья похожа на поедание тапаса [испанская закуска из множества разных компонентов — прим. пер.], здесь куча маленьких разделов. Мне кажется, она слегка коротковата, но в то же время я пытаюсь вести блог, а если продолжать её расширять, то это займёт вечность, так что извините.
Думаю, сравнение с Flash и Java-апплетами вполне естественно, когда вы встречаете такое описание WebAssembly:
WebAssembly (сокращенно Wasm) — это формат двоичных инструкций для стековой виртуальной машины. Wasm разработан как переносимый вариант компиляции языков высокого уровня, таких как C, C++ и Rust, что позволяет развёртывать в интернете клиентские и серверные приложения.
Это немного похоже на прошлые технологии. Вполне логично сравнить, как они связаны, и предположить небольшие различия между ними. Но WebAssembly значительно отличается по нескольким причинам.
Wasm победил
Первая причина отличий WebAssembly в том, что ему в итоге удалось добиться успеха, а предыдущим технологиям нет. Я имею в виду победу в специфическом смысле. Если сравнить количество Flash-приложений и количество приложений WebAssembly, то Wasm наверняка проиграет. Адептам WebAssembly придётся ещё немало поработать, чтобы распространить эту платформу.
Когда я говорю о победе WebAssembly, то имею в виду, что он стал частью веб-платформы. Flash, Java-апплеты и PNaCL работали через плагины. В некотором смысле, они находились вне экосистемы веба. Их никогда не включили в стандарт, а это очень важно.
В некотором смысле, такого объяснения достаточно. Но просто указать на факт не значит объяснить его причины. В остальной части этой статьи попробуем разобраться, почему так произошло: почему WebAssembly удалось то, что не смогли сделать другие технологии. Здесь многие причины связаны друг с другом, но я пытаюсь разумно разделить их на отдельные пункты.
Другие технологии не вписались в платформу
Помните это?
Или это?
Как насчёт такого?
Апплет, созданный на этих технологиях, на самом деле не является веб-приложением. У вас веб-страница с вырезанным из неё куском, а ваш апплет работал в этом фрейме. Вы теряете все преимущества других веб-технологий: ни HTML, ни CSS, ни возможности интегрироваться в веб. Эти платформы не взаимодействовуют с остальной платформой в браузере. Ну технически они могут, но на практике эти технологии использовались иначе.
Как же веб поддержит экосистему, которая с ним не интегрируется? Этого никогда не случится. И пользователи в конечном итоге решительно отвергли её. Кроме игр, пользователи ненавидели Flash, а Java-апплеты были тяжёлыми и медленными. Эти технологии не закрепились в веб-платформе.
С другой стороны, WebAssembly гораздо ближе к JavaScript. По сути Wasm не отбирает у вас часть экрана. Он не создаёт свой собственный маленький закрытый мир. Сейчас с помощью JavaScript, а в будущем и самостоятельно, он способен взаимодействовать с окружением. Он просто… вписывается в него.
Другие технологии принадлежали компаниям
Java принадлежала Sun Microsystems, Flash принадлежал Adobe. Почему это важно?
Корпоративное влияние в интернете — сложная тема. В целом веб работает на псевдо-консенсусной модели. С другой стороны, Java и Flash контролировались соответствующими компаниями. У них есть сильная мотивация к получению прибыли, а не к улучшению интернета. И это частично привело к вышеупомянутой ситуации: данные компании не заботились о том, чтобы должным образом интегрироваться с остальной частью платформы. Зачем им это? Намного лучше для бизнеса заблокировать свою платформу и полностью отказаться от остальной части интернета. Мотивация совершенно перекошена.
WebAssembly — совместная инициатива Mozilla, Google, Apple, Microsoft и других. Она не продвигает чью-то конкретную платформу, а вместо этого представляет общие интересы широкого круга заинтересованных сторон, как корпоративных, так и индивидуальных.
WebAssembly следовал веб-процессу
Корпоративная принадлежность также означает, что эти технологии никогда не следовали процессу, который мы используем для стандартизации веба. Процесс принятия веб-стандартов хорошо отлажен, но эти технологии были слишком большими и работали немного иначе. В отличие от них, WebAssembly следовал стандартной процедуре, принятой для веб-технологий.
Сначала был создан asm.js как доказательство, что мы можем делать с вебом впечатляющие вещи. Его исполнение вышло достаточно качественным и продемонстрировало возможности технологии, хотя там ничего фантастического. Главный козырь asm.js был в том, что это просто код JavaScript: он полностью совместим с существующей экосистемой. «Не ломайте интернет» — очень, очень важное правило для разработчиков браузеров.
WebAssembly был улучшенной разновидностью asm.js. После нахождения определённого консенсуса вокруг asm.js все собрались вместе, чтобы воплотить в реальность WebAssembly. Поскольку это не просто JavaScript, ему следовало пройти весь процесс для реализации в браузерах, и он его прошёл. Теперь это спецификация W3C, которая соответствует веб-стандартам, а не противоречит им.
Следствие: другие технологии были слишком большими и нестабильными
Ещё одна причина, по которой Wasm преуспел: он крошечный. Wasm использует подход других веб-технологий: начните с малого и укрупняйтесь на этой основе. Сохраняйте обратную совместимость. Прошлые технологии также не следовали этой конкретной социальной конвенции. Для Flash и Java-апплетов загружалась конкретная среда выполнения, поэтому совместимость не требовалась. PNaCl построен поверх совершенно нестабильного кода LLVM IR. Его собирались сделать стабильным подмножеством, но при изменении LLVM произошло бы расхождение, что не очень хорошо.
Эти технологии также слишком громоздки, чтобы когда-то надеяться на стабилизацию. Вы можете представить, чтобы четыре производителя браузеров полностью определили спецификации JVM, а затем согласились с этой семантикой навсегда? Для всего ActionScript, который сам по себе похожий, но отличающийся вариант ECMAScript? Для всего LLVM-IR?
Крупные технологии вносят в ситуацию недопустимый риск. Это сделка «всё или ничего», а здесь безопасная ставка «ничего». С другой стороны, WebAssembly почти ничего не делает. Это в основном математика и вызов JavaScript. То есть тут гораздо проще договориться.
Следствие: другие технологии требует целой отдельной виртуальной машины
В этой статье я не упомянул Dart, но он тоже сюда вписывается. У предложения «Давайте просто поместим JVM в каждый браузер» главная проблема в том, что в браузере уже есть среда выполнения для JavaScript. Даже одну среду выполнения достаточно сложно поддерживать, не говоря уже о двух. И как вы их интегрируете?
C другой стороны, WebAssembly разработан как небольшое расширение существующих виртуальных машин JavaScript. Хотя вы можете реализовать свою собственную виртуальную машину WebAssembly — так часто делают при офлайновом использовании WebAssembly, но для браузеров затраты на обслуживание намного, намного ниже.
Другие технологии слишком специфичны
WebAssembly фундаментально независим от языка. Flash и Java-апплеты создавались в первую очередь для запуска ActionScript и Java. Они глубоко привязаны к своей относительной семантике. Даже PNaCl в какой-то степени страдает от этого: LLVM реально приспособлен для C-подобных языков, хотя и не совсем в той же мере.
Действительно ли мы хотим выбрать один язык для всего интернета? У нас уже есть JavaScript. Когда-нибудь представим третий язык? Четвёртый? Независимый подход значительно лучше в долгосрочной перспективе.
У Wasm строгий подход к безопасности
Java-апплеты и Flash были настоящим кошмаром для безопасности. Даже если и предпринимались попытки их обезопасить, в реальности постоянно возникали проблемы.
С другой стороны WebAssembly опять получал бонусы от JavaScript VM: все усилия по изоляции её песочницы относятся также к Wasm. Здесь отсутствуют некоторые функции обычного ассемблера, которые могут привести к уязвимостям, вроде разрушения стека. Wasm безопасно работает с памятью, что очень важно!
Кроме того, WebAssembly изначально разработан с мыслью о валидации: он полностью типизирован, а программы можно проверить без запуска кода. Спецификации включают инструкции, как проводить такую валидацию. Это весьма полезно!
Вывод
Хочу сказать об этой статье следующее: она написана с точки зрения разработчика. Но разработчики важны, ведь они контролируют веб. Технология должна соответствовать их целям — это так же важно, как как удобство для конечных пользователей. В будущей статье я попробую проанализировать проблемы с точки зрения пользователей. Писать придётся немало!
Подводя итоги:
- Другие технологии не были интегрированы в веб-платформу, и этому мешали коммерческие интересы.
- Другие технологии требовали слишком многого: многим приходилось жертвовать в реализации.
- У Wasm действительно хорошая изоляция в песочнице и валидация, чего у других просто не было.
