Пару дней назад Дас Сурма из 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/

Оказывается команда SpiderMonkey (JavaScript движок, используемый в Firefox) недавно завела блог, в котором публикует новости об изменениях в движке. В последней новостной рассылке есть много всего интересного:
- обновление Intl.DateTimeFormat.prototype.formatToParts до актуальной версии, соответствующей последним изменениям в спецификаци
- Project Visage — новый фронтенд (парсер и эмиттер байткода) для JavaScript, написанный на языке Rust
- улучшения парсера
- Project Stencil — новый формат данных, генерируемых парсером
- движок для регулярных выражений будет заменён на тот, что используется в V8
- упрощение байткода
- устаревшие toSource и uneval убраны из движка
- улучшения дебаггера
- улучшения производительности Array.prototype.reverse и BigInt
- в Nightly появился флаг, включающий поддержку JS BigInt <-> wasm I64 conversion
- продолжается работа над уже добавленными #WebAssembly пропозалами Reference types и bulk memory
- много улучшений Cranelift — кодогенератора, который в будущем будет использоваться для оптимизирующего компилятора WebAssembly
- ведётся работа на WebAssembly пропозалом multi-value
- ведётся работа над включением SharedArrayBuffer по умолчанию
- начата работа по добавлению WebAssembly пропозала exception handling

В блоге v8 появилась статья про использование SIMD в WebAssembly — "Fast, parallel applications with WebAssembly SIMD".

SIMD (Single Instruction, Multiple Data) — набор низкоуровневых инструкций процессора, которые позволяют распараллеливать обработку данных в рамках одного ядра. SIMD используется для ускорения работы кодеков, алгоритмов обработки изображений, компьютерного зрения и т.п. Чтобы web-приложения могли использовать SIMD-операции, разрабатывается расширение стандарта WebAssembly. В окончательном стандарте набор инструкций будет ограничиваться только теми инструкциями, которые можно использовать вне зависимости от архитектуры процессора.

Разработчики v8 представили экспериментальную реализацию предложения, благодаря ей демо отслеживания жестов рук ускорилось в пять раз. Демку можно запустить в последней версии Chrome, включив "WebAssembly SIMD support" в chrome://flags/.

#webassembly #v8

https://v8.dev/features/simd
https://storage.googleapis.com/mediapipe-viz.appspot.com/wasm-demos/hand-tracking-simd/hand_tracking_demo.html

На сайте Mozilla Hacks появилась интересная статья Натана Фройда про новый механизма сандбоксинга кода — "Securing Firefox with WebAssembly".

Для предотвращения выполнения вредоносного кода в Firefox используется два подхода: сандбоксинг на уровне процессов и переписывание критичных частей на Rust. Первый подход хороший, но требует много системных ресурсов, переписывание на Rust не всегда самый оптимальный вариант.

Исследователи из Стенфорда, UC и других университетов представили новый инструментарий для более простого сандбоксинга библиотек — RLBox, который сейчас внедряется в Firefox. Его идея состоит в компилировании потенциально небезопасного кода в wasm. Скомпилированный wasm-модуль затем компилируется в нативный код, который может использоваться из любой подсистемы браузера. Данные, которые обрабатываются скомпилированным модулем считаются "испорченными" (tainted), их корректность использования проверяется на этапе компиляции. Если сторонняя библиотека была скомпроментирована, то благодаря дополнительному набору проверок небезопасный код не сможет попасть в браузер. Этот подход уже внедряется в Firefox 74 (Linux) для сандбоксинга библиотеки рендеринга шрифтов Graphite.

WebAssembly давно используется для разработки сложных web-приложений, идёт работа над системным интерфейсом для wasm (WASI), который уже поддерживается в Node.js, и вот сейчас его начинают использовать для изоляции библиотек. WebAssembly становится по-настоящему мощным инструментом.

#security #webassembly #internals

https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/

Ингвар Степанян из Google написал статью про ускорение сжатия png-изображений в Squoosh — "Bringing OxiPNG to Squoosh".

Squoosh.app, несмотря на то что работает в вебе, попадает в категорию лучших инструментов для сжатия изображений. Для работы с png в нём использовалась скомпилированная в WebAssembly C-библиотека OptiPNG. У неё есть продвинутая альтернатива — Rust-библиотека OxiPNG, основное преимущество которой поддержка многопоточности (планируют задействовать в будущих релизах Squoosh).

Первая попытка миграции на OxiPNG привела к увеличению размера сжимаемых png относительно OptiPNG. Проблема была в библиотеке miniz_oxide, которая реализует алгоритм сжатия без потерь deflate, использующийся в png. Проблемная библиотека в итоге была заменена на libdeflater. После миграции на OxiPNG скорость сжатия png в некоторых случаях ускорилась более чем в два раза, и на несколько процентов сократился объём генерируемых файлов.

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

