Майкл Дроэтбум неделю назад в статье "Pyodide: Bringing the scientific Python stack to the browser" рассказал про новую разработку Mozilla. Pyodite — это экспериментальный проект для запуска полноценного python data science стека в браузере. Цель проекта — развитие data science экосистемы JavaScript.

Pyodite использует WebAssembly для запуска python-кода в браузере. Из кода на python доступна вся web-платформа: результат работы python-библиотек можно обрабатывать в JavaScript, отображать в canvas и т.п. В статье есть подробное объяснение того, как разработчики достигли интероперабельности между Python и JavaScript, какие были альтернативы и почему они не подошли. Так как проект экспериментальный, ещё остаётся простор для развития, например, многопоточность, которой в Pyodite пока нет.

Сейчас в Pyodite доступны библиотеки NumPy, Scipy, Matoplib, Pandas, но в будущем разработчики планируют интегрировать PyPI (основной репозиторий python-библиотек и программ), таким образом будут доступны ещё более 50000 пакетов.

#webassembly #datascience #python

https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-stack-to-the-browser/

Разработчики Wasmer — рантайма для WebAssembly — представили пакетный менеджер WAPM.

WAPM расшифровывается как "WebAssembly Package Manager". Он состоит из двух частей: приложения командной строки wapm и реестра пакетов wapm.io. Цель нового пакетного менеджера — упрощение работы с модулями WebAssembly (запуск, распространение), поддержка разных видов ABI (WASI, Emscripten), простая интеграция с разными экосистемами языков (Python, PHP, Ruby, JavaScript). В разделе про NPM разработчики пишут про то, что WebAssembly на сервере — это совершенно новый сценарий использования технологии, поэтому при создании WAPM они решили отказаться от экосистемы JavaScript.

Проект, определённо, стоящий, но (имхо) всё ещё экспериментальный, так как у меня с первой попытки не заработал простой пример из статьи.

https://medium.com/wasmer/announcing-wapm-the-webassembly-package-manager-18d52fae0eea

#webassembly #package #announcement

На Microsoft Build 2019 пару дней назад был интересный доклад Дэниала Розенвассера про новые возможности в TypeScript "What’s new in TypeScript".

Разработчики компилятора последний год работали над скоростью. В версии 3.4 добавили инкрементальную сборку сборку проекта с сохранением состояния между сборками с помощью флага --incremental.

Было добавлено ключевое слово readonly, которое можно использовать вместо ReadonlyArray. Ещё теперь можно разворачивать кортеж типов в rest-параметрах функции, что позволяет избавиться от перечисления всех возможных параметров с помощью перегрузки типов. Это позволило улучшить типизацию методов bind и call у функций. Пример использования:

type MyTuple = [string, number];
declare function foo(...args: MyTuple): string;

После доклада автор TypeScript — Андерс Хайлсберг — отвечал на вопросы. Среди них был вопрос про компиляцию в WebAssembly. Если говорить кратко, это не имеет смысла. Для запуска TypeScript в WebAssembly необходим скомпилированный в WebAssembly JavaScript-движок, таким образом появляется избыточный слой (речь шла про браузерное окружение).

В общем, доклад хороший, советую посмотреть.

#typescript #webassembly #talk

https://www.youtube.com/watch?v=Au-rrY0afe4

Пару дней назад Дас Сурма из Google опубликовал у себя в блоге статью про работу с WebAssembly — "Raw WebAssembly".

В статье объясняются базовые принципы работы виртуальной машины wasm. Разбирается структура WebAssembly-модулей в текстовом формате "wat". Есть пара интересных примеров. Например, показывается как из WebAssembly вызывать JavaScript-функцию. Подобный подход используется в wasm-bindgen, для того чтобы из Rust-кода манипулировать DOM-узлами в браузере. Есть пример работы с памятью.

Сурма в статье пишет про то, что для эффективной работы c WebAssembly необязательно знать внутреннюю структуру wasm-модулей и особенности работы виртуальной машины. Но это знание может помочь в тех ситуациях, когда что-то идёт не так.

Мне статья понравилась. Примеры в ней разбираются подробно, есть много ссылок на полезные ресурсы. В общем, если интересуетесь WebAssembly, рекомендую почитать.

#webassembly #vm

https://dassur.ma/things/raw-wasm/

Инженеры eBay неделю назад написали пост про то, как они используют WebAssembly у себя в проекте — "WebAssembly at eBay: A Real-World Use Case". На хабре есть перевод.

В мобильном приложении eBay есть функция чтения штрих-кодов. С помощью отсканированного штрих-кода продавец товара может сэкономить время на заполнении объявления о продаже. Разработчики захотели сделать нечто подобное для мобильной версии сайта.

Сначала для чтения штрих-кодов они использовали JavaScript библиотеку BarcodeReader. Но она работала хорошо только в 20 процентах случаев. Потом они воспользовались скомпилированной в WebAssembly C++ библиотекой, которую они используют в нативных приложениях. И опять возникла проблема — библиотека даёт отличный результат только на сфокусированном изображении. Так как есть ограничения Web-платформы связанные с камерой, они не смогли добиться хорошего результата. Потом они попробовали другую Open Source C++ библиотеку, там тоже было не очень всё ок, но она работала в тех случаях, когда не работала предыдущая библиотека. Поэтому у них появилась идея распознавать штрих-код, используя сразу три разных подхода одновременно: с помощью двух скомпилированных в WebAssembly библиотек и с помощью JavaScript-библиотеки.

Несмотря на то что решение получилось монструозным, распознавание штрих-кодов стало работать стабильно. Клиентские метрики тоже показали успех эксперимента. Теперь они планируют внедрить поддержку чтения штрих-кодов для покупателей. Но в статье не написано, сколько трафика должен загрузить клиент, для того чтобы заработала эта фича.

