WebAssembly – коротко о главном

Недавно официально объявили о запуске проекта WebAssembly (также называемого как wasm), который преподносится как новый шаг в развитии Веба, посему немного тормозну на этой теме отдельно. И хотя про WebAssembly пока мало конкретики, а так, скорее одни намерения да видения, я попытался выцедить из этой темы все самое важное.

Под катом кратко перетру что это и для чего, специально для тех, кому лень тыркать ссылки самим.

Веб ожидает большое будущее: http://t.co/ImqN15jVj0. О WebAssembly и начале новой эры. pic.twitter.com/tSiIaXertC
— Хабрахабр (@habrahabr) 26 июня 2015

Что такое WebAssembly?

Я прочитал первоисточник — пост Брендана Айка про webassembly и вот что я понял:

  1. Исполняется внутри браузера (C++)
  2. Есть виртуальная машина JavaScript
  3. Она исполняет загрузчик на JavaScript (вернее, компилит его на лету в машинный код

    x86)

  4. Который на самом деле не настоящий JavaScript, а asm.js, и виртуальная машина это замечает и переключается в режим более «прямой» и более «жадной» компиляции …
  5. Кстати, как и большинство кода на asm.js, загрузчик изначально написан на С/С++ и
  6. скомпилирован в asm.js при помощи компилятора Emscripten …
  7. Загрузчик на asm.js разбирает специальный файл .wasm …
  8. Который скомпилен из кода С++ при помощи Emscripten …
  9. И превращает его в Javascript …
  10. Конечно, не настоящий JavaScript, а asm.js …
  11. Который тоже компилится на виртуальной машине JavaScript из пункта (2).
  12. На самом деле, конечно, это не окончательный уровень абстракции.

Машинный код x86 соответствует модели CISC-процессора (сложные, «толстые» инструкции), а современные процессоры совсем другие, они на лету превращают CISC-инструкции в легкие, простые инструкции RISC-стиля.

Но главное — сделать первый шаг к смерти JavaScript.

Забавный комментарий к #WebAssembly «Наконец то можно будет выгнать всех js-кодеров и начать писать SPA на хаскеле! :) »
— Luke Rubinchich (@luke_rubinchich) 19 июня 2015

А вот мнение другого человека, выковырянное отсюда:

В предыдущей инсталляции я писал про Web 2.5 — с потоками, вебсокетом и обменом с сервером исключительно данными. Это было в апреле 2013 года — с тех пор мы должны были шагнуть на уровень выше.

Так вот, Web 3.0 будет основан на WebAssembly. Помимо всего прочего, это, наконец, внутрибраузерная VM и бинарный формат для неё. Google и Mozilla уже договорились, ну и Microsoft, соответственно, подтянется.

Внутрибраузерная среда Web 3.0 будет всё больше напоминать game engine: много анимаций, произвольный рендеринг чего угодно где угодно, WebGL, сетевые протоколы, видеокодеки, текстуры, управление событиями. Ну и потоки кода через вебсокеты, подгружаемого по мере необходимости. DOM, понятно, сохранится, но это теперь будет больше похоже на scene graph.

Ассемблер для Веб. Яваскрипт в отставку? http://t.co/WHyajBF85s #wasm #javascript #WebAssembly #программирование
— Javascript Digest (@nodenow) 26 июня 2015

Вот ещё кусок из этой большой статьи:

А представьте, как здорово было бы заиметь абсолютно универсальный язык-посредник для веб-приложений! Требования к нему, впрочем, кажутся невыполнимыми. Во-первых, это должен быть не просто ещё один язык программирования, а такой, на который легко переводить программы с любых других языков — хоть с C, хоть с Python, хоть с того же Javascript.

Во-вторых, предназначаться в первую очередь он должен не для человека, а для машины, а потому записываться не текстом, а байт-кодом (компактней, быстрее читается компьютером и легче транслируется в машинный код для исполнения). Наконец, в-третьих, он должен пониматься любым браузером на любой платформе. Иначе говоря, необходимо заставить разработчиков всех браузеров трудиться сообща — и это кажется едва не самым сложным!

В то же время wasm призван не заменить Javascript, а избавить его от задач, для решения которых тот не предназначался. Отец яваскрипта Брендан Айк каким-то чудом в разработке WebAssembly участвует — так вот Айк уверен, что яваскрипт не исчезнет.

Просто каждый язык пойдёт своим путём. Javascript возьмёт на себя задачи, не требующие больших вычислительных затрат, а wasm станет именно посредником: писать на нём не будут, в него будут переводить сложные программы с других высокоуровневых языков. В результате станет практически возможным писать эффективные веб-приложения на любом языке программирования, а среднестатистическая производительность таких приложений вырастет.

Там же выцепил такой жирный и полезный коммент, оцените:

Wasm многопоточный, тогда как JavaScript однопоточный — отсюда сразу вылезает куча проблем.

Google, обжегшись на NPAPI и выпустив несколько многопоточных приложений на NaCl/PNaCl, хочет сделать все взаимодействие между ними с помощью сообщений (как в PNaCl). Тогда в wasm«e можно будет синхронно (пусть и медленно, поскольку придется пересекать границу потоков, а то и процессов) вызывать javascript, тогда как в javascript«e придется использовать только асинхронные API с коллбэками. В результате в wasm«e можно будет нормально портировать многопоточный C/C++ код, а в Javascript«e не будет подвисаний на ожиданиях wasm кода.

Mozilla и Microsoft, радуясь успеху от однопоточивания и портирования демки Unity, наоборот, хотят все взаимодействие между wasm и JavaScript сделать синхронным, через прямые вызовы друг друга (как в asm.js). Тогда библиотеки на wasm«e можно будет удобно использовать из JavaScript«a и наоборот.

Однако, за это придется расплатиться тем, что вызвать JavaScript из wasm«a можно будет не на всех потоках, а DOM можно модифицировать вообще только на одном. Многопоточное изменение DOM«а никто в здравом уме делать не будет. В результате с портированием многопоточного C/C++ кода возникнут проблемы и Javascript будет останавливать браузер, ожидая wasm«a. Но ничего, эти проблемы будут героически преодолены использованием веб-воркеров, которые могут общаться с основной программой на JavaScript«e… только с помощью сообщений.

Счастливые разработчики из Apple стоят в сторонке. Они еще не знают во что ввязались.

Смогут ли разработчики браузеров договориться по этому фундаментальному различию между [P]NaCl и asm.js и какого ужа с ежом мы получим в итоге — большой вопрос.

When Oracle doesn’t improve #Java then Google, Microsoft, Mozilla and Apple (WebKit) are teaming up launching #WebAssembly
— the Greek Suspect (@Greek_Suspect) 23 июня 2015

Good explanation of #webassembly by @DrPizza on ars technica http://t.co/vQ0y4nXHDG
— Christian Heilmann (@codepo8) 22 июня 2015

Послесловие

Для тех, кому как обычно и этого мало — интересное интервью с одним из непосредственных разработчиков wasm:

Why We Need WebAssembly: An Interview with Brendan Eich — JavaScript Scene — Medium http://t.co/8v8IhdRB0r
— jonecx (@jonecx) 28 июня 2015

© Blogerator