#webassembly #tool #graphics

https://rreverser.com/bringing-oxipng-to-squoosh/

Пол Батлер — экс-гуглер — написал эссе про будущее web-приложений — "The WebAssembly App Gap".

В 2005 году с появлением AJAX в web'е произошла первая революция, которая принесла в браузеры офисные приложения — текстовые редакторы, календари, почтовые клиенты и т.п. Пол в статье пишет про то, что мы находимся на пороге второй революции, в основе которой лежат WebAssembly и современные браузерные API.

Есть первые ласточки этой революции, например, Figma. Она завоевала рынок благодаря слиянию двух факторов: производительности нативного кода и возможностей web'а для совместной работы. Раньше пользователям хватало обычного графического редактора, сейчас web-альтернатива выглядит достойной заменой, так как сложно игнорировать её преимущества. То же самое может произойти и с другими категориями программного обеспечения.

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

Довольно глубокая статья. В первую очередь рекомендую почитать всем, кто находится в поисках идеи для своего проекта.

#musings #webassembly

https://paulbutler.org/2020/the-webassembly-app-gap/

Крис Сейнти рассказал про фреймворк от Microsoft для создания SPA-приложений на C# — "What’s behind the hype about Blazor?".

Blazor для C#-разработчиков сейчас очень хайповая тема, потому что благодаря ему можно создавать SPA без использования JavaScript. Его архитектура состоит из двух основных частей: App/Component Model (отвечает за компонентную модель, роутинг и другие невизуальные задачи) и Renderer/Hosting Model (отвечает за обновление и отображение UI).

На данный момент есть два стабильных рендерера: WebAssembly Renderer и Server Renderer. Первый используется для создания привычных SPA-приложений (объявлен стабильным в мае этого года). Второй — для клиентских приложений, которые работают на внешнем сервере, браузер клиента в этом случае отвечает только за обновление DOM. Есть ещё два экспериментальных рендерера: для мобильных приложений (использует нативные UI-элементы) и десктопных приложений (работает поверх Electron/WebWindow).

Если всё взлетит, то Blazor в будущем может стать конкурентом React Native и Flutter.

#webassembly #frameworks

https://stackoverflow.blog/2020/02/26/whats-behind-the-hype-about-blazor/

Ещё один пост про прошедший Chrome Dev Summit. Ингвар Степанян выступил на нём с небольшим докладом про улучшения отладки скомпилированного в WebAssembly C/C++ кода в инструментах разработчика — "Debugging WebAssembly with modern tools".

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

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

Новый отладчик пока доступен в экспериментальном режиме в Chrome Canary, но он уже используется разработчиками Google Earth.

#debug #webassembly #chromium

https://developers.google.com/web/updates/2020/12/webassembly

Недавно была опубликована статья, в которой рассказывается про работу с базой данных на статических сайтах — "Hosting SQLite databases on Github Pages".

Когда нужно организовать доступ к большому массиву данных (в режиме read only), а поднимать полноценный бекенд не хочется, можно воспользоваться решением из статьи. Автор реализовал виртуальную файловую систему для sql.js — WebAssembly-версии SQLite. Движок SQLite думает, что работает с обычным файлом, но все запросы на чтение транслируются в HTTP Range запросы к файлу базы данных на сервере. Для хостинга базы можно использовать GitHub Pages, Netlify и т.п.

Количество загружаемых данных зависит от типа запроса. Если база использует индексы и если запрос возвращает небольшое количество данных, то объём передаваемых данных не будет превышать несколько десятков килобайт.

#webassembly #staticsite

https://phiresky.github.io/blog/2021/hosting-sqlite-databases-on-github-pages/

Пару дней назад Эрик Симонс — создатель StackBlitz, online-песочницы для разработки приложений — рассказал о новой фиче проекта — "Introducing WebContainers: Run Node.js natively in your browser".

WebContainers — это проприетарный механизм для запуска Node.js-приложений внутри браузера с помощью WebAssembly. В StackBlitz он используется для создания локальной изолированной среды для разработки серверных приложений внутри браузера (Next.js, NestJS). Несмотря на исполнение кода с помощью wasm-версии Node.js работает всё быстро. В статье написано, что сборка приложения в WebContainer быстрее локальной сборки на 20%. Этот результат получен благодаря использованию кастомного npm-клиента (об этом Эрик написал в комментариях на HackerNews).

Кроме скорости у WebContainers есть другие плюсы. Потенциальные вредоносные скрипты не смогут получить доступ к машине-хосту. Очень просто разворачивать новые среды, что хорошо подходит для быстрого тестирования фич или создания примеров кода с воспроизведением ошибок. Есть бесшовная интеграция с отладчиком Chrome DevTools

