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

Original author: Steve Klabnik
  • Translation
В последней статье по 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 действительно хорошая изоляция в песочнице и валидация, чего у других просто не было.
Support the author
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 45

    +4

    Насколько код скомпилированный и запущенный в wasm быстрее кода на JavaScript? Есть ли смысл писать вебигру под wasm?

      0
      Вот это правильный вопрос. Я всегда начинаю с примеров. Просто смотрите примеры и делайте выводы. Вот «Hello, World!» на WebAssembly: example.qt.io/qt-webassembly/opengl/hellowindow/hellowindow.html

      Пока в Chrome приходится ждать, пока оно стартанет. Может пример кривой и где-то есть лучше?
        +4
        Дело не в том, что пример кривой, дело в том, что Qt это тяжеленный монстр. И кто то придумал, что WebAssembly существует для компиляции всего кода перед запуском модуля. Отсюда же нулевая оптимизация интеграции с JS. И всё ради того, чтобы JIT не лагал во время игры. Firefox быстро пошёл на уступки компилируя в первый раз без оптимизаций, но в тоже время отбросил основную идею. А Google забил и к тому же вырубил кеш компиляции. Вот не сильно тормозной пример github.com/timhutton/opengl-canvas-wasm
        +1
        Нет пока смысла, так как wasm не имеет доступа к DOM напрямую, только через JS. Т.е. wasm годится для узкого круга задач — напр. майнить биткоины в браузере через js и wasm (шютка).

        Прямое общение с DOM предполагается лишь в будущем, вот тикет, который блокирует это: github.com/WebAssembly/design/issues/1079. Кроме панипуляций DOM напрямую для полноценного приложения не хватает встраивания и модульности с прозрачной интеграцией с существующими es6 модулями.
          +1
          Ну вот неплохая серия статей (статья, ответ (перевод на хабре), ответ на ответ), отсюда можно сделать вывод, что по крайней мере в конкретном примере идиоматичный код скомпилированный в WASM в 7 раз быстрее, чем неидиоматичный оптимизированный JS.
          0
          Кроме игр, пользователи ненавидели Flash
          youtube тоже ненавидели? Или там swfupload? Пользователи зачастую просто не знали, что оно flash.

          Эти платформы не взаимодействовуют с остальной платформой в браузере
          ExternalInterface, не?
            –5
            Мне вот кажется, что пока нормально не будет поддерживать Java/C#, то особой популярности он не найдёт. Я не против установить виртуальную машину один раз и пользоваться на всю катушку, но вот в плане основной платформы для разработки увы Wasm в нынешнем виде не подходит. В итоге 99% энтерпрайза просто проходит мимо.

            Клепать игры? Браузерные? Ну да, можно, но большого смысла нет, высокий порог вхождения (нынешних JS программеров переучивать?), сложность разработки и отладки может привести к нерентабельности.

            Пока вижу из реальных вариантов использования: Видео- и аудио-связь, удалённое управление. Ну и та ниша, для чего использовались Java-апплеты.

            Даже если добавят возможность манипуляции DOM, то ничего не это не даст. Пользовательский код манипуляции DOM никогда не был узким местом, использовать Wasm для оптимизации смысла нет вообще. Единственный вариант — компиляция JS в Wasm, ради экономии трафика (спорно) и некоторой защиты от дурака.
              +1
              Про PHP забыли :) С поддержкой PHP для клиентского кода может взлететь и без Java/C#.
                +3
                  0
                  Пользовательский код манипуляции DOM никогда не был узким местом

                  Берём любой редактор текста на реакте, загружаем в него документ на сотню килобайт и любуемся на тормоза при вводе каждой буквы. Чтобы изменить один небольшой текстовый узел идёт пара секунд вычислений. Современный JS — очень даже узкое место.

                    0
                    Как бы ошибка архитектуры не говорит о тяжести пользовательского кода при манипуляциях с DOM. Если уж React реально коряв при работе формами, то это не говорит, что весь JS такой.
                      0
                      99% софта на JS именно такой.
                  –1

                  Минимально разумный пользователь не станет разрешать дырявоиу браузеру запускать на своей машине неизвестные блобы из Интернета.
                  Принципиальная читаемость JS кода — его важный плюс против джавы, флэша и прочего трэша.
                  Имхо, вместо использования браузера в качестве контейнера следует двигаться к контейниризации самого браузера.

                    +6
                    Принципиальная читаемость JS кода — его важный плюс против джавы, флэша и прочего трэша.

                    Читаемость JS, пропущенного через какой-нибудь минификатор, будет вот разве что «принципиальной». А блобы WA, полагаю, принципиально должно быть возможно декомпилировать и почитать.
                      0

                      Даже декомпилировать не надо. Браузеры отображают его в текстовом формате.

                        0
                        Линеаризованный дизасм читать — удовольствия мало.
                          0
                          Можно попробовать использовать официальную утилиту [wasm2c](https://github.com/WebAssembly/wabt), которая на нашем 20Mb wasm файле дает 170Mb кода на Си.
                            0
                            170Mb кода на Си даже без примера звучит отнюдь не заманчиво
                              0
                              32Mb asm.js кода то же не радость.
                      +2
                      Текстовая природа JS позволяет существовать и такому понятию, как XSS.
                      Обоюдоострый стул.
                      +2
                      Минимально разумный пользователь не станет разрешать дырявоиу браузеру запускать на своей машине неизвестные блобы из Интернета.

                      Типа вы весь js на каждой странице читаете перед запуском?
                        –2
                        Нет, конечно, только при необходимости.
                        0
                        А вот нафига, в самом деле, какому-либо приложению на веб-странице доступ к остальному DOM? Даже на чтение. Поэтому лично я люблю флэш — без спроса наружу не лезет, а для того, чтобы вылезать наружу, спрашивает ExternalInterface, а можно мне вон туда или нет (дыры в Flash — отдельная тема). С джавой, кстати, ещё веселее в этом плане, но она очень тяжелая в плане ВМ, она вообще вне браузера (что, впрочем, логичнее с точки зрения безопасности). А wasm выглядит так, что на нем будут эксплуатировать XSS, воровать сохраненные пароли или куки и потом деньги, причем быстрее, чем вы сможете сказать «Microsoft Firewall» :D
                          0
                          В теории не получится с помощью wasm своровать больше чем с помощью js. Сейчас песочница у wasm — подмножество песочницы js, планируется лишь расширить её до границ js.
                            +1
                            А вот нафига, в самом деле, какому-либо приложению на веб-странице доступ к остальному DOM?

                            Для единообразия. Если я пишу ПО на языке X#, чтобы оно работало в браузере, то мне намного удобнее всё делать на X#, не перемешивая его с JavaScript.

                            0
                            > Кроме игр, пользователи ненавидели Flash, а Java-апплеты были тяжёлыми и медленными.

                            Флэш ненавидили сеошники, а не простые пользователи. Java-апплеты были тяжёлыми и медленными когда компьютеры были медленными, а в интернет выходили по диалапу. Сейчас это не так.
                            • UFO just landed and posted this here
                                0

                                юзеры тоже, тк на мобилах и смартфонах он так никогда нормально и не работал, на ноутбуках жрал батарею нещадно, на нетбуках тормозил.

                                  0
                                  На линуксах тоже проблемы с ним были. Более-менее решились как раз к тому времени, когда он начал сдавать позиции.
                                +1

                                Пока в wasm есть один главный момент: он почти никак не подходит для запуска языков с GC, в результате по факту только на C++ да Rust под него сейчас и возможно писать.

                                  0
                                  Если не подходит, то как игры на Unity работают?
                                    0
                                    Они тащат свой GC. Т.е. они тащат свесь свой шарповый рантайм туда и гоняют там свой GC.
                                      0
                                      Знаю. Мы тащим C++ и Lua рантайм и не испытываем проблем. Тема почему это не подходит, так и не раскрыта.
                                    +2
                                    Не вижу в этом особых проблем. Мое персональное имхо, что за языками с автоматическим управлением памятью без GC — будущее. Рантайм при большом желании можно с собой затащить, делать GC на уровне wasm мне кажется было бы ошибкой.
                                    0
                                    Вот интересно стало, а какие ниши может занять wasm? Flash в свое время дал возможности, которые нельзя было реализовать без него и которые при этом были широко востребованы, потому так сильно распространился. Затем по мере расширения возможностей «нативных» средств, флеш начал терять ниши. Что может дать wasm, невозможного без него и при этом широко востребованного, чтобы закрепиться в индустрии?
                                    На ум приходит какой-нить суровый софт под Chrome OS, но это не похоже на большую нишу.
                                      0
                                      Web( и JS ) как таковой, уже достиг пределов своего развития( в плане количества задействованных разработчиков. Число, конечно, будет постепенно расти, но не так быстро, как некоторым хотелось бы ).

                                      Чтобы активно развиваться дальше, нужно поглощать других: как разрабов с других языков, так и наработанные за многие годы кодовые базы.
                                      Вот, посредством WebAssembly, это и реализуется: web в общем и js в частности, постепенно начинают «поглощать» остальных, делая js и его подобие, по сути, универсальным языком.

                                      Почему именно WebAssembly, а не просто преобразование в обычный js?
                                      Потому, что, если в языках используется-таки статическая типизация, грех не получить с этого профит.
                                        0
                                        node.js-у наносят ответный удар? :)
                                        0
                                        Вот интересно стало, а какие ниши может занять wasm?

                                        Ну представь себе облачный кроссплатформенный фотошоп.
                                          0
                                          Это да, но есть ли широкий спрос на такие продукты? Особенно при условии, что частично это можно сделать и без webasm, закрыв любительскую аудиторию. Тот же pixlr — отличный фотошоп для любителей, соотв переходить на полноценный аналог на webasm-е им будет незачем.
                                            +1

                                            Спрос есть. Иначе бы не было Asm.js, а Google бы не делала NaCL.

                                              0
                                              Только вот wasm ужасающе убог в сравнении ними обоими. Нет исключений, динамической линковки, кодогенерации; NaCL ещё и имеет бинарный API и не имеет необходимости в компиляции в браузере. Что есть в wasm? Есть только обещание, что всё это будет исправлено в будущем. Но судя по тому, как быстро принимаются спецификации HTML и JS и как медленно wasm, последний вероятно будет так же распространён как язык D.
                                                0

                                                Какой кодогенерации не хватает? Динамическая линковка, а она есть при компиляции C/C++ в asm.js?


                                                последний вероятно будет так же распространён как язык D.

                                                Компиляция C/C++ в Asm.js получила распространненость, почему wasm не должен?

                                                  0
                                                  Какой кодогенерации не хватает?
                                                  Невозможно в процессе работы создать новый wasm-код и тут же его использовать.
                                                  Динамическая линковка, а она есть при компиляции C/C++ в asm.js?
                                                  Технически это возможно и в emscripten уже есть экспериментальная поддержка. Но они почему то считают, что если слить всё в один гигантский файл, то производительность будет лучше.
                                                  Компиляция C/C++ в Asm.js получила распространненость, почему wasm не должен?
                                                  Потому, что медленнее вызывает импортируемые функции чем Asm.js. Или потому, что обратную совместимость с Asm.js всё равно придётся делать. Или потому, что вынужден таскать дополнительный JS-файл с бесчисленными обертками. Или потому, что простейшее Qt-OpenGL приложение в Chrome компилируется секунд 30, при каждом запуске…
                                                    0
                                                    Невозможно в процессе работы создать новый wasm-код и тут же его использовать.

                                                    А на C/C++ что-нибудь такое можно? А в чем достоинства динамической линковки? Для работы все равно нужно это загрузить и скомпилировать.


                                                    Потому, что медленнее вызывает импортируемые функции чем Asm.js.

                                                    Где бенчмарки на реальных проектах?


                                                    Или потому, что обратную совместимость с Asm.js всё равно придётся делать.

                                                    Её так и так нужно делать, т.к. не все пользователи обновили свои браузеры. Для emscripten это всего один флаг линковки.


                                                    Или потому, что простейшее Qt-OpenGL приложение в Chrome компилируется секунд 30, при каждом запуске…

                                                    Не используйте Qt, мы не использует Qt и 20Mb wasm кода компилируется на десткопах незаметно. В случае asm.js вы будете так же тратить время на компиляцию, но уже на JIT компиляцию. Это приводит к тому, что на iOS приложение может длительно тормозить, пока JIT все не откомпилирует.

                                          0
                                          1) ресурсоемкие, правда тут ему на пяты наступает JIT в JS.
                                          2) перенос части кодовой базы с сервера на клиент

                                        Only users with full accounts can post comments. Log in, please.