#webassembly #usecase

https://www.ebayinc.com/stories/blogs/tech/webassembly-at-ebay-a-real-world-use-case/

Дас Сурма недавно написал ещё один пост про работу с WebAssembly — "Compiling C to WebAssembly without Emscripten".

В этой статье он показывает как работать с WebAssembly без Emscripten. Есть пример того, как скомпилировать простой C-код в wasm с помощью llvm. Немного разбирается архитектура llvm (бэкенд/фронтенд-компиляторы). Показывается, как работать с динамической памятью, на примере суммирования массива целых чисел. Для выделения памяти в Emscripten используется malloc, но так как в статье рассказывается про более низкий уровень, там используется простой самописный bump-аллокатор памяти.

Статья довольно техническая и очень подробная. Если интересуетесь темой WebAssembly, рекомендую почитать.

#webassembly #llvm #internals

https://dassur.ma/things/c-to-webassembly/

Евгений Обрезков написал небольшую статью, в которой он разрушает самые популярные мифы, связанные с WebAssembly — "Three myths about WebAssembly". Вот небольшой пересказ, разбавленный моими мыслями.

Первый миф. "WebAssembly — это язык общего назначения". WebAssembly — это бинарный переносимый формат. Хотя у него и есть текстовое представление, он остаётся целью компиляции для других языков.

Второй миф. "WebAssembly — замена JavaScript". WebAssembly был разработан для того, чтобы работать в тандеме с JavaScript, а не заменить его. При этом WebAssembly поможет нативным языкам более эффективно работать с Web API, но это можно считать сайд-эффектом, а не целью создания WebAssembly. Как бы то ни было JavaScript сейчас слишком распространён, чтобы его можно было заменить в мгновение ока.

Третий миф. "WebAssembly быстрее JavaScript". Здесь нельзя однозначно заявить, правда это или нет, так как на скорость работы WebAssembly-кода будут влиять используемые оптимизации во время компиляции. В свою очередь JS-движки могут оптимизировать JavaScript-код настолько качественно, что в некоторых случаях он может быть производительнее, чем скомпилированный C++ код.

Статья небольшая, но в ней всё написано по делу. К слову, ссылку на неё я увидел в твите официального аккаунта WebAssembly.

#webassembly #list

https://blog.ghaiklor.com/2019/06/18/three-myths-about-webassembly/

Партрик Вентузело — независимый эксперт в области ИБ — опубликовал статью про анализ WebAssembly модуля Google Keep — "Analysis of Google Keep WebAssembly module​".

Сначала Патрик пытался выяснить, за что отвечает загружаемый WebAssembly модуль. Для этого он извлёк информацию о сборке. В ней содержались сведения о wasm-тулчейне (emscripten-wasm), использованной системе сборки (Bazel), имя сервера и путь до результата сборки. Название "sketchology", которое находилось в пути, дало подсказку о том, что модуль отвечает за создание векторных изображений в заметках Google Keep.

Далее в статье рассказывается, какую ещё информацию можно достать из модуля. Например, в секции данных модуля находились бинарные данные protobuf. Их можно проанализировать с помощью protobuf-inspector. В той же секции находились абсолютные пути скомпилированных файлов, сообщения об ошибках, имена функций и констант. С помощью этой информации можно восстановить дерево скомпилированного проекта. При большом количестве времени и упорстве возможно декомпилировать wasm-модуль в C-код.

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

#webassembly #security #re

https://webassembly-security.com/google-keep-webassembly-module-analysis/

Лин Кларк на Mozilla Hacks опубликовала большую статью, посвящённую новому пропозалу в WebAssembly — "WebAssembly Interface Types: Interoperate with All the Things!"

На данный момент WebAssembly без использования glue-кода может общаться с внешним миром только числами (значения, смещения, адреса). Пропозал "WebAssembly Interface Types" позволит работать со сложными типами напрямую (строки, объекты, структуры и т.п.) Это открывает двери таким возможностям как работа с Web API непосредственно из WebAssembly без привлечения JavaScript, общение wasm-модулей, скомпилированных из разных языков, между собой, использование одного и того же модуля без перекомпиляции в совершенно разных окружениях, например, Node.js, Python, WASI-рантаймах и т.п.

В статье очень детально разбирается, как это всё работает. От описания высокоуровневой проблемы до примеров реализации того, как будут представлены интерфейсные типы в коде wasm-модулей. Экспериментальная поддержка предложения есть в рантайме Wasmtime, Rust-тулчейне и wasm-bindgen.

Что сказать... очень крутая новость. Пойду ещё разок задоначу в Mozilla Foundation.

#webassembly #proposal

https://hacks.mozilla.org/2019/08/webassembly-interface-types/

Валерий Щавель из Яндекс.Карт рассказал на хабре про опыт использования WebAssembly — "Как мы внедряли WebAssembly в Яндекс.Картах и почему оставили JavaScript".

В Яндекс.Картах объекты перед отрисовкой разбивают на треугольники прямо в браузере. Это ресурсоёмкая задача, которую решили попробовать вынести на уровень WebAssembly. Ребята сделали прототип, который использует wasm, и внедрили его в своё TypeScript-приложение. Скорость обработки тайлов выросла в несколько раз, но появилась просадка из-за накладных расходов на передачу данных из wasm в js. Также вырос размер бандла (в комментариях пишут, что это скорее всего из-за неиспользуемых фич emscripten). В итоге от WebAssembly на данный момент решили отказаться.

Статья интересная. Советую почитать, если интересуетесь темой WebAssembly.

#webassembly #experience #yandex

https://habr.com/ru/company/yandex/blog/475382/