Оказывается команда 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/ (перевод на русский)