В общем, интересная технология, но на данный момент она находится в статусе беты и работает только в Chromium-based браузерах.

#nodejs #webassembly #announcement

https://blog.stackblitz.com/posts/introducing-webcontainers/
https://news.ycombinator.com/item?id=27223012

Лин Кларк опубликовала статью, посвящённую оптимизации работы JavaScript-кода в WebAssembly-окружении — “Making JavaScript run fast on WebAssembly”.

Некоторые платформы ограничивают набор оптимизаций, которые могут быть применены к JavaScript-коду. Например, на iOS и игровых консолях нельзя использовать JIT-компилятор, поэтому JS-движки там могут работать только в режиме интерпретатора. Это ограничивает спектр задач, который может быть решён с помощью JS. Участники Bytecode Alliance (Fastly, Mozilla, Igalia) работают над решением на базе WebAssembly, которое позволит ускорить выполнение JS-кода на таких платформах и достичь уровня производительности JIT-компиляторов ранних версий JavaScript-движков.

В разрабатываемом решении в качестве первой оптимизации будет использоваться снапшот памяти, который позволит сократить время инициализации программы до нескольких микросекунд. В качестве второй оптимизации будет использоваться AOT-компиляция с генерацией стабов для внутренних кешей.

В статье говорится о том, что подобный подход может использоваться не только с JavaScript, но и с Python, Ruby, Lua.

#js #internals #webassembly

https://bytecodealliance.org/articles/making-javascript-run-fast-on-webassembly

Веб-версии Adobe Photoshop и Illustrator

На конференции Adobe MAX 2021 были представлены веб-версии Photoshop и Illustrator. Томас Натстад и Набель Аль-Шама рассказали о технологиях, которые сделали веб-версию Photoshop возможной — "Photoshop's journey to the web".

Веб-версия Photoshop использует WebAssembly и кодовую базу своего старшего брата. Чтобы производительность приложения была хорошей, порт использует новые фичи WebAssembly и Emscripten: многопоточность, SIMD и поддержку обработки исключений. Для поддержки современных дисплеев используется новое цветовое пространство P3 в canvas.

Интерфейс Photoshop построен на веб-компонентах с помощью библиотеки LitElement. В некоторых частях приложения используется React.

Photoshop for Web поддерживает только базовые функции редактирования изображений и комментирование. Также на презентации была представлена веб-версия Adobe Illustrator, но на данный момент она пока недоступна.

Adobe Photoshop и Illustrator работают только в Chrome и Edge.

#webassembly #announcement

https://web.dev/ps-on-the-web/

Рендеринг DOOM с помощью чекбоксов

Эндрю Хэли из Vercel рассказал про свой эксперимент с DOOM — "DOOM Rendered via Checkboxes".

В статье рассказывается про интеграцию библиотеки Checkboxland и WebAssembly-порта DOOM. Checkboxland — это библиотека для рисования с помощью чекбоксов на HTML-странице. С её помощью можно рендерить текст, фигуры, изображения и видео.

Для рендеринга картинки DOOM используется видео. Изображение из <canvas> захватывается с помощью метода captureStream(), преобразуется в MediaStream и передаётся методу renderVideo из Checkboxland. Таким образом получается картинка. Автор пишет про то, что на высоких разрешениях всё тормозило, поэтому он остановился на разрешении 160x100. Вполне возможно, что в будущем мы увидим какой-нибудь бенчмарк на базе этого проекта.

Статья несерьёзная, но интересная. Рекомендую заглянуть.

#webassembly #fun

https://healeycodes.com/doom-rendered-via-checkboxes
https://habr.com/ru/post/590337/ (мой перевод на русский язык)

Возможно, вам не нужен Rust и WASM, если у вас есть JavaScript

Увидел в канале @ufostation ссылку на статью Вячеслава Егорова про анализ проблем производительности библиотеки source-map — "Maybe you don't need Rust and WASM to speed up your JS".

Авторы source-map переписали основную логику библиотеки на Rust и WebAssembly, чтобы улучшить производительность. Егор решил проверить оригинальный код на предмет возможных оптимизаций. Там были найдены и исправлены проблемы, связанные с неоптимальной сортировкой, была уменьшена нагрузка на сборщик мусора заменой большого числа объектов типизированным массивом с ссылками на нужные данные, была испралвена проблема с деоптимизацией кода, связанной с передачей двух аргументов в функцию, которая ожидает на вход три аргумента.

В результате всех оптимизаций JavaScript-код стал уступать по скорости Rust и WebAssembly всего лишь на 15%.

Крутая статья. Рекомендую почитать всем.

#performance #js #internals #webassembly #rust

https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html
https://habr.com/ru/post/350018/ (перевод на русский)