Для того, чтобы WebAssembly заработал, нам нужны две основных компоненты: инструменты для сборки кода в бинарник формата WebAssembly и браузеры, способные этот бинарник загрузить и выполнить. И то, и другое ещё не полностью создано и очень сильно зависит от завершения работы на спецификацией WebAssembly, но в общем-то это отдельные компоненты и их развитие идёт параллельно. Это разделение — хорошая вещь, оно позволит компиляторам создавать WebAssembly-приложения, способные работать в любом браузере, а браузерам — запускать WebAssembly-программы не зависимо от того, каким компилятором они были созданы. Другими словами — мы получаем открытую конкуренцию инструментов разработки и браузеров, что непрерывно будет двигать всё это вперёд, принося конечному пользователю отличный выбор. Кроме того, такое разделение позволяет командам разработчиков инструментария и браузеров работать параллельно и независимо.
Новый проект на стороне инструментарий WebAssembly, о котором я хочу сегодня рассказать, называется Binaryen. Binaryen это библиотека для поддержки WebAssembly в компиляторах, написанная на С++. Если вы лично не работаете над компилятором WebAssembly, то вам, вероятно, не нужно напрямую знать что-либо о Binaryen. Если вы используете какой-нибудь компилятор WebAssembly, то он, возможно, под капотом использует Binaryen — мы рассмотрим примеры ниже.
Ядро библиотеки Binaryen предназначено для парсинга и генерации WebAssembly, а также представлении его кода в виде абстрактного синтаксического дерева (AST). На основе этих возможностей созданы следующие полезные утилиты:
- утилита для командной строки, способная загрузить WebAssembly-модуль, распарсить его и выполнить его код как интерпретатор (произвести действия, вывести результат в консоль). Для загрузки модуля и вывода результата используется временная нотация s-выражений, имеющая суффикс .wast (я напомню, что окончательный формат представления бинарных модулей WebAssembly всё ещё в процессе разработки).
- asm2wasm — утилита для компиляции asm.js в WebAssembly.
- wasm2asm — утилита для компиляции WebAssembly в asm.js (ещё разрабатывается)
- s2wasm, которая компилирует .s-файлы (формат, создаваемый новым бекендом для WebAssembly в LLVM) в WebAssembly.
- wasm.js — порт Binaryen на JavaScript. Это позволит запускать все вышеуказанные инструменты прямо в браузере.
О Binaryen можно посмотреть вот эти слайды.
Ещё раз напомню, что WebAssembly находится в стадии активного проектирования, а значит входные и выходные форматы Binaryen (.wast, .s) не окончательны. Binaryen постоянно обновляется с обновлением спецификации WebAssembly. Степень кардинальности изменений со временем снижается, но гарантировать какой-либо совместимости никто, конечно, пока не может.
Давайте рассмотрим несколько областей, где Binaryen может быть полезен.
Компиляция в WebAssembly с использованием Emscripten
Emscripten может компилировать код на С в asm.js, а Binaryen (с помощью утилиты asm2wasm) может компилировать asm.js в WebAssembly, таким образом связка Emscripten + Binaryen даёт нам полный набор инструментов для компиляции кода на С и С++ в WebAssembly. Вы можете запустить asm2wasm на asm.js коде, но проще позволить Emscripten сделать это за вас, как-то так:
emcc file.cpp -o file.js -s ‘BINARYEN=”path-to-binaryen”’
Emscripten скомпилирует файл file.cpp и на выходе даст вам JavaScript-файл, плюс отдельный файл в формате .wast с WebAssembly. Под капотом Emscripten скомпилирует код в asm.js, сам запустит для него asm2wasm и сохранит результат. Более детально это описано на Вики проекта Emscripten.
Но подождите, какой смысл компилировать что-то в WebAssembly, если браузеры его пока не поддерживают? Отличный вопрос! :) Да, мы пока что не сможем запустить этот код ни в одном браузере. Но мы уже можем кое-что потестировать с его помощью. Итак, мы хотим проверить, верный ли бинарник создала связка Emscripten + Binaryen. Как же это сделать? Для этого мы можем использовать wasm.js, который Emscripten интегрировал в выходной .js-файл, полученный командой вызова emcc (см. выше). wasm.js содержить в себе порт Binaryen на Javascript, включая интерпретатор. Если вы запустите file.js (в node.js или в браузере), то вы получите результат выполнение WebAssembly. Это позволяет нам фактически подтвердить, что скомпилированный бинарник WebAssembly работает верно. Вы можете посмотреть на пример такой программы, плюс ещё пару примеров есть в репозитории для тестовых целей.
Конечно же, мы пока ещё не стоим на твёрдой земле со всеми этими инструментами. Тестовое окружение получается странноватое. С++ код компилируется в WebAssembly и затем выполняется в WebAssembly-интерпретаторе, который сам по себе написан на С++, но портирован на JavaScript. И нет пока никаких других способов запустить всё это. Но у нас есть несколько причин верить полученным результатам:
- Выходной код проходит все тесты Emscripten. Они включают обработку множества реальных кодовых баз (Python, zlib, SQLite) плюс множество «подозрительных» ситуаций в С и С++. По опыту можно сказать, что если тесты Emscripten проходят для всех этих случаев, то и другой код, обработанный Emscripten будет вести себя нормально
- Интерпретатор Binaryen проходит все внутренние тесты WebAssembly, определяющие правильность выполнения WebAssembly. Другими словами, когда мы получим поддержку WebAssembly в браузерах, они должны будут вести себя тем же образом (ну разве что работать быстрее).
- Большую часть работы делает Emscripten, который является стабильным компилятором, давно используемым в продакшене и лишь относительно малая часть поверх него делается с помощью Binaryen (его код составляет всего пару тысяч строк). Меньше кода — меньше багов.
Всё это показывает, что мы уже имеем некоторый результат, можем скомпилировать код на С и С++ в WebAssembly и даже как-то его запустить.
Заметьте, что WebAssembly — всего лишь ещё одна новая фича, и, отвлёкшись от неё, всё остальное в Emscripten работает по-прежнему: Emscripten позволяет использовать libc и syscalls, OpenGL/WebGL код, интеграцию с браузерами, интеграцию с node.js и т.д. В результате проекты, которые уже используют Emscripten, смогут переключиться на WebAssembly просто добавлением нового параметра командной строки. И это позволит С++ проектам быть скомпилированным в WebAssembly и работать в браузерах без всяких усилий.
Использование нового экспериментального бекенда к LLVM для WebAssembly с Emscripten
Мы только что увидели новый важный этап в развитии Emscripten, который дал ему возможность создавать WebAssembly-модули и даже тестировать их работу. Но на этом работа не останавливается: это было всего-лишь использование текущего компилятора asm.js, вместе с утилитой asm2wasm. Есть новый бекенд к LLVM для WebAssembly (вернее пока ещё нет, но активно пишется) — прямо в основной ветке разработки LLVM. И, хотя он ещё и не готов для реального применения, со временем он станет очень важным инструментом. Binaryen поддерживает формат его выходных данных.
LLVM-бекенд для WebAssembly, как и большинство LLVM-бекендов, создаёт ассемблерный код, в данном случае в специальном .s-формате. Этот формат близок к WebAssembly, но не прямо идентичен ему — он скорее похож на вывод компилятора С (линейный список инструкций, одна инструкция на строку), чем на абстрактное синтаксическое дерево WebAssembly. Данный .s-файл может быть преобразован в WebAssembly достаточно тривиальным способом (в общем-то, Binaryen включает утилиту s2wasm, которая именно это и делает — посмотрите насколько она проста). Вы можете запустить её саму по себе, или использовать для этого Emscripten, который теперь поддерживает новую опцию WASM_BACKEND, которую вы можете использовать вот так:
emcc file.cpp -o file.js -s ‘BINARYEN=”path-to-binaryen”’ -s WASM_BACKEND=1
Обратите внимание, что вам также нужно использовать опцию BINARYEN, поскольку s2wasm это часть Binaryen. Когда все эти опции указаны, Emscripten использует новый бекенд для WebAssembly вместо использования компилятора asm.js. После вызова бекенда и получения от него файла в .s-формате Emscripten вызовет s2wasm для конвертации в WebAssembly. Несколько примеров программ, которые вы уже можете собрать подобным способом, вы можете найти на Вики проекта Emscripten.
Таким образом, у нас есть два способа собрать WebAssembly-модуль с использованием Binaryen:
- Emscripten + asm.js backend + asm2wasm, что работает уже прямо сейчас и должно быть относительно простым и приемлимым вариантом
- Emscripten + новый бекенд для WebAssembly + s2wasm, который пока не полностью рабочий вариант, но с развитием бекенда для WebAssembly будет выходить на первый план.
Цель на данный момент — сделать переход от первого способа ко второму как можно менее сложной. В идеале всё должно свестить к замене одного аргумента в командной строке.
Таким образом у нас формируется чёткий план:
- Используем Emscripten для генерации asm.js кода (уже сегодня)
- Переходим на генерацию WebAssembly через asm2wasm (уже можно, но ещё не готовы браузеры)
- Переходим на генерацию WebAssembly через новый LLVM бекенд (как только он будет готов)
Каждый шаг даёт новые преимущества пользователям (скорость!) и практически не вызывает сложностей у разработчиков.
В заключение хочу сказать, что хотя данная статья и написана о Binaryen в контексте его применения с Emscripten, это всё-ещё отдельная библиотека для WebAssembly общего применения. Если у вас есть идеи создания некоторых инструментов для работы с WebAssembly — вы можете взять библиотеку Binaryen и работать с ней, не оглядываясь на Emscripten, LLVM или что-то ещё.
Комментарии (58)
Antelle
24.12.2015 23:24Из новостей про реализацию в движках: неделю назад поддержка wasm была включена в v8 без флага компилятора, с рантайм-флагом --enable-wasm, но коммит оказался плохим, и на следующий день его откатили, поэтому пока v8 надо собирать самому. Чуть раньше какая-то поддержка прототипа появилась в jsc. Подозреваю, что скоро уже можно будет попробовать первую реализацию.
beduin01
24.12.2015 23:43+2Пожалуйста покажите исходный код Hello World которое можно было-бы запустить в браузере.Так же смогу ли я из С++ приложения манипулировать DOM — т.е. не значит ли это что скоро всякие Ангулары и JQuery уйдут прошлое и появится новое поколение более простых и удобных фреймворков.
Плюс такой вопрос — есть ли шансы, что скоро вместо HTML можно будет QML использовать?
VlK
24.12.2015 23:53+21. Это переводная статья, и переводчики никому ничего не должны показывать :-)
2. Да, сможете делать в том числе и это, при должной поддержке разработчиками компиляторов. WebAssembly разрабатывается именно как целевая платформа для компиляции, т.е. разработчики LLVM или backend GCC должны будут поддерживать WebAssembly как еще одну платформу.
3. Вы какой именно QML имели в виду..?
1vanK
24.12.2015 23:57urho3d.github.io/HTML5-samples.html (чтобы мышь захватывалась примеры нужно развернуть на весь экран)
Исходный код: github.com/urho3d/Urho3D
tangro
25.12.2015 00:42Пожалуйста покажите исходный код Hello World
Самый обычный Hello World, ничего лишнего. Только браузера подходящего пока нет :)
dmitrmax
25.12.2015 01:42-7Flash умер, да здравствует
кусок бинарного говнаFlash!
И до вэба проклятые ироды добрались.tangro
25.12.2015 01:51+5Не-не, флеш был закрытый, внешний по отношению к браузеру и неконтролируемый. А WebAssembly — бегает внутри браузера (быстро), безопасный, работает с тем же HTML5, а не строит свои велосипеды.
dmitrmax
25.12.2015 01:53-5Дело совершенно не в том, закрытый или открытый по отношению к браузеру. А в том, что эта хрень будет закрыта по отношению к пользователю.
Попробуйте-ка из бинаря рекламу вырезать, например.tangro
25.12.2015 01:56С чего бы это? Она будет строить DOM-дерево, которое можно проинспектировать или изменить инструментами разработчика в браузере. Более того, разработчики браузеров вполне могут дать и возможность отладки WebAssembly (точки останова, трейсы, пошаговое выполнение). Что им мешает? Формат же полностью открыт и именно браузер его выполняет.
dmitrmax
25.12.2015 02:06-1Ассемблер и бинарный формат инструкций процессора тоже ни для кого не секрет. Однако попробуйте пореверсить какой-нибудь более менее большой проект.
Всё делается ради того, чтобы закрыть свой код от посторонних глаз. А аргументы могут быть самые разные: скорость, безопасность и так далее.tangro
25.12.2015 02:23+1Ну мне кажется популярные вещи (типа jQuery и Angular) сразу выпустят бинарники своих либ с исходниками и файлами символов, что сделает отладку тривиальной. Что касается остальных — хм… я даже не знаю, а какой-такой хитрый закрытый код может бежать в браузере, учитывая что всё, что он может — менять UI на страничке правками DOM-дерева?
dmitrmax
25.12.2015 10:49А вам лично чем это поможет, что вы так за эту технологию обрадовались? Скорость, как правильно пишут ниже, не особо изменится. Затык в другом месте. Отладка пусть чуть-чуть, но станет геморнее (надо добывать дебаг символы теперь). Где профит-то?
TeiSinTai
25.12.2015 11:59+3Серьёзно? А скажите мне, как соотносится с DOM набор пикселей внутри canvas? Или видео/звук из media?
И это всё не упоминая о привычке разработчиков считать своё приложение уникальным и единственным, и претендовать на 100% ресурсов пользователя. После чего рушить браузер при 50 открытых вкладках.
neolink
25.12.2015 13:52ничего не мешает повесить браузер/вкладку из javascript while (true) {} и вперед, в чем проблема?
для webAssebly сразу делаю восстанавливалку кода из бинарного формата
tangro
25.12.2015 14:12+1Как я и говорил — у WebAssembley будут те же права и возможности, что и у javaScript, просто работать он будет быстрее. Как в JS вы можете работать с DOM или рисовать по canvas — так и там сможете, просто отрисовка какой-нибудь HD-сцены из пары текстур уже сможет работать на 50 fps, а не на 10 fps.
ZyXI
25.12.2015 02:05+2Я не вижу принципиальной разницы между WebAssembly и минифицированным JS. Оба закрыты на одном уровне, из обоих одинаково сложно вырезать рекламу. И вырезать её всё равно будут не из них, а из построенного ими DOM.
dmitrmax
25.12.2015 02:09+6Смотрите на два шага вперед. Сначала вам сделают бинарный JS. Потом скажут: а нафига эта свистопляска с DOM? Пусть браузер тупо исполняет код и рисует в экран. Жаба-аплеты помните? То, что не удалось тогда Sun, потому что у них не было своего браузера, сейчас на ваших глазах сделает Google сотоварищи. Только следите за руками.
tangro
25.12.2015 02:26Свистопляска с DOM нужна пока, чтобы кормить миллионы дизайнеров и верстальщиков :) А в широком смысле слова — вы на С++ не нарисуете интерфейс настолько быстро и красиво, как на HTML+CSS. Ну, вернее, может и красивее нарисуете, но точно не быстрее. А вот провалидировать ввод регэксиком, сделать HTTP-запрос, распарсить JSON, как-то данные эффективно в памяти разложить и быстро искать — на С++ будет реактивно и приятно.
zapolnoch
25.12.2015 07:13А в чем тогда преимущество по скорости? Ведь в браузере уже давным давно тормозит не JS, а DOM. Какая разница чем вы будете манипулировать DOM (хоть Ассемблером), ведь он сам является узким местом.
Antelle
25.12.2015 09:36Цель wasm — не новый фреймворк вроде java и прочих, а для того, чтобы 1. тяжёлую логику сделать компилируемой, 2. позволить компиляцию из любых языков. Кстати в десктоп-приложениях проблема такого количечтва элементов, как требуется от DOM, тоже не решена никак, его не на что заменить.
dmitrmax
25.12.2015 10:35+2Декларируемая цель — да. А так: посмотрите, во что превратился ACPI из декларируемой цели сделать управление питанием простым и легким. Понимаю, что это далеко от вэб-разботки и гораздо ниже уровнем, но аналогия, как мне кажется, очень хорошая и показательная.
Кроме того, ответ на вопрос предыдущего оратора в чем преимущество по скорости так и не дан. А если не скорость, то ради чего это всё?tangro
25.12.2015 11:21+2Ну представьте какую-нибудь игрушку в браузере. У неё некоторая часть нагрузки — это физический движок, который до этого надо было писать на Javascript и он тормозил, к примеру, для рассчета какого-нибудь там взрыва\дыма\блика\дождя. Теперь код рассчёта физики будет можно написать на С++, ну а отрисовывать как раньше — по канвасу (который тоже уже через DirectX рисуется с ускорением). Прикиньте — какое-нибудь там GTA в браузере будет работать, ну потому что нет никаких больше причин, почему бы оно не работало.
dmitrmax
25.12.2015 11:32Вы либо путаете тёплое с мягким, либо путаетесь в показаниях.
Если речь идет о неком бинарном intermediate language, чем мне представляется WebAssembly из того, что я прочитал, то там должно быть всё равно на чём писать. Вы будуте ограничены наименьшим из возможностей языка и возможностей WebAssembly. Таким образом, никаких преимуществ кроме вкусовщины вы не получите.tangro
25.12.2015 12:20-1Там и есть всё-равно на чём писать, просто писать будут на С\С++ :) Преимущества получаются от того, что это будет бинарный код, уже собранный под нужную архитектуру проца. И не надо тратить время на парсинг и интерпретацию javascript. Плюс можно делать такие прикольные штуки как реалтайм обработка видео, таймеры с точностью до сотен наносекунд, какой-нибудь массивчик на миллиард элементов в словаре и т.д. — попробуйте это на javascript написать.
dmitrmax
25.12.2015 12:28Я ничего не понимаю. С какого рожна вэб-разрабы вдруг возьмуться за C++? А главное зачем, если то же самое можно написать на знакомом им JS, скомпилировать и вперде?
Нет абсолютно никакого спроса на разработку вэб-логики на C++. Если оставаться в рамках вэб-логики.tangro
25.12.2015 12:54+3Так они и будут писать на «знакомом JS» — в смысле всякие «обычные» сайты. Просто те библиотеки, которые они сейчас используют (jQuery, Angular) будут переписаны на WebAssembly и начнут работать в разы больше. Но интерфейс у них останется тот же. Плюс добавляется возможность написать и «необычный сайт» — игрушку типа флешевой, презентацию, веб-редактор видео и т.д. — массивная логика больше не будет тормозить из-за неэффективности Javascript.
dmitrmax
25.12.2015 14:23+2А разве сейчас для JS не применяются JIT-компиляторы? А если они применяются, то есть какие-то общедоступные результаты профилирования, которые подтверждают, что проблема именно в JS?
dmitrmax
25.12.2015 12:50Прочитал ваш измененный камент. Скажите, а вы сами разработчик? Как у вас в одном абзаце уживаются слова: «Там и есть всё-равно на чём писать» и «попробуйте это на javascript написать»?
tangro
25.12.2015 12:56+2«Там и есть всё-равно на чём писать»
Код можно будет написать на любом языке, для которого будет создан компилятор в WebAssembly. Первым появится компилятор для С\С++ (потому что LLVM его уже пилят), но потом, возможно, будут и другие.
попробуйте это на javascript написать
Имелось в виду «попробуйте это написать сейчас на javascript, выполняющемся в браузере без WebAssembly» — работать будет очень медленно.ZyXI
25.12.2015 15:19Код можно будет написать на любом языке, для которого будет создан компилятор в WebAssembly. Первым появится компилятор для С\С++ (потому что LLVM его уже пилят), но потом, возможно, будут и другие.
Вообще как я понял emscripten занимается не компиляцией C/C++ в JS. Он занимается трансляцией LLVM биткода в JS, соответственно в WebAssembly можно скомпилировать любой язык, поддерживаемый LLVM. Уже можно. Но в статье почему?то говорится только о C/C++.
Если я прав, то, соответственно, писать компиляторы в WebAssembly практически не будут. Будут в первую очередь писать компиляторы в LLVM биткод.
Serator
25.12.2015 15:24+2Такой длинный спор и в качестве профита — пример в виде переписанного jQuery / Angular. Ну перепишут (ли? — прямо таки огромным «ли?») и будет работать на миллисекунду в секунду быстрее, но тормозить же все равно будет отрисовка. В большинстве случаев проблема в неэффективном использовании операций работы с DOM, что вызывают лишние перерисовки, перерасчеты размеров, положения элементов на странице и т.п., а не скорость работы с JS. Вот работа с аудио, видео, игродев и прочее — вот здесь профит может быть куда ощутимее.
dmitrmax
25.12.2015 19:58Так о том и речь, что под видом мнимой производительности юзеры получат анальный зонд.
dmitrmax
25.12.2015 10:31А в широком смысле слова — вы на С++ не нарисуете интерфейс настолько быстро и красиво, как на HTML+CSS. Ну, вернее, может и красивее нарисуете, но точно не быстрее.
Дооо! Видимо от того, как быстро, гибко и красиво можно наструячить под HTML+CSS к каждому первому большому сайту теперь есть свой апп под iOS и Android. Следующий ход: сделать апп под браузер. Следующий ход избавится от отдельных аппов под мобильные платформы, превратив вэб в сплошные закрытые аппы.
Zifix
25.12.2015 11:06+1А в широком смысле слова — вы на С++ не нарисуете интерфейс настолько быстро и красиво, как на HTML+CSS. Ну, вернее, может и красивее нарисуете, но точно не быстрее.
Почему быстрее не получится, расскажите?tangro
25.12.2015 11:24Потому, что многие штуки из HTML+CSS просто не реализованы пока достаточно хорошо даже в мощных UI-фреймворках типа Qt и их придётся писать руками. А даже если реализованы — вы программистов на таком уровне знающих QML и всякие кутешные стили не найдёте даже 1% от количества дизайнеров и верстальщиков, знающих HTML+CSS.
Zifix
25.12.2015 11:31Потому, что многие штуки из HTML+CSS просто не реализованы пока достаточно хорошо даже в мощных UI-фреймворках типа Qt и их придётся писать руками.
Какие штуки? Можно хоть пару примеров?
А даже если реализованы — вы программистов на таком уровне знающих QML и всякие кутешные стили не найдёте даже 1% от количества дизайнеров и верстальщиков, знающих HTML+CSS.
Там для качественной верстки порог вхождения на порядок ниже, так что вопрос с количеством решится очень быстро, тем более что логика в QML и так пишется на JS.
Zifix
25.12.2015 11:05Потом скажут: а нафига эта свистопляска с DOM? Пусть браузер тупо исполняет код и рисует в экран.
И это будет просто шикарно, это я вам как QML разработчик говорю. Нельзя вырезать рекламу? Ну из мобильных приложений тоже нельзя, живем же как-то.dmitrmax
25.12.2015 11:37Шикарно? Ну сиюминутную выгоду в том, что вы, я и ещё 100 тысяч девелоперов внезапно станут востребованными на рынке вэб-разработки, получим. Но как быть с тем, что 7 млдр. людей (в том числе и мы с вами) получат очередной анальный зонд?
Zifix
25.12.2015 11:50Мне кажется, вы неправильно трактуете термин «зонд». Еще раз: проблема только в том, что рекламу нельзя вырезать, верно?
dmitrmax
25.12.2015 12:06Нет, реклама — это только самое первое и самое безобидное, что приходит на ум. В перспективе вы получите андроид или айос. Да, будет умерено безопасный браузер. Да, будут приложения с разными правами и браузер будет контролировать, чтобы они эти права не превышали. Но будет юзер, который будет собственноручно и слепо выдавать права приложениям, не имея в сущности возможности проверить на сколько добросовестно приложение этими правами пользуется. И только не надо в этом месте рассказывать про юзера, который сам себе злобный буратино, потому что у него не будет другой альтернативы.
Zifix
25.12.2015 12:10Какие права? Как была песочница в браузере, так и останется.
dmitrmax
25.12.2015 12:22+1Это то, что вам сейчас обещают. Так было в своё время с ACPI, когда всем сунули открытую спецификацию и сказали: нафига ОС знать много подробностей об управлении питанием? Давайте сделаем AML, который будет хранится в BIOS, а в ОС будет интерпретатором этого кода.
Что имеем теперь? Теперь в каждом PC процессор иногда входит в System Management Mode. Ни ОС, ни кто-либо другой не может ни предсказать, когда это случается, ни посмотреть что за код исполняется в этот момент, потому что этот код закрыт даже от ОС (даже в бинарном виде). Потом к этому добавили UEFI и Management Engine, который также связан с этой фигней. Его работа является одним из самым больших секретов корпорации Intel (у AMD свой не менее секретный аналог). Даже разработчики BIOS'ов получают от Intel кусок бинарного говна, который они обязаны включить в свой BIOS и всё. Никаких сведений.
А всё начиналось так безобидно.
tangro
25.12.2015 12:50+2Приложения, работающие на WebAssembly будут иметь те же права, которые сейчас имеет javascript в браузере. И так же, как javascript, их выполнение можно будет отключить. Ничего с этой точки зрения не поменяется.
dmitrmax
25.12.2015 14:31Вы сейчас нам рассказываете про то, с чем WebAssembly предстанет пред ясные очи общественности в первой версии. Мы же в этом треде обсуждаем скорее перспективы его развития.
tangro
25.12.2015 15:52-2А, ну так захватит браузер и будет за всеми следить, конечно же :) Сейчас все так делают.
BOBS13
25.12.2015 23:15Это конечно все круто и быстро. У меня только один вопрос на сколько это будет безопасно?
Давайте так я пишу на C++ под браузер, у меня есть указатель на адрес в памяти и я могу в теории, обратится к любому участку памяти текущего процесса, я бы не считал это особо безопасным. Можно таких дел натворить.ZyXI
26.12.2015 00:19Вы и сейчас можете писать на C++ под браузер и переводить это через emscripten в asm.js. Это безопасно?
WebAssembly исполняется в виртуальной машине. Он будет ровно настолько безопасным, насколько безопасной будет виртуальная машина: т.е. никаких отличий от текущего статуса с JavaScript, за исключением новизны и, как следствие, наличия пока не обнаруженных ошибок. От используемого языка безопасность не зависит совершенно; хотя на C++ вы будете иметь все шансы обратиться куда?то не туда, это «куда?то» может вести только в память машины.
И, кстати, про безопасность написано прямо в README WebAssembly:WebAssembly is safe: WebAssembly describes a memory-safe, sandboxed execution environment that may even be implemented inside existing JavaScript virtual machines. When embedded in the web, WebAssembly will enforce the same-origin and permissions security policies of the browser.
BOBS13
26.12.2015 00:35Спасибо за объяснение.
Код компилируется более предсказуемо с точки зрения безопасности из js нежели из c++. И всяких дыр там будет хватать, ладно пока в действии не увидишь, не узнаем, но будущие туманно.tangro
26.12.2015 00:38+1А как-будто js-код после интерпретации не превращается в машинный код, который байтики туда-сюда по памяти гоняет и инструкции на процессоре выполняет. А всяких там выходов за границы и переполнений не случается просто потому, что код интерпретатора хорошо отлажен. Вот и WebAssembly отладят.
Gorthauer87
Интересно, получится ли современные js движки и рендеры html просто превратить в обычные библиотеки с wasm кодом для совместимости с существующим кодом, а новые веб приложения делать каким угодно образом?
tangro
Конечно, для того всё и затевалось. Всякие там ангуляры и jQuery не имеет никакого смысла парсить и выполнять как Javascript — это должен быть бинарный код, быстрый и эффективный, но в то же время не встроенный в браузер, чтобы была возможность оперативно его обновить.