Уязвимости затрагивают разные этапы обработки файла. Для ошибки iinf/max_items достаточно чтения контейнера через heif_context_read_from_file, без декодирования изображения. Отдельная проблема возникает при обходе ссылок на этапе декодирования, а взаимная блокировка потоков связана с параллельным декодированием grid-тайлов. Поэтому проверка только загрузки метаданных не воспроизводит все три проблемы с высокой оценкой.

• Лимит max_items не применялся к дочерним боксам iinf: файл объявляет сколько угодно элементов, разбор становится квадратичным. Замер: 1,7, 6 и 23 секунды процессора на файлы 1, 2 и 4,1 МБ; файл 6,9 МБ держит 480 МБ памяти, 23 МБ файл 1,5 ГБ, и max_total_memory этого не видит. В сборке под Emscripten тот же счётчик задавал размер alloca на 64-килобайтном стеке WebAssembly: 16 000 элементов проходят, 17 000 роняют вызов, с 18 000 модуль ломается необратимо.
• Неограниченная рекурсия при обходе ссылок могла исчерпать стек; исправленный обход на этапе декодирования использует явный список в куче.
• Инверсия порядка блокировок при параллельном декодировании тайлов grid (включено по умолчанию) давала вечный дедлок; циклические графы ссылок отклоняются до начала декодирования.
• Три проблемы средней важности: чтение за границей буфера в плагинах кодировщиков aom и x265, неисправимая утечка памяти в heif_track_get_next_raw_sequence_sample и чтение за границей в экспериментальном плагине WebCodecs.
• Уязвимы версии от 1.16.0 до 1.23.3 включительно (в зависимости от проблемы), исправлено в 1.23.4; номера CVE будут присвоены позже.

Как одна неучтённая ветка отключила лимит на число элементов

В отчёте описана классическая ошибка перегруженного параметра. Функция Box::read_children принимает max_number, у которого два смысла: со значением-сентинелом READ_CHILDREN_ALL она читает до конца бокса и проверяет лимит max_items, а с любым другим числом читает ровно столько детей и ничего не проверяет. Box_iinf::parse передавала туда счётчик из самого файла, поэтому проверка, написанная специально для iinf, никогда не выполнялась.

Дальше цена растёт квадратично: для каждого элемента вызывается полный проход по списку ссылок iref без раннего выхода. Исследователь измерил на одном ядре 1,7, 6,0 и 23 секунды для файлов в 1,0, 2,0 и 4,1 МБ; абсолютные цифры различаются вдвое между машинами, но рост в 3–4 раза на каждое удвоение стабилен против 2 раз у линейного парсера. Всё это происходит внутри вызова, который затем возвращает heif_error_Ok, без коллбэка отмены и прогресса. В 1.23.4 лимит проверяется заранее, объявленное число ограничено оставшимся входом, а запросы к iref индексируются по идентификатору элемента: на файле с 1 000 элементов и 160 000 ссылок dimg время чтения упало с 1,83 до 0,26 секунды.

Сборка под WebAssembly страдала отдельно. Два вспомогательных метода в Emscripten-обвязке выделяли массив идентификаторов через alloca с размером из того же счётчика. Скрипт сборки не задаёт ни размер стека, ни проверку его переполнения, поэтому использовался стек по умолчанию в 64 КБ: 16 000 элементов занимают 64 000 байт и декодируются, 17 000 прерывают вызов, а с 18 000 переполнение уходит в сегмент статических данных и экземпляр модуля перестаёт работать до перезагрузки страницы. Хелпер вызывается при каждом HeifDecoder.decode().

Рекурсия и дедлок: две другие высокие уязвимости

Вторая проблема: проверка на циклы ссылок между производными элементами была рекурсивной, и длинная цепочка исчерпывала стек. Без лимита на число элементов глубина ничем не ограничена. Исправленный обход на этапе декодирования использует явный рабочий список в куче вместо рекурсии.

Третья проблема затрагивает серверы с параллельным декодированием: параллельное декодирование тайлов grid включено по умолчанию, а ImageItem::decode_image() держит нерекурсивный мьютекс элемента на время вложенных декодирований. Два рабочих потока, чьи элементы ссылаются друг на друга, берут два мьютекса в противоположном порядке и зависают навсегда; процесс не падает и не освобождает ресурсы. Исправление отклоняет циклические графы декодирования, включая рёбра dimg и alpha auxl, до старта.

Кому обновляться в первую очередь

Всем, кто принимает HEIC и AVIF от пользователей: это серверные конвертеры, бэкенды фотохостингов и мессенджеров, CI-пайплайны с ImageMagick, а также веб-приложения, которые декодируют HEIC на клиенте через libheif-js или собственную Emscripten-сборку. Для последних важно, что обрушение WebAssembly-модуля необратимо в рамках страницы. Мейнтейнеры советуют обновиться всем пользователям; в дистрибутивах смотрите на пакет libheif1 или libheif в вашем менеджере. Уязвимость средней важности в плагине WebCodecs касается только Emscripten-сборок с WITH_WEBCODECS=ON, по умолчанию выключенной опции, и только без libde265.

Отдельный отчёт о расходе ресурсов опубликован для Go-библиотеки Excelize: файл на 3 КБ заставляет библиотеку выполнять произвольное число итераций хеширования, и патча пока нет (исправление в сохранённом отчёте не указано). Из недавних выпусков безопасности того же масштаба мы разбирали curl 8.22.0 с девятью уязвимостями и внеочередные релизы PostgreSQL от Postgres Pro.

Источники: libheif v1.23.4 – security maintenance, release notes, GHSA-vg7w-rp49-4fc2: The max_items security limit is not enforced for iinf child boxes, GHSA-xrp2-63fq-jm8q: Unbounded iref entry list and unbounded recursion, GHSA-prgh-72vc-3xmc: Lock-order inversion in parallel grid tile decoding

Я разбираю WebLLM как рабочий инструмент: что нужно от железа и браузера, сколько весят модели, какой скоростью придётся заплатить за отказ от сервера и где проще остаться на облачном API. Все команды и фрагменты кода взяты из README репозитория, цифры производительности из статьи авторов на arXiv, требования к видеопамяти из файла конфигурации в исходниках.

Материал для фронтенд- и фулстек-разработчиков, которым нужен чат, классификатор или JSON-извлекатель на клиенте без счёта за токены и без передачи пользовательских данных третьей стороне.

• WebLLM выполняет модель в браузере на WebGPU, без сервера; API совместим с OpenAI Chat Completions: стриминг, JSON-режим, seed. Вызов функций помечен в README как незавершённый.
• Актуальная версия пакета @mlc-ai/web-llm — 0.2.84 от 27 мая 2026 года; в 2025–2026 годах вышло всего 7 релизов против 63 за 2024 год по данным реестра npm.
• По замерам авторов на MacBook Pro M3 Max WebLLM выдаёт 41,1 токена/с на Llama-3.1-8B и 71,1 токена/с на Phi-3.5-mini, то есть 71–80% от нативного MLC-LLM на том же железе.
• Модели в 4-битной квантизации требуют от 0,7 ГБ видеопамяти (gemma3-1b) до 6,4 ГБ (Qwen3.5-9B) по значениям vram_required_MB в src/config.ts; первый запуск качает всё это с huggingface.co.
• WebGPU по данным MDN есть в Chrome и Edge с версии 113, в Safari 26 с сентября 2025 года, в Firefox с 141 только частично: Linux и Intel-маки не поддерживаются.

Как WebLLM выполняет модель в браузере и при чём тут WebGPU?

Модель считается на видеокарте пользователя через WebGPU, а всё, что не ложится на GPU, крутится в WebAssembly. Авторы описывают схему так: родственный проект MLC LLM компилирует открытую модель заранее в два артефакта, конвертированные веса и WASM-библиотеку с WebGPU-ядрами и вспомогательными функциями. WebLLM в браузере загружает оба артефакта с хостинга, инициализирует WebGPU-устройство и дальше исполняет граф вычислений локально.

Everything runs inside the browser with no server support and is accelerated with WebGPU.

Отсюда же и главное ограничение, о котором в статье авторы говорят прямо: в отличие от CUDA у WebGPU нет готовых ускоренных библиотек для типовых ядер, поэтому матричные умножения и внимание команде пришлось писать и оптимизировать самой. Цена этого видна в замерах: на Apple MacBook Pro M3 Max в Chrome Canary 133 WebLLM версии 0.2.75 выдавал 41,1 токена/с на 4-битной Llama-3.1-8B против 57,7 у нативного MLC-LLM с Metal-ядрами на той же машине, и 71,1 против 89,3 токена/с на Phi-3.5-mini. Это 71,2% и 79,6% нативной скорости соответственно, замер вендора, другого железа в статье нет.

Второй компонент, о котором обычно забывают, это кэш. Веса и WASM-библиотека скачиваются при первом обращении и складываются в хранилище браузера. README перечисляет четыре бэкенда, которые задаются полем cacheBackend в AppConfig: Cache API по умолчанию, IndexedDB, Origin Private File System и экспериментальный cross-origin через расширение Chrome, чтобы одни и те же веса не качались заново для каждого сайта. Без расширения движок сам откатывается на Cache API.

JSON-режим, который в серверных API обычно реализован на стороне провайдера, здесь тоже выполняется локально: по README структурированная генерация встроена в WebAssembly-часть библиотеки модели, а попробовать её со своей JSON-схемой можно в JSON Playground на Hugging Face. Про то, как WASM-рантаймы догоняют нативный код, мы писали в заметке про Wasmi 2.0.

Что нужно, чтобы запустить первый чат?

Достаточно npm-пакета, одного вызова фабрики и терпения на первую загрузку весов. README даёт три варианта установки и импорт через CDN для JSFiddle и CodePen без сборщика.

Движок создаётся функцией CreateMLCEngine: это асинхронная фабрика: она возвращает Promise, а готовый движок с загруженной моделью получают через await. Колбэк прогресса обязателен на практике, потому что без него пользователь смотрит на пустой экран, пока качаются гигабайты.

loading models requires downloading and it can take a significant amount of time for the very first run without caching previously

Дальше интерфейс тот же, что у клиента OpenAI: engine.chat.completions.create({ messages }). Одна ловушка: параметр model в запросе игнорируется, модель выбирается при создании движка или через engine.reload(model). Стриминг включается флагом stream: true, а статистика по токенам приходит только в последнем чанке, если попросить её через stream_options.

Готовый чат для проверки железа не нужно собирать самому: WebLLM Chat сделан на том же пакете, а его код открыт в отдельном репозитории.

Какие модели доступны и сколько видеопамяти им нужно?

В список prebuiltAppConfig.model_list в src/config.ts на 3 сентября входят 165 записей: это варианты квантизации и длины контекста для семейств Llama 3.x, Qwen 2.5, Qwen 3 и Qwen 3.5, Phi 3.5 и Phi 4 mini, Gemma 2 и Gemma 3, Mistral и Ministral 3, дистилляты DeepSeek-R1, SmolLM2, OLMo 2, а также две модели эмбеддингов snowflake-arctic-embed. README при этом всё ещё перечисляет старый набор с Llama 2 и Qwen2, так что актуальный набор виден только в коде.

У каждой записи есть поле vram_required_MB, и это честнее любого «весит N гигабайт»: оно включает не только веса, но и память под KV-кэш при заданном контексте. Для 4-битных вариантов с половинной точностью (суффикс q4f16_1) разброс такой:

• gemma3-1b-it — 0,71 ГБ; Llama-3.2-1B-Instruct — 0,88 ГБ; Qwen2.5-0.5B-Instruct — 0,94 ГБ. Помечены флагом low_resource_required, это кандидаты для встроенной графики и ноутбуков.
• Qwen3-0.6B — 1,40 ГБ; gemma-2-2b-it — 1,90 ГБ; Llama-3.2-3B-Instruct — 2,26 ГБ.
• Qwen3-4B — 3,43 ГБ; Phi-3.5-mini-instruct — 3,67 ГБ; Llama-3.1-8B-Instruct — 5,00 ГБ; Qwen3-8B — 5,70 ГБ; Qwen3.5-9B — 6,43 ГБ.
• Есть и Llama-3.1-70B-Instruct в 3-битной квантизации с требованием 31,15 ГБ; на потребительской видеокарте это не запустится.

Варианты с суффиксом «-1k» урезают контекст до одной тысячи токенов и экономят память: у Llama-3.1-8B это 4,60 ГБ вместо 5,00, у Phi-3.5-mini 2,52 ГБ вместо 3,67. Все эти гигабайты приезжают с huggingface.co/mlc-ai, поэтому доступность и скорость этого хоста в вашей сети стоит проверить до того, как обещать пользователям «работает без сервера». Свою модель в формате MLC подключают через appConfig.model_list, указав URL весов и WASM-библиотеки. Какие небольшие открытые модели вышли в августе и на чём их запускать дома, мы собирали в обзоре открытых нейросетей.

Полный каталог собранных моделей лежит на mlc.ai/models. Номер совместимой сборки библиотек зашит в пакет: для 0.2.84 это константа modelVersion со значением «v0_2_84/base», так что после обновления npm-пакета кэшированные WASM-библиотеки могут потребовать перезагрузки.

Как не заморозить интерфейс: Web Worker или Service Worker?

Для обычного приложения хватает выделенного Web Worker, а Service Worker нужен, когда модель должна переживать переходы между страницами. Оба варианта в README оформлены одинаково: в потоке живёт обработчик, в основном скрипте создаётся движок-прокси с тем же интерфейсом MLCEngineInterface.

С Service Worker сложнее. Его жизненным циклом управляет браузер и может убить поток без предупреждения; движок шлёт heartbeat каждые 10 секунд по умолчанию (значение keepAliveMs в src/service_worker.ts), но авторы просят закладывать обработку ошибок и в приложении. README отдельно требует создавать ServiceWorkerMLCEngineHandler на верхнем уровне скрипта и запрещает делать это внутри обработчиков activate или message: браузер перезапускает уже активный воркер без повторного события activate.

Service Worker's life cycle is managed by the browser and can be killed any time without notifying the webapp. ServiceWorkerMLCEngine will try to keep the service worker thread alive by periodically sending heartbeat events, but your application should also include proper error handling.

Отдельная ветка применения — расширения Chrome: в репозитории есть примеры базового расширения и расширения на Service Worker с WebGPU, которое держит модель в фоне. По данным MDN, в Firefox WebGPU недоступен именно в контексте Service Worker, так что этот сценарий пока привязан к Chromium.

Где WebLLM выигрывает у серверного API, а где проигрывает?

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

• Деньги. Инференс идёт на GPU пользователя, счёт за токены равен нулю. Платите трафиком: каждый новый пользователь качает от 0,7 до 6,4 ГБ весов с Hugging Face; свой CDN нужен только тем, кто перехостит артефакты сам.
• Приватность. Промпты и ответы на сервер не уходят, это следует из архитектуры. Но сетевые запросы есть: веса и WASM скачиваются с huggingface.co и jsdelivr, поэтому формулировка «данные никогда не покидают устройство» некорректна, и в политике приватности так писать нельзя.
• Скорость. 71–80% от нативного инференса по замеру авторов на M3 Max. На ноутбуке с встроенной графикой цифр в статье нет, и обещать «десятки токенов в секунду» без своего замера нельзя.
• Первый запуск. Минуты загрузки против миллисекунд первого ответа у API. Кэш спасает повторные визиты, но не первый.
• Браузеры. По данным MDN, WebGPU есть в Chrome и Edge с версии 113 (полная поддержка на Linux только с 144 и только на Intel Gen12 и новее), в Safari 26 на macOS и iOS с 15 сентября 2025 года, в Firefox с 141 частично: есть Windows и Apple Silicon, нет Linux и Intel-маков. Проверка navigator.gpu обязательна.
• Управление моделью. Серверный API даёт одну версию модели для всех и мгновенную замену. В WebLLM версия модели живёт в кэше каждого браузера, а обновление пакета может потребовать перекачки библиотек.
• Функции. Вызов инструментов через tools и tool_choice в README помечен как WIP с предварительной поддержкой. Для агентских сценариев это стоп-фактор; про выбор стека для агентов у нас есть отдельный разбор.

Есть и организационный риск. По реестру npm пакет обновлялся 19 раз в 2023 году, 63 раза в 2024-м, 3 раза в 2025-м и 4 раза с начала 2026 года; последний релиз 0.2.84 вышел 27 мая. Код в репозитории при этом продолжает меняться, последний push был 3 сентября. Для продакшена это означает, что свежие модели из config.ts могут ждать релиза месяцами.

Evaluations show that WebLLM can retain up to 80% native performance on the same device with room to close the gap further.

Что делать по шагам, чтобы собрать чат на WebLLM за вечер

План ниже покрывает путь от проверки железа до защиты артефактов; команды и имена функций взяты из README для версии 0.2.84.

1. Проверьте, что в браузере есть navigator.gpu, и покажите понятную заглушку тем, у кого его нет. По MDN это Chrome и Edge 113+, Safari 26+, Firefox 141+ с оговорками по ОС.
2. Установите пакет: npm install @mlc-ai/web-llm (версия 0.2.84). Для прототипа без сборки подойдёт импорт с https://esm.run/@mlc-ai/web-llm.
3. Выберите модель из prebuiltAppConfig.model_list по полю vram_required_MB. Для широкой аудитории начните с моделей с флагом low_resource_required: Llama-3.2-1B, Qwen2.5-0.5B, gemma3-1b.
4. Создайте движок через CreateMLCEngine с initProgressCallback и выведите прогресс загрузки на экран.
5. Перенесите инференс в Web Worker через CreateWebWorkerMLCEngine, чтобы интерфейс не замирал во время генерации.
6. Включите стриминг флагом stream: true; для извлечения структурированных данных используйте JSON-режим из раздела Full OpenAI Compatibility.
7. Если артефакты лежат на своём хостинге, добавьте в запись модели поле integrity с SRI-хэшами для конфига, WASM и токенизатора; хэш генерируется командой openssl из README.

При несовпадении хэша движок бросает IntegrityError, либо пишет предупреждение и продолжает работу, если задать onFailure: "warn". Без поля integrity проверка не выполняется вовсе, как и в прежних версиях.

Что дальше: чего нет в WebLLM и за чем следить

Первое, за чем стоит следить, это релиз после 0.2.84: в src/config.ts уже есть Qwen3.5 и Ministral 3, и вопрос в том, когда они попадут в опубликованный пакет. Второе — статус вызова функций, который держится в README как WIP. Третье — cross-origin хранилище: сейчас это расширение Chrome и экспериментальный API, а без него каждый сайт качает свою копию весов.

Мы не проверяли скорость на встроенной графике и на Windows-ноутбуках; единственные опубликованные цифры относятся к MacBook Pro M3 Max. Доступность huggingface.co и esm.run из конкретной сети мы тоже не измеряли: перед запуском продукта на WebLLM стоит замерить время первой загрузки у своей аудитории или перехостить артефакты.

Источники: GitHub: mlc-ai/web-llm (README, лицензия Apache-2.0), src/config.ts: prebuiltAppConfig.model_list с vram_required_MB, src/service_worker.ts: keepAliveMs и heartbeat, arXiv 2412.15803: WebLLM: A High-Performance In-Browser LLM Inference Engine, Блог MLC: WebLLM, 13 июня 2024, Документация WebLLM, Реестр npm: @mlc-ai/web-llm (версии и даты), Hacker News: обсуждение WebLLM 2 сентября 2026, MDN: WebGPU API, совместимость браузеров, Hugging Face: модели mlc-ai, WebLLM JSON Playground, WebLLM Chat, Каталог моделей MLC, GitHub: mlc-ai/mlc-llm

Изображение на обложке: Скриншот: chat.webllm.ai

Wasmi написан на Rust и рассчитан на сценарии, где нужен именно интерпретатор: плагины в приложениях, встраиваемые устройства, песочницы, смарт-контракты. Релиз опубликован на GitHub и crates.io; работа над ним заняла восемь месяцев.

• Wasmi 2.0 примерно в 2,2 раза быстрее Wasmi 1.0 по геометрическому среднему; замеры вендора на Apple M2 Pro, AMD EPYC 7763 и Intel Xeon Platinum 8370C.
• Появились четыре режима dispatch; indirect-threaded на 10–15% медленнее direct-threaded, но экономит память под IR.
• Новое промежуточное представление с аккумуляторными регистрами ireg, freg32 и freg64 и 64-битными ячейками стека.
• Fuel metering стал стабильным и привязан к входному Wasm-коду; появился deterministic profile и новый CLI.
• Включение SIMD больше не замедляет обычный код: в 1.0 это стоило около 8%, в 2.0 разница в пределах шума.

Откуда взялись 2,2 раза

Автор подробно разбирает три источника ускорения. Первый: режимы диспетчеризации инструкций. В 1.0 был один switch-loop, теперь их четыре: direct-threaded, indirect-threaded, switch-loop и call-loop. Режим auto-dispatch включён по умолчанию и выбирает threaded-код там, где компилятор и платформа это позволяют. Indirect-threaded вариант примерно на 10–15% медленнее direct-threaded, зато требует меньше памяти на промежуточное представление, что важно для микроконтроллеров.

Второй источник: новое промежуточное представление. В 1.0 операнды адресовались смещениями в стеке; в 2.0 появились аккумуляторные регистры ireg, freg32 и freg64, через которые проходит большая часть значений. Ячейки стека стали всегда 64-битными, а SIMD-значения занимают две соседние ячейки, поэтому поддержка SIMD больше не стоит производительности обычного кода.

Третий: структура CodeMap, в которой хранятся скомпилированные функции. Она стала append-only с раздельными buckets, поэтому вызов внутренней функции на горячем пути не требует ни одного lookup и не берёт блокировок. Доступ к данным экземпляра модуля, по бенчмарку count/globals, улучшился примерно на 35%; таблицы Wasm уменьшились в 2–4 раза за счёт 32-битных ссылок.

Как измеряли и с кем сравнивали

Замеры сделаны на проекте wasmi-benchmarks, который можно запустить самостоятельно, на трёх машинах: Apple M2 Pro, AMD EPYC 7763 и Intel Xeon Platinum 8370C. Кроме Wasmi 1.0 в сравнении участвовали интерпретаторы Wasm3, WAMR в режиме fast-interpreter, Wasmtime Pulley и Stitch. Это замер вендора: набор тестов, машины и конфигурации выбирал сам проект, и автор оговаривает, что цифры зависят от нагрузки.

В посте есть поучительный эпизод про компилятор. Rust 1.92 включил оптимизацию DestinationPropagation, из-за чего CoreMark у интерпретатора Stitch упал с более чем 3000 до примерно 2200 баллов; после исправления результат вернулся выше 3000. Похожая проблема нашлась и в Wasmi: её устранение подняло CoreMark примерно с 2800 до более чем 4200 баллов, то есть примерно на 50%. Вывод для практики: производительность интерпретатора на Rust заметно зависит от версии компилятора, и после обновления toolchain бенчмарки стоит перепрогонять.

Что изменилось кроме скорости

• Fuel metering, то есть учёт «топлива» на выполнение, стал стабильным и считается по входному Wasm-коду, а не по внутренним инструкциям; это важно для смарт-контрактов и лимитов на плагины.
• Deterministic profile гарантирует одинаковый результат на разных платформах.
• Поддержка memory64 стала опциональной; отключение валидации через feature validate уменьшает бинарник примерно на 200–300 КБ.
• Обновлённый CLI и C-API.

Кому обновление ничего не даст: тем, кто запускает Wasm через JIT-рантаймы вроде Wasmtime или V8 на сервере и в браузере. Интерпретатор нужен там, где JIT запрещён (iOS, некоторые блокчейн-среды), где нет памяти под скомпилированный код или где важна предсказуемость времени запуска.

Как попробовать

Wasmi ставится как обычный crate из crates.io; для Rust-проекта достаточно обновить зависимость wasmi до версии 2.0 и прогнать тесты: автор предупреждает о смене внутреннего представления, а значит, поведение при ошибках и лимитах стоит перепроверить. Проект открыт, спонсируется Stellar Development Foundation с октября 2024 года.

В планах на Wasmi 3.0 названы оставшиеся части WebAssembly 3.0: function-references, exception-handling и gc. Сроков автор не называет.

Источники: Блог Wasmi Labs: Wasmi v2.0, Релиз v2.0.0 на GitHub

Изображение на обложке: Wasmi Labs

Стековые машины (Forth, JVM) различают вычислительные операции и операции работы со стеком — dup, swap, drop. Регистровые машины вместо этого индексируют значения именами переменных.

В Wasm из «стековых» инструкций есть только drop. Никаких dup, swap, rot не предусмотрено.

Поэтому «чистый» Wasm способен вычислять только выражения ровно так, как они написаны. Любая нетривиальная оптимизация (вынесение общих подвыражений, превращение expr^2 в expr * expr) требует локальных переменных.

Корректнее воспринимать Wasm как регистровую машину с операциями, обобщёнными до составных выражений. Бинарный формат — лишь обратная польская запись поверх этой модели.

Регистровая машина и стековая машина

Шаг назад. Что такое стековая машина? Допустим, вы пишете на каком-нибудь языке высокого уровня и вам нужно посчитать 2 * 3 + 5 * 7. У низкоуровневых языков нет понятия составных выражений: они умеют выполнять только одну операцию за раз. То есть вам нужно сделать два умножения, сохранить промежуточные результаты, потом сложить.

Многие низкоуровневые языки — например, ассемблер x86 — представят эти шаги примерно так:

Это регистровая машина. У вас есть переменные (их называют регистрами), в которых можно держать и постоянные значения, и временные результаты. Каждая инструкция — формы var1 = var2 op var3.

Другие языки — например, Forth или Hex Casting — используют для тех же целей стек. Стек хранит последовательность значений в порядке поступления; уже посчитанные подвыражения «лежат» на нём, пока вы работаете с другими частями. На стековом языке тот же самый расчёт выглядит так:

Обратите внимание на сходство: в обеих программах столько же шагов, и шаги делают то же самое. Главное различие — в стековой машине операнды неявно закодированы в порядке инструкций, а регистровая машина каждый раз указывает индексы явно.

Перестановки на стеке

Сжатия без потерь, которое всегда уменьшает данные, не существует — поэтому, делая индексы неявными, мы что-то теряем в выразительной силе. Что именно?

Для простых выражений — почти ничего. А вот когда значения переиспользуются, разница становится очевидной. Представьте, что вы — компилятор и вам надо скомпилировать такой кусок:

На регистровой машине всё прямолинейно:

А вот стековая машина «как описано выше» не умеет ссылаться на одно и то же значение дважды: mul всегда умножает два значения, лежащих на разных позициях стека. Чтобы такая программа стала возможной, в реальные стековые машины добавляют операции работы со стеком — помимо чисто вычислительных. Нужный нам инструмент называется dup — он дублирует верхнее значение стека:

Вы заметите, что регистровая машина посчитала (x*x)*x, а стековая — x*(x*x). Для умножения это одно и то же, но для других операций может быть нет. Чтобы починить — добавляют swap, который меняет местами два верхних значения:

На практике используют ещё больше операций: over (копирует предпоследнее значение наверх), 2dup (дублирует два верхних), drop (выбрасывает верхнее), rot (переносит третье сверху наверх) и так далее.

С этой точки зрения стековые машины можно рассматривать как разделение операций и индексов, на которые они действуют. Регистровые машины всегда явно указывают индексы и платят за это лишним размером, когда индексы избыточны. Стековые машины кодируют индексы только когда нужно — но платят за это ростом числа инструкций. Если хочется красиво — стековые машины реализуют «энтропийное сжатие» регистровой записи: средний код получается компактнее, потому что неявный индекс операнда дешевле в битах, чем явное имя регистра.

А что у Wasm?

Если посмотреть на JVM — известную стековую машину, с которой Wikipedia сравнивает WebAssembly — найдёте примерно тот же набор байт-кода:

• Доступ к памяти и константам: iaload, iastore, iconst.
• Унарные и бинарные операции: d2f, iadd.
• Манипуляции со стеком: dup, dup_x1 (он же over), pop (он же drop), swap.

JVM — не чистая стековая машина: у неё есть инструкции для доступа к локальным переменным (iload, istore). Но без них тоже можно писать вполне рабочие JVM-программы — javac обычно использует их только для переменных, которые программист на Java явно завёл.

А теперь посмотрите на набор инструкций Wasm:

• Доступ к памяти и константам: i32.load, i32.store, i32.const.
• Унарные и бинарные операции: f32.demote_f64, i32.add.
• Манипуляции со стеком: drop, э-э… и всё?

Любопытно, не правда ли? У Wasm полно инструкций, которые принимают аргументы и кладут возвращаемые значения на стек, но почти нет инструкций, которые могут стек переставить. Насколько я могу судить, drop существует только потому, что иначе нельзя было бы проигнорировать результат функции.

По сути, чистый Wasm умеет вычислять выражения ровно так, как они записаны в исходнике. Оптимизирующий компилятор не может сделать вынесение общих подвыражений (CSE) или превратить expr^2 в expr * expr без введения новых переменных. Как только нужно что-то нетривиальное — приходится тянуться к локальным переменным, и иллюзия «стековой машины» рассыпается: получается обычная регистровая.

Семантика

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

Вообразите бинарный Wasm с префиксной нотацией — принципиально это бы ничего не поменяло. Если гадать почему всё-таки выбрали постфиксную — вероятно, чтобы упростить неоптимизирующие интерпретаторы, или потому что у разработчиков был опыт со стек-ориентированными VM, и это стало решающим аргументом.

Эту перспективу подкрепляет ещё один факт: пока Wasm не получил расширение multi-value, управляющие конструкции практически не могли взаимодействовать со стеком. Значения, положенные на стек до if, не были видны внутри его тела; тело if могло вернуть только одно значение, поэтому if по сути был тернарным оператором, и даже значения с одним потребителем приходилось гонять через локальные переменные.

Заключение

Имеет ли это значение на практике? Не очень: почти любую машину можно перевести в SSA-форму (static single assignment — внутреннее представление, в котором каждой переменной значение присваивается ровно один раз; большинство оптимизирующих компиляторов работают именно с ней), и тогда формат входа становится не важен. Простоту реализации стекового интерпретатора тоже надо признать плюсом — это, наверное, помогло Wasm быстрее стать стандартом.

Но я думаю, стоит честно сказать: опыт работы со стек-ориентированными VM плохо переносится на Wasm — потому что Wasm не совсем стековая машина.

Уже после публикации этого поста я нашла ещё один отличный разбор того же вопроса — но с точки зрения оптимизаций. Рекомендую почитать.

Перевод: оригинал — purplesyringa.moe/blog/wasm-is-not-quite-a-stack-machine/. Публикуется с разрешения автора в адаптации редакции tproger.

Эту статью будет проще читать, если вы знакомы с основами Yoke и Air Traffic Controller.

Если вкратце, Yoke позволяет определять пакеты как распространяемые программы, скомпилированные в WASM, которые называются Flights («рейсы»). Air Traffic Controller («диспетчер воздушного движения») расширяет API Kubernetes через Airways («воздушные трассы») — специальный ресурс, который создаёт CRD и связывает его с конкретным Flight.

Этот материал как раз о том, как Air Traffic Controller открывает простор для мощной и гибкой оркестрации ресурсов.

За пределами плоского YAML: как выглядит реальная оркестрация в Kubernetes

Если вам доводилось управлять современными сложными приложениями в Kubernetes, то наверняка знакомо чувство тревоги, когда ждёшь, пока все ресурсы перейдут в healthy-статус. Например, база данных должна быть готова до запуска приложения, серия пакетных задач (batch jobs) должна выполниться в строгой последовательности, а сервис может зависеть от секрета, которым управляет совершенно другая система. Как описать эти взаимоотношения? Сегодня, по большому счёту, никак.

Годами Helm и Kustomize были основными инструментами для управления Kubernetes-приложениями. Но они работают как генераторы манифестов: вы описываете список YAML-файлов, отправляете их в API и надеетесь, что всё сработает. Для простых stateless-приложений это нормально, но когда нужны порядок выполнения, координация между компонентами или управление состоянием — такой подход не годится.

Вот тут и встаёт вопрос оркестрации: способности осмысленно управлять жизненным циклом компонентов приложения, а не просто создавать их, надеясь на удачу.

Пробел в оркестрации

Причина этого пробела кроется в истории. Инструменты вроде Helm и Kustomize — это, по сути, шаблонизаторы на стороне клиента. Они генерируют манифесты, и на этом их работа заканчивается. Даже серверные GitOps-решения вроде Argo CD или FluxCD придерживаются той же концепции, ведь они преимущественно используют те же инструменты для генерации манифестов, которые потом синхронизируют за вас.

Конечно, есть обходные пути. Вы наверняка сталкивались с хуками pre/post-install в Helm или волнами синхронизации (sync waves) в Argo CD. И хотя это полезные фичи, проблема решается лишь частично. Они срабатывают только при установке или обновлении, но не работают на протяжении всей жизни приложения.

Пара слов о YAML и итоговой согласованности

Мы осознаем, что предложение отойти от использования YAML воспринимается неоднозначно. Для многих в сообществе «голые» манифесты — единственный «правильный» способ взаимодействия с API Kubernetes. Такая привязанность привела к тому, что для решения сложных проблем с зависимостями все стали активно полагаться на один базовый паттерн — итоговую согласованность (eventual consistency).

Идея в том, чтобы выкатить всё разом и просто надеяться, что рано или поздно контроллеры всё приведут к желаемому состоянию, зависимости подтянутся и кластер сам… заведётся. Все мы видели это на практике: под уходит в CrashLoopBackOff и висит в нём, пока какая-нибудь другая система наконец не создаст нужный ему ConfigMap или Secret.

Сразу поясним: итоговая согласованность — это фундаментальная часть Kubernetes и очень мощная идея. Проблема в том, что мы слишком долго использовали её как единственный инструмент для управления комплексными воркфлоу. Нам приходилось на неё полагаться, потому что имеющиеся инструменты не давали иного выбора: что имеем, тем и пользуемся. Наши YAML-ориентированные утилиты могли описать лишь то, что мы хотим получить в итоге, но не то, как к этому прийти.

Дилемма оператора

Классический ответ на запрос о создании умных и гибких стратегий развёртывания всегда был один: «Пишите свой оператор».

И хотя создание оператора — мощный и правильный подход, это ещё и масштабная задача. Здесь и высокий порог входа, и постоянные расходы на разработку и поддержку, которые далеко не всегда оправданы. Неужели нет золотой середины?

Новая модель: логика приложения как код

Вот тут-то на сцену и выходят Yoke и Air Traffic Controller (ATC) с новым образом мышления. Вместо того чтобы генерировать статичный набор YAML-файлов, Yoke описывает пакеты в виде исполняемого кода.

Это позволяет сфокусироваться на логике оркестрации приложения, написав простую [WASM] программу, работающую по знакомой схеме:

1. Прочитать входные параметры из кастомного ресурса.
2. Принять решения, основываясь на текущем состоянии кластера.
3. Обновить статус кастомного ресурса, указав прогресс или другую информацию.
4. Создать те ресурсы, которые должны быть в кластере прямо сейчас.

И да, это очень похоже на классический цикл согласования (reconciliation loop) в контроллере Kubernetes — так и задумано.

ATC — это контроллер, чья единственная работа — приводить ресурсы в кластере к желаемому состоянию. WASM-модуль представляет собой ядро логики и выступает посредником для цикла согласования, управляя желаемым состоянием (ресурсами) пакетов и избавляя вас от необходимости создавать и поддерживать собственный оператор с нуля.

Как это работает на практике

По своей сути, «Flight» в Yoke — это просто программа (скомпилированная в WASM; аналог Helm-чартов), которая считывает кастомный ресурс (Custom Resource) из stdin и записывает желаемое состояние системы в stdout.

Но поскольку ATC перезапускает её в рамках цикла управления (control loop), она становится динамической и реагирующей. Код выполняется каждый раз, когда:

• ресурс, которым он управляет (например, Job или Deployment), обновляется или удаляется;
• внешний ресурс, который он отслеживает (например, Secret от другого инструмента), создаётся, обновляется или удаляется.

Так код реагирует на изменения в кластере в реальном времени.

Примеры

Пример 1: пайплайн для последовательного запуска задач

Предположим, вам нужно создать ресурс Pipeline для запуска трёх задач друг за другом: job-one, job-two, job-three. При этом каждая следующая задача должна стартовать только после успешного завершения предыдущей.

С Yoke эту логику можно описать прямо в коде.

Сначала определим Go-тип для кастомного ресурса Pipeline:

Затем добавим соответствующее определение Airway, которое указывает ATC, как им управлять:

Основная магия содержится в WASM-модуле. Рассмотрим её пошагово:

Эта простая Go-программа как раз и реализует логику оркестрации. Она создаёт задачу, проверяет её статус и движется дальше, только когда та завершится. А цикл управления от ATC берёт на себя всю рутину по «ожиданию» и «перезапускам».

Пример 2: координация с внешними ресурсами

Рассмотрим другой распространённый сценарий: приложению требуется база данных. Вы используете Crossplane для инициализации CloudSQLInstance, который в итоге создаёт Secret, содержащий данные для подключения. Deployment не запустится до тех пор, пока этот Secret не будет существовать.

Сегодня вы, скорее всего, просто выкатываете всё сразу и ждёте, когда появится секрет (под приложения находится в состоянии CrashLoopBackOff). Но можно поступить умнее.

Давайте опишем ресурс App, который будет управлять этим процессом:

Airway нужно будет настроить так, чтобы он имел доступ к кластеру, а если точнее — чтобы мог искать ресурсы типа Secret.

Логика в нашем WASM-модуле будет такой:

Эта логика описывает зависимость: создать базу данных, дождаться секрета и только после этого развернуть приложение. Больше никаких подов в состоянии CrashLoopBackOff, только чистая оркестрация с отслеживанием состояния!

Заключительные мысли

Применяя подход «логика приложения как код», Yoke предлагает компромисс между статическими YAML-шаблонами и полнофункциональными операторами. Он позволяет кодифицировать сложные, активно реагирующие стратегии развёртывания с отслеживанием состояния, используя привычные языки программирования и инструменты, делая настоящую оркестрацию доступной для каждого.

Нет. WebAssembly победил — просто не так, как все ожидали.

Главное: WebAssembly не заменил JavaScript в браузере — и не должен был. Его главная роль — мост между языками. Figma, Godot, Squoosh, Cloudflare Workers, Zellij — все они используют Wasm, но вы этого не замечаете — и это нормально.

Где Wasm уже работает

• Figma — конвертирует C++ кодовую базу в браузерное приложение + запускает пользовательские плагины в песочнице через QuickJS+Wasm
• Godot — сборка игр для веба
• Squoosh.app — использует C/C++ библиотеки сжатия изображений прямо в браузере
• Stackblitz — веб-контейнеры на Wasm
• Ruffle — эмулятор Flash в браузере
• Cloudflare Workers — запуск недоверенного кода через V8 isolates
• Zellij, Envoy, Lapce — экосистема плагинов на Wasm

Что такое WebAssembly на самом деле

WebAssembly — это язык. Более точно — байткод, похожий на JVM bytecode, но с меньшим API, более строгими гарантиями безопасности и без мнений о том, как управлять памятью.

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

Цель компиляции, не язык разработки

В Wasm компилируются десятки языков: Rust, C, Zig, Go, Kotlin, Java, C#. Даже интерпретируемые языки работают — их рантаймы компилируются в Wasm (Python через Pyodide, PHP, Ruby). Есть и языки, которые компилируются исключительно в Wasm: AssemblyScript, Grain, MoonBit.

Ваш браузер уже умеет запускать Wasm. Но есть и автономные рантаймы: Wasmtime, WasmEdge, Wasmer — аналоги JVM, но для Wasm.

Безопасность — главное преимущество

Всё внешнее взаимодействие — явные импорты от хоста. Это даёт изоляцию на уровне процесса внутри одного процесса. Cloudflare запускает недоверенный код через V8 isolates — старт в 100 раз быстрее, чем отдельный процесс. Fermyon заявляет о старте менее чем за миллисекунду.

Мост между языками — главная роль

Самое распространённое применение — мост между языками. В большинстве случаев Wasm прозрачен для вас — какая-то библиотека просто использует его в дереве зависимостей. Это обработка изображений, OCR, физические движки, рендеринг, базы данных, парсеры.

Ограничения

• В браузере Wasm работает через тот же пайплайн, что и JS — потолок на производительность
• Пересечение границы хост-программы стоит дорого — пост-мортем Zaplib показал, что постепенная миграция может не дать выигрыша
• Нет нативного строкового типа — системные API приходится пересоздавать, WASI помогает частично
• Самые компактные бинарники даёт Zig, самые тяжёлые без оптимизации — Rust

Почему кажется, что ничего не произошло

Wasm-инструменты массово используются авторами библиотек, а не разработчиками приложений. Внутренности непрозрачны — и это нормально. Многие ожидали, что можно будет обойтись без .js файлов вообще — это крайне маловероятно, ни один вендор браузеров не работает над этим.

Фреймворки Blazor (.NET) и Leptos (Rust) позволяют писать веб-приложения без прямого контакта с JS. Стандартизация идёт: WasmGC уже в Chrome, Firefox и Safari; Component Model развивается в Bytecode Alliance.

FAQ

WebAssembly быстрее JavaScript?

Некорректный вопрос — скорость зависит от рантайма. Но конструкции Wasm хорошо ложатся на современное железо, поэтому в вычислительных задачах Wasm часто быстрее.

Wasm заменит JavaScript?

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

С чего начать?

Попробуйте watlings — упражнения по ручному написанию WAT в стиле rustlings. А для практического применения — wasm-pack для Rust.

Источник: What Happened To WebAssembly — EmNudge

Да, тот самый культовый шутер от id Software, с которого для многих началась эра 3D-игр, теперь работает даже на смартфоне — без установок, эмуляторов и рекламы.

Автор проекта, разработчик под ником @doszone, рассказал, что за основу взял движок Qwasm, но полностью переработал его под Telegram. Он устранил критические ошибки, починил звук, добавил полноценное мобильное управление и интеграцию с мессенджером.

Как это работает

Игра запускается прямо в окне Telegram — на смартфоне, планшете или десктопе. Главные особенности:

• стабильная работа на большинстве устройств;
• поддержка полноэкранного режима и геймпадов;
• автоматическое сохранение прогресса;
• полностью переработанное тач-управление.

Разработчик предупреждает, что играть в шутер с сенсорным управлением все еще «экстремальный опыт», но обещает доработать интерфейс по отзывам игроков.

Что внутри

Бот использует официальную shareware-версию Quake — тот же вариант, который распространялся бесплатно в 90-х. В ней доступен первый эпизод, состоящий из семи уровней и одного секретного, с финальным боссом.

Поиграть можно бесплатно, без рекламы, регистраций и прочих «подписок». Для запуска достаточно написать боту.

Почему это важно

Quake в Telegram — не просто ностальгия, а показатель того, как далеко шагнули веб-технологии. Благодаря WebAssembly (WASM) и API Telegram, полноценная 3D-игра теперь помещается в окно мессенджера, работая без установки клиента или запуска с сервера.

Зачем распознавать паспорта СНГ

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

Сегодня в этом помогает искусственный интеллект – он берет на себя распознавание паспорта и позволяет получить в структурированном виде всю информацию о владельце документа без ошибок и задержек. Однако если решение умеет распознавать только российский паспорт, оно сразу теряет актуальность для Беларуси, Казахстана, Армении, Узбекистана и других стран. Это стратегический недочет – в особенности если бизнес имеет дело с иностранцами: например, связан со сферой туризма, банкингом, перевозками, или просто представлен в соседних с Россией государствах. Существенный спрос на технологии распознавание паспорта СНГ наблюдается со стороны HR-сферы – автоматизация ввода данных позволяет избавиться от бюрократических проволочек при массовом найме и работе с трудовыми мигрантами. Во всех этих случаях поддерживать распознавание документов стран СНГ просто необходимо.

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

Как в этом помогает WebAssembly

PWA, благодаря своей доступности и независимости от устройств и операционок, уже превратились в золотой стандарт для сферы цифровых услуг. «Прокачанные» сайты уже заменяют классические нативные приложения, поскольку не уступают по функциональности и быстродействию и при этом не требуют скачивания, обновления и поддержки в сторах. Кроме того, сейчас буквально на наших глазах происходит интеграция аналогичного формата в мессенджеры – MAX и Telegram. Туда уже интегрируют платежи и переводы, онлайн-покупки, регистрацию в сервисах и другие возможности, которые раньше оставались прерогативой нативных приложений.

Для переноса в веб хорошо знакомого пользователю функционала используется технология WebAssembly, или Wasm. Она позволяет выполнять ресурсоемкие вычисления – например, распознавание документов, анализ изображений, работу с графикой, – непосредственно в браузере. Это возможно без потери скорости и без постоянных запросов к серверу. Мы в Smart Engines разглядели перспективность Wasm задолго до того, как о технологии широко заговорили, и к моменту удаления банковских приложений из App Store и Google Play мы уже имели обширную экспертизу в этой области.

Мы разработали PWA, в котором реализовали распознавание QR-кодов, банковских карт, номеров телефонов, паспортов и других объектов. Это дало возможность ведущим российским банкам внедрить переводы по СБП и оплату квитанций прямо на интернет-странице. Таким образом, проблему блокировки приложений удалось решить – конечный пользователь получает максимально нативный опыт, оставаясь прямо в браузере. Веб-приложение хранит все необходимые ресурсы (включая Wasm-модули) в локальном кеше благодаря Service worker. В результате приложение получается максимально отзывчивым и может работать без интернета.

Как работает распознавание паспорта СНГ

Распознавание паспортов стран СНГ – задача нетривиальная: разные государства используют свои форматы документов, шрифты и уровни защиты. Мы разработали универсальную технологию, которая одинаково уверенно работает с паспортами России, Казахстана, Беларуси, Армении, Узбекистана, Таджикистана и других государств региона. В общей сложности система поддерживает более 100 языков, включая редкие письменности.

На распознавание паспорта любой страны СНГ в браузере с помощью нашего движка уходит всего несколько мгновений. Форма заполняется корректными данными за секунды, а пользователь не тратит время на перепечатку.

Как встроить распознавание паспорта СНГ в веб

Перейдем к делу. Для начала отметим, что источник входа, откуда система будет получать изображения, может быть совершенно любым. Например, камера — тогда речь о фотографии или видео в реальном времени. Документ также может быть прикреплен из галереи или упакован в многостраничный PDF. Все эти форматы можно отрисовать на canvas и передать на распознавание.

Вы выбираете в вашем дизайне место для расположения canvas для вывода видео или делаете его скрытым для отрисовки PDF, например. Этот же подход используется, если вы пользователь айфона и хотите распознавать файл в формате HEIC.

Получаем ссылку на DOM-элемент:

Вот так мы извлекаем из него данные

Теперь же мы переключимся на воркер и заберем эти данные уже из него.

Воркер

Воркер или веб-воркер — это дополнительный поток браузера, который можно использовать для выполнения тяжелых задач, чтобы не нагружать основной поток, где осуществляется отрисовка UI и взаимодействие с пользователем.

Загружаем наш модуль для инициализации WASM.

Инициализируем Wasm-модуль

Создаем инстанс библиотеки распознавания

Сессия распознавания

Теперь мы подготовим сессию для распознавания. Создаем объект настроек

Указываем режим распознавания и маску документа. Можно указать маску звездочкой «*», а режим «anydoc», тогда поиск будет осуществляться по всем доступным документам.

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

Теперь мы инициализируем сессию.

Передача изображений. Видеопоток

В браузере для захвата изображений с камеры необходимо сначала отрисовать видеопоток на canvas, и после этого мы получаем доступ к пикселям, которые передаем в специальный объект Image.

Отметим, что объект canvas возвращает пиксели в формате RGBA, то есть с альфа каналом.

Создание объекта seImage класса se.common.image, необходимого для распознавания, возможно практически из любого набора пикселей, в том числе подходит и четырехканальное изображение.

Изображение создано. Теперь мы можем передать его на распознавание.

Результат

Объект result содержит в себе всю информацию о документе: текстовые поля, координаты шаблона и полей документа, изображения (подписи и фото держателя).

И на этом этапе мы рекомендуем не закрывать сессию, а продолжать подавать в нее изображения, то есть мы рекомендуем использовать распознавание документа в видеопотоке.

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

Если система больше не ожидает получить более качественное изображение на вход, она переводит флаг терминальности сессии в true и вы можете забрать результат.

Проверяйте результат каждый раз на терминальность:

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

А если вам интересно узнать больше про возможности искусственного интеллекта на WebAssembly, рекомендуем почитать наши прошлые статьи про распознавание банковских карт и паспорта РФ в браузере.

Новый стандарт 3.0 уже поддерживается большинством современных браузеров и приносит сразу несколько ключевых нововведений.

Главное из нововведений

• 64-битная адресация: теперь Wasm может использовать i64 вместо i32, что расширяет лимит адресуемой памяти с 4 ГБ до 16 ЭБ (в реальности — до 16 ГБ в браузерах).
• Несколько областей памяти: модули теперь могут напрямую использовать и копировать данные между разной памятью, без обходных трюков с импортом других модулей.
• Сборка мусора (GC): добавлена поддержка управляемой памяти для языков с автоматическим управлением памятью (например, Java, Scala, Kotlin, Dart).
• Типизированные ссылки: улучшенная типизация ссылок и функций позволяет избежать лишних проверок в рантайме.
• Исключения: наконец-то появилась полноценная система обработки исключений — с try, throw и catch, как в других языках.
• Хвостовые вызовы: позволяют не занимать стек при возврате через вызов, что критично для функциональных языков и оптимизаций.
• Расслабленные SIMD-инструкции: добавлены быстрые, но менее детерминированные версии векторных инструкций для повышения производительности.
• Детерминированный профиль: теперь для задач с требованием полной воспроизводимости (например, блокчейны) можно включить строго определенное поведение операций.
• Аннотации в тексте: появилась возможность вставлять пользовательские аннотации прямо в текстовый формат .wat.

Что это значит

WebAssembly становится всё ближе к полноценной виртуальной машине для высокоуровневых языков. В новой версии уже появляются компиляторы для Java, OCaml, Scala и прочих ЯП — благодаря поддержке GC и исключений.

Новый стандарт уже поддерживается в основных браузерах, включая Chrome и Firefox. Независимые движки, такие как Wasmtime, тоже догоняют.

WebAssembly в браузере: как всё начиналось

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

Ярче всего успех этого подхода демонстрирует Figma — популярный редактор для дизайнеров интерфейсов. Для многих стало неожиданностью, что редактор Figma, будучи веб-приложением, написан на C++.

Александр Коротаев, фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

На заре появления WASM многие ошибочно считали его то ли машиной для ускорения JS, то ли нативным модулем, который имеет доступ к операционной системе. Буквально чудо-коробочка, в которую можно поместить весь код, и он станет быстрее в три раза. Но в реальности технология столь ограничена в применении, что она до сих пор остается нишевой, хотя и очень перспективной.

До WebAssembly разработчики Figma использовали технологию asm.js — предшественника WASM. Специальный компилятор преобразовывал (транспилировал) код C++ в высокооптимизированный JavaScript, который браузерные движки могли выполнять с близкой к нативной производительностью. У этого подхода были недостатки: большой размер получаемого кода и затраты на его парсинг и компиляцию в браузере.

Переход на WebAssembly стал переломным моментом. Поскольку WASM — это бинарный машинно-ориентированный формат, он гораздо компактнее и требует меньше ресурсов для обработки браузером. В результате миграции с asm.js на WebAssembly, Figma получила трёхкратный прирост производительности.

Этот кейс наглядно показал, что WebAssembly — это не просто ещё одна веб-технология, а настоящий прорыв, который стирает границы между нативными и веб-приложениями. Успех Figma и подобных проектов заложил фундамент для следующего логического шага: если WebAssembly так эффективен в браузере, почему бы не запускать его где угодно?

Почему WebAssembly выходит за пределы браузера

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

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

Главным катализатором этого процесса стал стандарт WASI (WebAssembly System Interface), разработанный при участии Mozilla, Fastly и других компаний. WASI предоставляет стандартизированный интерфейс, где WebAssembly-модули взаимодействуют с операционной системой и решают проблему переносимости между различными платформами.

Александр Коротаев, фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Открытая «кроссплатформенная» обертка WASI — это довольно большой прорыв в разработке, так как в текущем состоянии все современные продукты, выпускающиеся для разных ОС с одной кодовой базой, имеют большие, подчас legacy модули совместимости, или же запускаются внутри особых песочниц, сильно увеличивающих размер бандла. Например, браузерный движок Electron или React Native.

Как WebAssembly работает вне браузера

Вне браузера WebAssembly исполняется в специальных средах выполнения (runtimes), которые взаимодействуют с операционной системой через WASI. Известные примеры — Wasmtime от Mozilla, Lucet от Fastly и Wasmer.

Эти среды выполняют роль «концептуальной операционной системы», предоставляют модулям WebAssembly стандартизированный доступ к системным ресурсам: файлам, сети, случайным числам и другим функциям.

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

Безопасность как фундаментальное преимущество

Безопасность WebAssembly основана на нескольких уровнях защиты. Модули выполняются в изолированной среде, отделённой от хост-системы с помощью техник изоляции отказов. Это означает, что приложения выполняются независимо и не могут покинуть песочницу без явного разрешения через API.

Система контролирует выполнение кода с помощью статической проверки типов — все функции нужно явно объявлять перед использованием. Даже косвенные вызовы проверяются на соответствие сигнатурам прямо во время работы программы. Такой подход блокирует распространённые атаки — переполнение буфера и внедрение вредоносного кода.

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

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

Если запускать изолированные модули WebAssembly на своей инфраструктуре вместо публичного облака, можно безопасно обрабатывать чувствительные данные без риска утечки.

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Здесь явно подчеркивается безопасность платформы из коробки, но не стоит забывать, что на разработчике все еще лежит ответственность за безопасность данных и пользователей. Режим «разрешить все» — стандарт для любого MVP, и без аудита перед релизом тут все еще не обойтись. Платформа лишь гарантирует, что память процесса будет защищена от несанкционированного доступа, что уже давно делается во всех популярных операционных системах. Чтобы выйти за пределы стека или прочитать чужую память, надо использовать очень старые компиляторы или сильно низкоуровневые средства разработки.

Серверные применения WebAssembly

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

Микросервисы и бессерверные архитектуры

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

Кейс: компания Fastly использует WebAssembly для исполнения пользовательского кода на серверах. Их технический директор Тайлер МакМаллен отмечает: «Мы рассматриваем WebAssembly как платформу для быстрого и безопасного кода в облаке на границе сети».

Безопасные расширения приложений

Многие приложения позволяют пользователям запускать собственный код через плагины и расширения. Но это создаёт риски для безопасности. В WebAssembly пользовательский код выполняется с минимальными рисками.

Веб-сервер Angie использует WASM для безопасности пользовательских модулей. Это решает проблему совместимости, характерную для традиционных модулей, написанных на C.

Экономическая эффективность таких вариантов становится решающим фактором. По данным на 2025 год, глобальный рынок больших языковых моделей (LLM), чьи backend-системы часто используют микросервисные архитектуры, демонстрирует колоссальный рост. Прогнозируется, что к 2033 году он достигнет $140,8 млрд.

Для таких масштабов нужны технологии с качествами, которые как раз предоставляет WebAssembly: безопасность, переносимость и эффективное использование ресурсов. Почти все компании из списка Fortune 500 уже используют генеративный ИИ в своих бизнес-процессах, и для многих из них WebAssembly — ключевой инструмент для развёртывания и масштабирования этих рабочих нагрузок.

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Здесь все закономерно: бизнес всегда выбирал решения, где можно было написать код один раз и поставить его сразу на несколько платформ. Даже если сами решения сырые и небезопасные, дешевле было увеличить поддержку пользователей и настроить аудит безопасности, чем реализовать фичу для каждой платформы отдельно. Так на рынок вышли Python, Node.js, React Native, стремительно обгоняя конкурентов за счет скорости разработки.

WebAssembly в embedded-системах

WebAssembly успешно работает на серверах, но главные изменения происходят во встроенных системах. В IoT всегда была проблема совместимости: разные процессоры, операционные системы и периферийные устройства.

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

Удаленные интерфейсы и централизованный мониторинг

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

Согласно исследованию Qt Company, более 77% респондентов из промышленной автоматизации считают удалённое управление и централизованный мониторинг критически важными в ближайшие десять лет. WebAssembly предоставляет экономичный способ реализации таких решений.

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

А это, пожалуй, самая продающая фича: обычно у компаний, которые выходят на рынок со своими железками, базами данных и прочими продуктами, все продажи буквально построены на том, что программисты у клиента знают, как это быстро встроить. Так, бизнес готов платить деньги. Обычно у них есть проблемы с API для разных языков программирования, ОС и девайсов: либо хорошо все в JS, а в мобилках не заводится, либо наоборот. А то и вообще: стоит забросить поддержку платформы хоть на полгода, сразу всёперестает работать. Потому поставлять модуль для WASI должно быть дёшево, при этом потенциально можно закрыть даже платформы будущего. Это инновация сродни изобретению стандарта USB.

Прототипирование и сотрудничество

WebAssembly упрощает процесс прототипирования и обратной связи для embedded-устройств. Разработчики могут скомпилировать приложение, разместить его на веб-сервере и предоставить доступ всем заинтересованным сторонам. При этом не нужно распространять устройства или проходить сложные процессы публикации.

Компания Qt использует этот подход в Qt Design Viewer, позволяя разработчикам делиться интерактивными дизайнами, созданными в Qt Design Studio, с коллегами по всему миру.

Примеры внедрения: история ByteFog

Компания Inetra из Новосибирска разработала технологию peer-to-peer для доставки видео ByteFog. Система работает на множестве платформ: Windows, Linux, Android, iOS, Web и Tizen.

Изначально веб-версия использовала Netscape Plugin API, но когда основные браузеры прекратили поддержку этой технологии в 2015 году, компания осталась без веб-версии на два года. Поэтому в 2017 году они обратились к WebAssembly.

Используя компилятор Emscripten, разработчики перенесли существующее C++-приложение в браузер. Главной сложностью было разграничить транспортный слой и бизнес-логику через интерфейсы. Основной канал доставки видео заменили на AJAX, а P2P-слой — на WebRTC.

Результат компиляции — двоичный.wasm-файл и «клеевой код» на JavaScript, взаимодействующий с браузерными API. Это позволило запускать сложную P2P-систему Peers.TV напрямую в браузере без плагинов.

Fastly Terrarium: экспериментальная платформа для WebAssembly-приложений

В 2021 году инженеры Fastly выпустили Terrarium — экспериментальную платформу для запуска WebAssembly-модулей на периферийных устройствах (edge devices), над которой работали несколько лет. Сейчас проект всё ещё в демо-версии.

Terrarium показывает, как можно запускать пользовательский код в изолированных средах с минимальной задержкой. Платформа использует рантайм Lucet, разработанный инженерами Fastly, и поддерживает компиляцию из Rust, C++ и AssemblyScript.

Ключевая особенность подхода — стандарт WASI для системных вызовов, что помогаетпереносить модули между разными средами. Это особенно важно для edge-вычислений, где код должен работать на разнородном оборудовании.

По данным тестирования, время запуска модулей составляет около 50 микросекунд, а потребление памяти измеряется килобайтами на инстанс. Такие показатели достигаются за счёт изоляции на уровне инструкций, а не процессов.

Хотя Terrarium не стал коммерческим продуктом, его наработки повлияли на другие решения Fastly. Компания развивает направление WebAssembly-вычислений далее — экосистема постоянно обновляется.

Технические вызовы и ограничения

Несмотря на впечатляющие возможности WebAssembly за пределами браузера, технология сталкивается с объективными сложностями в реальных проектах. Разработчикам приходится решать две задачи одновременно: изолировать код для безопасности и при этом давать доступ к системе. Важно также сохранить кроссплатформенность, но не терять в производительности на конкретных устройствах.

Эти компромиссы особенно заметны в embedded-среде, где каждое решение напрямую влияет на энергопотребление, стоимость и надежность системы.

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

А здесь кроется главное: почему такое решение не было написано ранее? Дело в том, что оно явно затратное по ресурсам, если сравнивать ту же логику, написанную на низком уровне. Сейчас любые устройства стали мощнее, чем ранее, и теперь разница уже не так заметна. Поэтому WASI может широко распространяться, без типичных минусов высокоуровневых абстракций: потребления памяти и энергии сильно выше чем у конкурентов.

Доступ к аппаратным ресурсам

WebAssembly ограничивает прямой доступ к аппаратуре во встроенных системах — это плата за безопасность. Это усложняет работу embedded-разработчикам.

Сообщество WebAssembly уже решает проблемы. Стандарт WASI продолжает развиваться, и в будущем появятся более гибкие способы работы с оборудованием.

Размер файлов и производительность

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

Чтобы уменьшить размер, нужно тщательно удалять неиспользуемый код и подбирать настройки компиляции. Кроме того, передача данных между хост-системой и WebAssembly-модулем обходится дорого.

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Тут имеется ввиду краеугольная проблема WASM модулей — ввод и вывод. Дело в том, что он довольно низкоуровневый, и если в случае с микроконтроллерами они буквально будут говорить на «одном языке» с железом, то более высокоуровневые системы, передающие данные в том же JSON, столкнутся с довольно затратным процессом сериализации данных. Чтение строки с английскими буквами это одно, а текст на разных языках — это уже задачка со звездочкой. Так что в случае LLM надо будет серьезно работать надо протоколом обмена данными.

Инструменты и экосистема

Экосистема WebAssembly вне браузера всё ещё развивается. Поддержка различных языков программирования неравномерна: лучше всего дела обстоят у C/C++ и Rust, с интерпретируемыми языками всё сложнее.

Отладка WebAssembly-модулей ограничена в сравнении с традиционными средствами. Разработчикам часто приходится использовать косвенные методы и работать с преобразованным кодом. Это особенно важно в контексте другой быстрорастущей тенденции — переносить выполнение ИИ-моделей с серверов на сами устройства пользователей (edge computing).

Например, современные компактные LLM, такие как Phi-4-mini-flash, демонстрируют впечатляющую производительность на мобильных чипах ARM, обрабатывая запросы за 90–100 мс прямо на устройстве без облака. Для подобных сценариев WebAssembly с его переносимостью и низким потреблением ресурсов выглядит идеальной средой, если сможет предложить более прямой и эффективный доступ к специфическим возможностям железа.

Будущее WebAssembly вне браузера

Перспективы WebAssembly вне браузера выглядит многообещающим. Стандарт WASI совершенствуется, поддерживая новые системные интерфейсы и возможности. Разработчики получают всё более мощные инструменты для создания и отладки WASM-модулей.

В embedded-сфере WebAssembly может стать стандартом для безопасного выполнения кода на различных устройствах IoT (интернета вещей). Его способность работать на ресурсо-ограниченных устройствах при изоляции делает инструмент привлекательной альтернативой традиционным подходам.

Майлз Боринс, технический директор руководящего комитета Node.js, видит потенциал WebAssembly в решении одной из наибольших проблем фреймворка: «Это способ достичь скорости, близкой к нативной, и повторно использовать код, написанный на других языках (C и C++), сохранять портативность и безопасность».

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Как я понял, под фундаментальными проблемами имеется в виду ограничение на кол-во операций с потоками и файлами в текущий версиях Node.js, что не дает серверам на «ноде» тягаться с Nginx на равных.

Итоги

WebAssembly превращается из узкоспециализированной веб-технологии в универсальную платформу для выполнения кода. Безопасность, переносимость и производительность WebAssembly делают его эффективным решением для серверных и встраиваемых систем.

У WebAssembly всё ещё есть проблемы с доступом к аппаратным ресурсам и большим размерам модулей. Однако инструменты и стандарты активно развиваются — скорее всего, эти ограничения постепенно устранят.

Для разработчиков WebAssembly открывает новые возможности повторного использования кода и создания безопасных, переносимых приложений. Для индустрии в целом — это шаг к более безопасным и эффективным моделям распределения и выполнения кода.

Как отмечает Шон Уайт, директор Mozilla по R&D: «WebAssembly уже меняет способы доставки людям новых видов привлекательного контента. С WASI преимущества WebAssembly получат больше пользователей и больше устройств в разных местах».

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

Мы в Smart Engines занимаемся разработкой интеллектуальных систем для распознавания документов. Мы уже рассказывали вам, как просто и быстро интегрировать наши решения для распознавания паспорта, а также распознавания жестких и гибких форм в Android.

Сегодня речь пойдет про браузерное распознавание. Оно в последние несколько лет пользуется колоссальным спросом со стороны рынка – прежде всего у финтеха. Кроме того, развертывание PWA-приложений понадобится компаниям при интеграции функциональности в новый отечественный мессенджер MAX.

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

Исторический экскурс

Технология WebAssembly (WASM) появилась в 2015 году и два года спустя была реализована во всех основных браузерах. Тогда же ученые Smart Engines начали проводить с WASM первые эксперименты.

Немного похвастаемся: в 2021 году мы первыми в стране представили промышленные технологии для распознавания документов в вебе. Это оказалось очень кстати, поскольку на фоне удаления мобильных приложений из магазинов к интерес к технологиям распознавания QR и банковских карт в браузере вырос.

Банки и финтех стали искать способы, как перенести привычную для пользователя функциональность – платежи по QR, распознавание номера телефона, распознавание банковской карты – из мобильного приложения в веб.

Ответ нашелся быстро – WASM и Smart Engines.

В чем плюсы?

Браузерное распознавание имеет очень много преимуществ. Во-первых, это все преимущества веб приложения:

• Кроссплатформенность;
• Возможность доступа к приложению из любой точки с интернет-соединением
• Мгновенное развертывание и обновление приложения, что позволяет пользователям всегда работать с актуальной версией.

Во-вторых, предусматривает совершенно иной уровень защиты персональных данных. Пользователь не выгружает свои данные на сервер для распознавания, а, напротив, загружает модуль для распознавания изображений с персональными данными себе.

И, в-третьих, позволяет в сжатые сроки реализовать фронтэнд-интеграцию силами web-разработчиков.

Все преимущества браузерного распознавания уже оценили наши партнёры, нацеленные на развитие своих интернет-сервисов. Среди них – Альфа-Банк, Газпромбанк и другие.

Распознавание кодифицированных объектов

Одним из самых востребованных направлений в OCR сейчас является распознавание кодифицированных объектов, таких как баркоды, номера телефонов, банковских карт и прочие машиночитаемые зоны.

В своё время мы выделили распознавание таких объектов в отдельный продукт Smart Code Engine для того, чтобы иметь возможность гибче работать с различными сценариями распознавания, а также иметь возможность пойти дальше в деле оптимизации скорости и размера библиотеки. В результате появился Smart Code Engine 2.0 – продукт получил новый интерфейс и возможность максимально гибко настраивать поведение для получения лучшего качества распознавания.

Библиотека Smart Code Engine написана на С++ и портировалась в веб с помощью инструмента Emscripten. Поскольку вся кодовая база, от низкоуровневых вычисления над изображениями до архитектуры поисковой сети, поддерживается нашим научным отделом, качественное портирование не составляло особых проблем.

Js-интерфейс библиотеки представляет собой практически зеркальный С++ интерфейс и с его помощью распознавание банковской карты реализуется вот так:

Этот код необходимо поместить в веб-воркер, чтобы не нагружать UI поток браузера лишними вычислениями.

Передача изображений в библиотеку осуществляется прямо с чтения пикселей элемента canvas, где вы выводите изображения с камеры устройства или прикрепленного файла PDF.

В процессе работы распознавания у вас есть возможность нарисовать поверх изображения найденные элементы документа за мгновение до распознавания.

Вот как это выглядит на выходе:

Как вы можете заметить, интеграция Smart Code Engine SDK не вызывает сложностей – внедрение происходит практически мгновенно, а скорость распознавания сопоставима с нативными библиотеками.

Эта статья — подробная хроника эволюции программистов: какие языки и технологии они осваивали, как менялись их рабочие места, методы обучения и даже само восприятие профессии. Мы разберем ключевые этапы, от первых веб-гигантов до эпохи совместного программирования с ИИ, и попробуем представить, что ждет нас дальше.

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

Обучение программированию в этот период кардинально отличалось от современных подходов. Онлайн-курсы практически отсутствовали. Основными источниками знаний служили бумажные книги:

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

ORM-технологии еще не получили широкого распространения, поэтому SQL-запросы писали вручную. Многие проекты представляли собой монолитные приложения, где весь код хранился в единой кодовой базе без четкого разделения на модули.

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

Этот кейс хорошо иллюстрирует дух эпохи: отсутствие готовых безопасных решений заставляло программистов изобретать велосипеды. Многие подобные наработки позже легли в основу ORM-библиотек, но тогда они рождались в муках — через пробелы в безопасности и километры самописного кода.

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

Эти проекты заложили основу для бума EdTech в России после 2015 года, доказав, что онлайн-формат может давать актуальные навыки быстрее вузов.

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

В профессиональной среде начал формироваться консенсус о том, что PHP устаревает для сложных коммерческих проектов.

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

За два десятилетия программисты прошли путь от одиночек за CRT-мониторами до участников глобальных распределенных команд. Если в 2005 ключевым навыком было умение написать работающий код, то в 2025 главное — способность эффективно взаимодействовать с ИИ-ассистентами. Однако основы профессии остались неизменными — логическое мышление, способность к абстракции и желание автоматизировать рутинные задачи.

Будущее обещает новые трансформации. К 2030 году нейроинтерфейсы смогут заменить традиционные устройства ввода, а квантовые компьютеры — перевернуть основы криптографии. Но пока актуальными остаются проверенные временем принципы: изучать перспективные технологии (вроде Rust и Mojo), осваивать работу с ИИ и, конечно, совершенствовать главный навык любого программиста — умение быстро и грамотно гуглить.

Ты уже программист, если читаешь это! Больше о кодинге тут.

В рейтинге языков программирования TIOBE Rust занимает 14 место. Для сравнения — в прошлом марте он был на 17 позиции. Вместе с экспертами Solvery Василием Кузенковым, full-stack разработчиком в Web3 стартапе, и Дмитрием Беляевым, Rust developer в Wildberries, разбираемся, как стать разрабом на Расте в 2025 году.

Немного об особенностях

Если вы до этого программировали на ООП языках, то вам, возможно, бросалось в глаза отсутствие привычных классов. Вместо них здесь алгебраические типы данных и трейты для решения expression problem. Их механизм куда больше похож на typeclasses из Haskell, что также будет для вас новой концепцией при построении крупных приложений, и нужно будет перестраивать мышление.

Также когда стартуешь, немного непривычно работать с move-семантикой, RAII, borrow checker’ом и лайф-таймами. Но компилятор сыпет довольно подробными ошибками, которые можно легко поправить, если разобраться.

А еще у Rust очень строгая типизация и очень мощная система типов, а сами типы построены так, чтобы предоставлять некоторые гарантии программисту. Например, ссылки в Rust всегда ссылаются на объект, гарантировано существующий в памяти, а стандартные строки содержат только валидный UTF-8. При этом в подавляющем большинстве случаев тип необязательно указывать явно, компилятор способен выводить типы, анализируя контекст функции целиком. Кроме того, Rust следует идеологии «компилируется, значит, работает». От логических ошибок, конечно, Раст не спасёт, но тем не менее очень большой пласт багов можно отловить на этапе кодинга. Да, это сложно, но лучше помучиться при разработке, чем потом разбираться почему упал прод.

Ещё одна отличительная фишка — абстракции с нулевой стоимостью. Rust позволяет писать высокоуровневый и понятный код, который при этом будет иметь ту же производительность, что и более низкоуровневый оптимизированный вручную вариант.

Хороший пример здесь — итерация по различным коллекциям. Многие языки позволяют использовать итераторы с их абстракциями вроде map или filter. Только такой код, как правило, будет в несколько раз медленнее, чем если то же самое переписать на циклы. Компилятор Rust способен развернуть такой итератор в обычные циклы сам, и производительность будет сравнима, а порой даже лучше, так как программисты часто при написании низкоуровневого кода заставляют процессор делать много лишних вычислений.

Сложно ли переходить на Rust

У Rust достаточно нетривиальная кривая входа, и без понимания некоторых важных принципов сложно написать код, который хотя бы будет компилироваться. Это относится не только к полным новичкам в программировании, но и к людям, которые уже владеют другим языком.

На рынке фактически все вакансии требуют уже какого-то опыта в разработке. И сложность перехода сильно разнится от вашего текущего стека. Для Go-программиста переход будет средне-сложным, а язык, возможно, покажется перегруженным. Для С++ — менее сложным, но язык покажется местами ограничивающим. Я переходил на него с JS/TS’а и столкнулся со множеством низкоуровневых концепций, о которых раньше мог не задумываться. Но если у вас есть опыт в системном программировании — переходить будет в разы проще.

Однако Rust прививает программисту очень много хороших привычек, которые меняют подход к написанию кода и на других языках. Это однозначно хороший выбор в качестве первого языка, но при условии, что у вас есть достаточно времени и терпения на освоение.

В моей практике менторства много успешных кейсов перехода на Rust с самых разных языков, но проще всего он даётся тем, кто раньше писал на современном C++ и уже понимает такие концепции, как move-семантика и RAII. Много привычного здесь обнаружат и те, кто писал на функциональных языках (Haskell или OCaml). Но в целом, для остальных тоже нет никаких проблем, даже если вы совсем новичок.

С чего начать изучать Rust

Вместе со стартом в изучении языка с The Rust Book — бесплатной официальной книгой по Rust’у — стоит углубить свои знания в более низкоуровневых вещах: в чем разница стека и кучи, что такое разметка памяти и адресация в памяти, как работает процессор, подходы и проблемы многопоточного программирования, плюс почитать про операционные системы и сети. Если вы решили осознанно применять Rust, оно вам пригодится.

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

Вот примерный список того, что нужно учить на старте:

• Переменные. Они по умолчанию неизменяемые (let x). Чтобы x стал изменяемым, нужно указать это явно через let mut. Константы (const) и статические переменные (static) вам будут нужны редко, они имеют свои особенности.
• Типы. Стоит разобраться с составными типами, такими как массивы и кортежи, а также с пользовательскими объявляемыми конструкциями struct (тип-произведение) и enum (тип-сумма). Также типы данных в Расте есть стандартные: bool, i32, u64 и прочие числовые, но строки могут удивить, так как их видов сильно больше.
• Match. Нужно понять такую вещь, как pattern-matching, познакомиться с оператором match, а также осознать, что pattern-matching применяется не только в нём, а везде, где возможно объявление переменных.

Таким образом, вы можете сразу проверить что-то и присвоить результат в переменную:

Здесь мы сразу проверили и присвоили:

Тут нам потребовалась дополнительная изменяемая переменная.

Что такое Cargo

Cargo — это консольная утилита, которая устанавливается вместе с компилятором языка. Она служит одновременно для управления зависимостями, сборки проекта и запуска тестов. Плюс для Cargo есть расширения, например, в поставке по умолчанию уже есть форматтер и линтер clippy.

Cargo рассчитан на то, что вы будете запускать его через терминал, самые полезные команды это:

• cargo new — создаёт новый шаблонный проект в указанной папке;
• cargo build — собирает проект;
• cargo run — собирает проект и запускает получившийся исполняемый файл;
• cargo check — dry-run сборки, делает все проверки компилятора, но ничего не собирает, что заметно быстрее полноценной сборки;
• cargo test — собирает проект со всеми тестами и запускает их;
• cargo fmt — форматирует проект в общепринятый стиль кода;
• cargo clippy — запускает линтер, очень полезно, можно подсказать более оптимальные варианты кода, найти некоторые потенциальные логические ошибки;
• cargo install — устанавливает пакет, содержащий исполняемые файлы;
• cargo clean — очищает все артефакты сборки.

Cargo позволяет описать структуру, настройки (профили сборки, описание крейта) и зависимости вашего крейта или даже монорепозитория (с помощью workspace). Кроме непосредственного запуска через терминал, многие вещи могут запускаться через средства интеграции в IDE, такие как rust-analyzer для VSCode.

Как работать с ownership, borrowing и lifetimes?

Для многих новичков системы владения (ownership), заимствования (borrowing) и времен жизни (lifetimes) выливаются в борьбу с компилятором раста. Эти механизмы нужны в первую очередь для безопасности памяти без сборщика мусора. Общее правило владения такое:

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

Когда значение перемещается (передается другой переменной или функции), владение переходит, и исходная переменная становится недействительной.

Для типов, реализующих трейт Copy (например, целые числа, булевы значения), значения копируются автоматически:

Для более сложных типов нужно использовать метод clone(), чтобы создать глубокую копию. В местах программы, где производительность не так важна — использование clone() не возбраняется.

Если же у вас критичный к производительности кусок кода, то вам также понадобится заимствоватние и лайфтаймы.

Заимствование позволяет использовать значение без получения владения через ссылки (& и &mut). Для мутабельных ссылок `&mut` есть дополнительные ограничения: в каждый момент времени может существовать только одна изменяемая ссылка на значение.

Нельзя иметь изменяемую ссылку, если уже есть неизменяемая ссылка на то же значение.

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

Аннотация 'a указывает, что возвращаемая ссылка будет жить как минимум столько же, сколько кратчайшая из входных ссылок.

Общие советы по заимствованию здесь такие:

• Используйте ссылки, когда не нужно владение.
• Возвращайте значения из функций для передачи владения обратно.
• Используйте клонирование для создания новых экземпляров (с пониманием стоимости).
• Используйте типы с трейтом Copy, когда это возможно.
• Еще полезно не забывать о контейнерах. Rc<T> позволяет иметь несколько владельцев одного значения через счетчик ссылок, а RefCell<T> обеспечивает проверку правил заимствования в рантайме.

О структурах, перечислениях, модулях и функциях, замыканиях, итераторах

Структуры (structs) в Rust позволяют создавать пользовательские типы данных, объединяющие связанные значения и выступающие типом произведения.

Перечисления (enum) позволяют определить тип, перечисляя все возможные варианты значений.

Перечисления в Rust являются типами суммы, поскольку значение может быть одним из вариантов:

Тип Shape представляет объединение (сумму) всех возможных вариантов. И к этому есть мощное сопоставление с образцом для работы с ADT:

Модули позволяют организовать код и контролировать видимость элементов. Определяются они через синтаксис mod <name> {} и могут быть вложенны друг в друга:

Также модули могут быть организованы в различных файлах (имя файла в таком случае будет именем модуля):

Импорт модуля осуществляется через ключевое слово use:

Функции в Rust определяются через ключевое слово fn:

Можно делать функции высшего порядка и передавать в них, как обычные, так и анонимные функции:

Еще одним элементом функционального программирования в Rust выступает итератор:

Здесь мы создаем собственный итератор Counter, реализуя стандартный трейт Iterator. Он используется для многих встроенных коллекций, таких как Vec или HashMap. Этот трейт особенно удобен из-за различных функциональных комбинаторов из стандартной библиотеки:

Трейт Iterator предоставляет множество методов адаптеров, таких как enumerate, filter или map, которые возвращают новый итератор. Методы адаптеров ленивые, они не запускают итерацию. Также есть методы исполнители, которые итерируют пока не закончатся значения, например, collect, fold или count.

Большинство коллекций (и ссылки на них) реализуют трейт IntoIterator (способность кастоваться в Iterator). Также IntoIterator автоматически реализуется для любого Iterator (ничего не стоящий каст сам в себя). Цикл for в Rust работает только с объектами, реализующими IntoIterator.

Как обрабатывать ошибки в Rust

В Rust принято разделять ошибки на 2 вида: паники и результаты операций:

• Паники используются для непредвиденных ситуаций и ошибок программиста, например, деление целочисленного типа на 0 или выход за границу массива. И хотя паники можно отловить, стандартное и рекомендуемое поведение при них — программа упадёт, будет напечатан стектрейс.
• Результаты операций выражаются типом Result<T, E>, который является перечислением из двух вариантов — Ok(T) и Err(E). Такой подход гарантирует, что все ошибки строго типизированы, а без обработки ошибки невозможно извлечь результат операции.

Option<T> используется для представления значения, которое может отсутствовать:

Result<T, E> используется для операций, которые могут завершиться ошибкой:

Для удобства проброса ошибок наверх существует оператор ?, который пишется после любого выражения, возвращающего Result, и возвращает Ok вариант. В случае Err варианта будет выход из функции с возвращением ошибки.

Обычно все ошибки описываются в перечислениях, а для уменьшения шаблонного кода используются крейты вроде thiserror.

Про асинхронное программирование

Асинхронное программирование в Rust строится вокруг трейта Future— его реализуют для типов, представляющих значение, которое будет доступно в будущем.

Также в Rust есть синтаксис async/await. Ключевым словом async могут быть отмечены функции и блоки кода — они будут возвращать анонимный тип, реализующий Future. Async-блоки также могут захватывать окружение подобно замыканиям. Внутри async-блоков и функций возможно использовать ключевое слово await на любом выражении, возвращающем Future или IntoFuture (способность кастоваться к Future). В отличие от других языков с подобным синтаксисом, await записывается через точку после выражения, что очень удобно для построения цепочек вычислений.

Для исполнения асинхронного кода необходим рантайм, но стандартная библиотека такого рантайма не предоставляет, поэтому приходится использовать сторонние библиотеки. Самым популярным рантаймом является библиотека tokio.

В асинхронное программирование на Rust я рекомендую приходить уже после углубленного изучения языка, первых пет-проектов и небольшой работы с многопоточным кодом. Хотя синтаксис и общие правила работы с асинхронным кодом покажутся знакомыми тем, кто знает JS или C#, из-за более низкоуровневой природы языка работать с ним немного сложнее.

Что еще должен знать новичок в Rust

Вот примерный список:

• Очень желательно погрузиться в устройство памяти процесса, узнать, что помимо стека и кучи существуют и другие области (например, исполняемый машинный код так же отражён на память, а static-переменные хранятся не в стеке и не в куче, а в своей собственной области). Неплохо было бы и разобраться с тем, что у типов помимо размера есть выравнивание. Что в Rust бывают ZST (zero size type) — типы, размер которых честный 0, и DST (dynamic size type) — типы, размер которых неизвестен во время компиляции.
• Обязательно разобраться, как Rust освобождает память, не используя сборщик мусора. Почитать, что такое RAII. Понять, как работает трейт Drop.
• Избавится от стереотипов о Rust. Rust — не самый сложный язык, как только вы поймёте, как он работает. Плюс платят за Rust, как правило, больше, чем на аналогичных позициях на других языках.
• Оставить свои привычки из других языков (за исключением разве что Haskell/OCaml). Здесь не получится писать, как на C++/Java/Go и т.д. Привыкайте к хорошему и станете лучше, чем были до освоения Rust.

Что изучать, если есть вся база: чек-лист

• Макросы и метапрограммирование
• Unsafe Rust для низкоуровневого контроля
• Интеграция с C/C++ через FFI
• Разработка встраиваемых систем
• WebAssembly
• rustnomicon
• Undefined Behavior
• unsafe-код

Тренды на 2025 год

На Rust’е пишут все. Более полный список можно посмотреть тут: https://github.com/rust-unofficial/awesome-rust

Вот несколько топовых фреймворков и библиотек:

• serde — фреймворк для сериализации/десериализации
• tokio, futures — для асинхронного программирования
• clap — парсер аргументов командной строки
• anyhow, thiserror — удобная работа с ошибками
• chrono — работа с датой и временем
• dashmap — многопоточная hashmap
• bytes — эффективная работа с сырыми байтами
• log, tracing — для логирования
• reqwest — для http запросов
• axum — для http сервера и REST api
• mockall, test-case — упростит написание тестов
• bevy — игры
• clippy — линтер

Новость быстро разлетелась по сообществам, но на деле всё не так однозначно, пишет разработчик Оскар Дудич в рамках Architecture Weekly.

Речь идёт о скорости компиляции, а не исполнения кода. Ваши приложения не станут работать быстрее — только собираться. Это как если бы производитель автомобилей сказал, что «машина стала в 10 раз быстрее», а потом уточнил, что речь о производстве, а не скорости на трассе.

Почему решили переписать и причём тут Go

Компилятор — это CPU-bound задача. Он не ждёт ответа от базы данных и не занимается сетевыми запросами. Он грузит процессор на полную, разбирая дерево типов, анализируя код и генерируя выходной файл.

Node.js с его однопоточной моделью и event loop плохо подходит для таких задач. Он отлично работает в веб-серверах — там важна скорость отклика и работа с I/O, но не тяжёлые вычисления. Компилятор TypeScript вырос, стал сложнее, и старая архитектура начала тормозить.

Go здесь оказался подходящим выбором:

• у него есть легковесные потоки (goroutines);
• параллельное выполнение встроено на уровне языка;
• нет нужды в трюках с worker threads, как в Node.js;
• проще работать с памятью и сложными структурами.

Почему просто не использовать worker threads в Node.js?

Это возможно, и они действительно дают параллельность. Но:

• переписывать старый код с учётом многопоточности — больно;
• обмен данными между потоками в Node.js идёт через сериализацию;
• каждый поток создаёт свой V8-инстанс, что дорого по ресурсам.

Команда решила не латать старое, а начать с чистого листа. И, как показали первые тесты, даже однопоточный Go-компилятор оказался быстрее, чем старый на Node.js.

А что с браузерами и плагинами?

Это пока не ясно. В браузерах Go не работает нативно, и придётся либо компилировать его в WebAssembly, либо сохранить JS-версию для playground'ов. Вопросов больше, чем ответов:

• как сохранить совместимость с TypeScript-плагинами;
• будет ли 100% повторяемость в поведении компилятора;
• изменятся ли ошибки, предупреждения и тонкости типов.

Зачем вообще об этом думать

Это кейс о масштабировании и выборе инструментов. То, что хорошо работало в 2012 году, перестаёт тянуть в 2025-м. Переписывание проекта — не всегда трагедия. Иногда это необходимость, если фундамент начал мешать росту.

Важно не повестись на «10x быстрее». Такие цифры всегда требуют контекста. Но и отрицать ценность изменений не стоит — особенно если вы работаете с большими кодовыми базами и каждый процент ускорения важен.

Видео о проекте уже стало вирусным, набрав более 84 000 просмотров за 14 часов (на момент написания материала).

При этом на его производство ушло около 200 часов, но сам проект занял целый год.

Как это вообще возможно?

Чтобы заставить DOOM работать в TypeScript types, разработчик:

• Реализовал полноценную WASM-виртуальную машину внутри типовой системы TypeScript.
• Воссоздал 116 инструкций WebAssembly, начиная с арифметики и заканчивая динамическим диспетчированием вызовов.
• Управлял памятью и обрабатывал бинарные числа в строковых литералах.

В результате компилятор создавал 20 млн конкретных типов в секунду, из-за чего рендеринг первого кадра DOOM занял 12 дней.

Что в итоге?

• Финальный размер проекта — 177 ТБ (3.5 триллиона строк TypeScript-типов).
• Опубликован полный исходный код WASM-рантайма.
• Отдельного внимания заслуживают реализации сложения, деления и сдвига битов — там видно, сколько боли пришлось пережить разработчику.

Почему это круто?

Этот проект — не просто технический абсурд.

Чтобы реализовать такое, пришлось разобраться не только в TypeScript, но и в WebAssembly, виртуальных машинах, внутреннем устройстве TypeScript-компилятора и архитектуре DOOM.

Если вам казалось, что DOOM запустили на всём, попробуйте повторить это на TypeScript-типах.

Что такое облачные IDE и почему они важны

Облачные IDE (или онлайн-редакторы кода) позволяют работать над проектом прямо из браузера, без сложной локальной настройки окружения. На сервере уже установлены необходимые инструменты (компиляторы, интерпретаторы), можно быстро переключаться между различными стеками технологий. Это удобно, когда нужно:

1. Быстро протестировать идею или прототип,
2. Работать из любого места и с любого устройства,
3. Обучаться программированию (особенно новичкам, которым сложно настраивать среду разработки),
4. Совместно редактировать код в реальном времени.

Для меня облачные IDE — отличный вариант, когда нужно не заморачиваться с локальной установкой инструментов, а сразу перейти к коду. А ещё они выручают, когда я не хочу загружать ноутбук гигантскими IDE, особенно если машина не слишком мощная.

Replit

Replit был одним из первых облачных решений, с которыми я столкнулся. Он ориентирован на скорость старта: заходишь на сайт, создаёшь «репл» (так называются проекты в Replit), выбираешь язык — и готово. Уже предустановлен интерпретатор или компилятор, можно писать и сразу же запускать программу.

Возможности

• Поддержка множества языков: Python, JavaScript, C++, Java, Go, Rust и другие.
• Встроенный чат с искусственным интеллектом (Ghostwriter) для помощи в написании кода.
• Возможность совместной работы: можно дать ссылку коллеге, и он зайдёт в ваш проект, чтобы вместе отлаживать или рефакторить код.
• Хостинг: Replit умеет публиковать веб-приложения «на живом URL» одним нажатием кнопки.

Плюсы

• Очень простая регистрация и моментальный старт.
• Социальные функции: можно смотреть публичные проекты других пользователей, форкать их и учиться.

Минусы

• Не всегда удобен для серьёзных проектов: базовые настройки окружения ограничены, а для расширенных сценариев нужен платный тариф.
• Интерфейс может работать медленнее, если проект становится большим или инсталляция зависимостей тяжёлая.

Где пригодится

• Отличный вариант для новичков, которые хотят учиться программировать без сложной настройки локальной среды.
• Быстрые прототипы, демонстрации кода на собеседованиях или парное программирование.

CodeSandbox

CodeSandbox ориентирован, прежде всего, на фронтенд-разработчиков. Он замечательно подходит для проектов на React, Vue, Angular, Svelte и других библиотечных и фреймворковых решениях.

Возможности

• Автоматическое создание окружения для фронтенд-проектов: нужен React? Выбираем шаблон — и сразу получаем структуру, файлы конфигурации и пакетный менеджер.
• «Live preview» (живая перезагрузка): при каждом изменении в коде страница в правой части обновляется без перезагрузки.
• Интеграция с GitHub: можно подтянуть репозиторий, внести правки в CodeSandbox, а затем запушить изменения обратно.
• Возможность запускать бэкенд-сервер (через Docker-контейнеры) в отдельных sandboxes.

Плюсы

• Удобно для веб-разработки: всё уже настроено (Webpack, Vite или другие сборщики).
• Поддержка TypeScript из коробки.
• Отлично работает совместное редактирование, есть возможность прямого «шеринга» результатов.

Минусы

• Фокус именно на веб-технологиях, так что для языков, не связанных с фронтендом, CodeSandbox не всегда подойдёт.
• Бесплатные sandboxes могут засыпать при простое, что не всегда удобно для постоянного хостинга.

Где пригодится

• Быстрые демки UI-компонентов или обучающие примеры для фронтенда.
• Когда нужно показать коллегам, как работает тот или иной React-хук, без установки Node.js локально.
• Создание небольшого прототипа веб-приложения в режиме реального времени.

GitHub Codespaces

GitHub Codespaces — по сути, облачное продолжение Visual Studio Code. Если у вас есть репозиторий на GitHub, вы можете открыть его в Codespaces и получить преднастроенную среду разработки прямо в браузере. Это решение особенно нравится разработчикам, которые уже привыкли к VS Code.

Возможности

• Полноценная интеграция с GitHub: открываем репозиторий, создаём Codespace, и всё готово к работе.
• Расширения VS Code в облаке: многие привычные плагины можно установить и использовать.
• Поддержка Docker и Dev Containers: можно создавать контейнеры со своим набором инструментов, чтобы каждый член команды имел идентичную среду.
• Возможность «подцепиться» к Codespaces и локальным VS Code, если хочется работать в офлайне или со своим привычным окружением.

Плюсы

• Знакомая среда для тех, кто пользуется VS Code.
• Гибкий вариант конфигурации (Dev Containers), позволяющий упростить онбординг новых сотрудников.
• Нет проблем с зависимостями: всё хранится в контейнере, поэтому переходить между проектами очень удобно.

Минусы

• Требует платного тарифного плана GitHub, если нужен серьёзный объём ресурсов (хотя есть ограниченное бесплатное время).
• Для маленьких проектов может быть избыточен, так как мощь Codespaces раскрывается больше в средних и крупных командах.

Где пригодится

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

JetBrains Fleet

Fleet — новый проект от JetBrains, который позиционируется как «умная и быстрая» IDE нового поколения. Предлагается как облачная среда с возможностью локальной установки. JetBrains известны своими тяжёловесными, но очень функциональными IDE (IDEA, PyCharm, WebStorm и т.д.), а Fleet стремится занять более лёгкую нишу с возможностью работать в облаке.

Возможности

• Режим «смарт-редактирования», когда Fleet по мере необходимости подгружает функции анализа кода.
• Распределённая архитектура: можно разворачивать часть Fleet в локальном окружении, часть — в удалённом, чтобы снизить нагрузку на машину.
• Совместное редактирование кода в реальном времени, причём JetBrains обещают, что это будет «ровно, как в Google Docs, только для кода».

Плюсы

• Потенциально более лёгкая, чем классические JetBrains IDE, работает быстрее на слабом железе.
• Глубокий анализ кода, как и во всех решениях JetBrains, что особенно полезно для больших проектов.

Минусы

• Fleet пока ещё развивается, некоторые функции отсутствуют или реализованы не до конца.
• Менее дружелюбен к новичкам, чем Replit или CodeSandbox, потому что ориентирован скорее на опытных разработчиков.

Где пригодится

• Разработка на языках, где особенно важны рефакторинг и интеллектуальные подсказки: Java, Kotlin, Python и т.д.
• Если нужна более «лёгкая» альтернатива классическим IDE JetBrains, но при этом с возможностью работать удалённо.

StackBlitz

StackBlitz — ещё один «фронтенд-ориентированный» онлайн-редактор, но с упором на выполнение кода прямо в браузере без специальных серверных окружений. Он запускает Node.js-среду в браузере через WebAssembly, благодаря чему проекты могут работать очень быстро и автономно.

Возможности

• Мгновенный запуск Angular, React, Vue, Svelte и т.д., без серверной компоненты.
• Поддержка Node.js-приложений (через WebContainers) прямо в браузере: по сути, локальная VM работает «внутри» вкладки.
• Отличная интеграция с GitHub и возможность деплоя проектов.

Плюсы

• Реально быстрая загрузка и мгновенный старт проектов на популярных фреймворках.
• Почти не зависит от «серверной» стороны, потому что всё работает через WebContainers.
• Хорошо подходит для офлайн-режима (в разумных пределах).

Минусы

• Частично функционал ограничен: если нужны какие-то специфические системные зависимости, WebContainers могут не справиться.
• Не так универсален, как решения уровня GitHub Codespaces. В первую очередь он предназначен для веба.

Где пригодится

• Обучающие примеры фронтенда, демо на конференциях или мастер-классах.
• Когда нужно показать, как работает Angular-компонент или React-хук, а интернет-подключение не самое надёжное.
• Быстрое создание прототипа и проверка идей.

Мой личный опыт и выводы

За 10 лет работы программистом я привык, что «настоящая IDE» должна быть у меня локально, с тщательно настроенными плагинами. Однако чем дальше, тем больше я использую облачные решения. В одних случаях это экономит время на настройке окружения, в других — позволяет быстро работать даже на слабом устройстве, а в третьих — просто удобно для совместной разработки.

• Replit я использую, когда хочу быстро показать фрагмент кода на собеседовании или протестировать идею на маломальном языке, где нет желания ставить компилятор локально.
• CodeSandbox прекрасно подходит для демонстрации и прототипирования фронтенд-проектов. Идеально, если нужно поделиться примером React или Vue-компонента.
• GitHub Codespaces — моё решение для серьёзных проектов, где нужна стабильная облачная среда уровня VS Code, плюс глубокая интеграция с GitHub Actions и репозиториями.
• JetBrains Fleet я «щупаю» как потенциальную легковесную замену IntelliJ IDEA, но с возможностью облачной синхронизации и удалённой мощью серверов JetBrains. Пока рано говорить о полной замене, но направление впечатляет.
• StackBlitz — это «волшебство», когда нужно поднять Node.js в браузере. Очень люблю показывать StackBlitz на воркшопах по фронтенду, потому что всё запускается буквально за секунды.

Какую из этих сред выбрать — зависит от задач и предпочтений. Если вы профессионал, который «сидит в одной IDE 8 часов в день», возможно, вы пока предпочтёте локальные решения. Но всё чаще облачные сервисы дают такую же мощь и удобство, причём сэкономив кучу времени на конфигурации. В любом случае, всем рекомендую попробовать, хотя бы ради эксперимента. Может оказаться, что облачная IDE для некоторых задач станет вашим новым любимым инструментом.

После почти двух лет разработки и закрытого бета-тестирования проект, созданный с целью превзойти существующие решения, такие как iTerm 2, будет выпущен под лицензией MIT.

Разработчик поделился подробностями о целях проекта, особенностях версии 1.0 и планах на будущее.

Цель – лучший эмулятор терминала

Основная идея Ghostty – предоставить пользователям macOS и Linux быструю, функциональную и имеющую нативный интерфейс альтернативу существующим эмуляторам.

Разработчик стремился создать продукт, который не заставлял бы пользователей выбирать между скоростью, функциональностью и нативным внешним видом.

Ghostty 1.0 не ставит целью революционизировать концепцию терминала, а скорее предлагает лучший опыт использования уже существующих возможностей.

Быстрый, функциональный и нативный

Ключевыми характеристиками Ghostty являются скорость, богатая функциональность и нативный интерфейс.

Скорости работы было уделено особое внимание, о чем свидетельствует доклад разработчика на Systems Distributed 2024.

В плане функциональности Ghostty поддерживает больше escape-последовательностей xterm, чем любой другой эмулятор (кроме самого xterm), а также современные стандарты, такие как стилизованные подчеркивания, протокол клавиатуры Kitty и графический протокол.

Интерфейс реализуется за счет использования соответствующих системе GUI-инструментариев: на macOS – нативные инструменты, на Linux – GTK (с libadwaita, если доступно). Благодаря этому Ghostty выглядит и ощущается как родное приложение на обеих платформах.

Версия 1.0 и причины длительного бета-тестирования

Первый публичный релиз Ghostty сразу получит номер версии 1.0, минуя стадию ZeroVer.

Длительное закрытое бета-тестирование, в котором участвовало около 2000 человек, было обусловлено личными обстоятельствами разработчика (рождение ребенка), а также желанием выпустить стабильный и качественный продукт.

Разработчик признает, что такой подход мог создать впечатление эксклюзивности и вызвать критику, но благодарит всех тестеров за их вклад в стабильность Ghostty.

Скачать версию 1.0 можно по ссылке.

Планы на будущее: libghostty и расширение функциональности

В будущем разработчик планирует развивать два основных направления: libghostty и функциональность терминальных приложений.

libghostty – это кроссплатформенная библиотека, лежащая в основе Ghostty, доступная через API на Zig и C. Цель – создать экосистему терминальных приложений, от отдельных программ до встроенных терминалов в редакторах и веб-интерфейсах.

После релиза 1.0 планируется сделать libghostty доступной как отдельную библиотеку и расширить поддержку платформ, включая WebAssembly.

Новинка позволяет запускать Linux-приложения и работать с файлами в полностью функциональной среде без необходимости установки операционной системы на компьютер.

Как работает WebVM 2.0

WebVM 2.0 создан на базе WebAssembly, что позволяет ему использовать мощные возможности браузера для быстрой работы даже с относительно ресурсоемкими Linux-приложениями.

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

WebVM 2.0 поддерживает достаточно широкий спектр утилит и приложений, доступных в Linux, включая компиляторы, редакторы и другие инструменты для разработчиков.

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

Основные возможности и преимущества

Одной из ключевых особенностей WebVM 2.0 является его доступность на любых устройствах, где есть веб-браузер — будь то ноутбук, планшет или даже смартфон.

Это делает платформу полезной для разработчиков, студентов и IT-энтузиастов, которым требуется доступ к Linux-инструментам «на ходу».

Кроме того, WebVM 2.0 не требует сложной установки или настроек, что позволяет запустить окружение буквально в пару кликов. Отличный вариант на случай, когда надо быстро протестировать код или выполнить определенные команды в Linux.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики.

Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

Если мы обратимся к сайту, то сможем увидеть те цели, с которым создавался WebAssembly. Это быстрота/эффективность, безопасность, простая отладка и возможность переноса нативных приложений в веб. Если со скоростью, отладкой и безопасностью более-менее понятно из названия, то на счёт желания проникнуть в веб с первого взгляда — не очень. Но оно обусловлено несколькими факторами. Один из них — простота доставки изменений. Как мы помним, из взаимодействия с нативными программами, нам нужен либо какой-то пакетный менеджер, либо магазин, который будет доставлять обновления нашим клиентам. В случае с вебом, нам достаточно обновить код на наших серверах и наши клиенты при следующем открытии нашего сайта/приложения получат все наши изменения. Ещё одним фактором проникновения в веб является задача кроссплатформенности. У нас есть прекрасные утилиты и приложения, которые можно было бы без переписывания или с минимальными изменениями сделать доступными в наших веб приложениях.

К чему всё это? К тому, что в изначальных целях не стояло и не стоит пункта который бы прямо или косвенно приводил к вытеснению JavaScript. Случайным образом этого тоже не произошло, и дальше я изложу свои мысли почему.

Если речь идёт о сравнении производительности JavaScript и WebAssembly, то в общих случаях она будет сопоставимой, а в частных — действительно можно достичь определенного прироста. Но всё это при условии что не будет использоваться браузерный API, ибо если мы начнём манипулировать DOM деревом, то очень скоро упрёмся в производительность перерисовки DOM элементов.

Помню тот период, когда WebAssembly находился на стадии разработки и почти каждый разработчик, который не имел опыта написания веб приложений говорил “вот появится поддержка моего языка в WebAssembly, и я буду писать интерфейсы, и наконец-то исчезнет этот ваш JavaScript”. На данный момент в продуктивной среде можно использовать C/C++/Rust/Golang и ещё множество языков с разной степенью готовности. Пример.

Как мы видим, языки, готовые для продуктива, имеют высокий порог входа и не могут конкурировать с JavaScript в плане легкости освоения. При этом разработчики C/C++/etc не спешат переходить в frontend разработчики. Энтузиасты ведущие разработку на других языках и ранее (до появления WebAssembly) имели возможность писать код на своём любимом языке вместо JavaScript, взгляните на https://brython.info/. Даже мне удалось повстречать самобытный генератор JavaScript кода из Python кода. Но таких энтузиастов единицы: они не закрывают потребность рынка, а надёжность таких решений вызывает сомнения. Часть этих ребят могла бы перейти на WebAssembly и развивать компилятор под свой язык, но это не составляет конкуренции JavaScript.

Думаю, никому из вас не хотелось бы попасть на проект, на котором используется вот такое непопулярное решение, пусть и на любимом языке программирования. Хотя…

На сегодняшний день, вокруг JavaScript выросла большая экосистема. У нас есть всё что нужно для разработки: пакетные менеджеры, фреймворки, библиотеки компонентов, различные инструменты. В троицу frontend фреймворков по сей день не может попасть ни один другой фреймворк. Да, инструменты для WebAssembly тоже развивались, появились фреймворки работающие с DOM, но вы, как и я, наверняка о них ничего не слышали. Мы смеёмся над frontend фреймворками и библиотеками, которые десятками появляются каждый день, и тут же умирают. Пока писал этот текст и искал фреймворки для написания веб приложений с компиляцией в WebAssembly повстречал немало ссылок, которые ведут на нерабочие сайты. В целом, всё это не выглядит живым и перспективным, посмотрите пример кода этого фреймворка.

С браузером и frontend разработкой всё стало немного понятнее, но у нас же есть ещё серверная среда исполнения — Node.js. Но и там возможность писать кастомные модули, расширяя возможности самой Node.js, или переносить сложные вычисления в реализацию на языке более низкого уровня, была давно, и многие использовали в случае необходимости.

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

На мой взгляд, самым лучшим назначением для WebAssembly является возможность кросплатформенного переноса. Хорошим примером будет Figma. AutoCAD презентовал, что они смогли перенести 30-летнюю кодовую базу в веб благодаря WebAssembly.

Исходя из всего вышеизложенного, достаточно просто ответить на вопрос “Почему WebAssembly не заменил JavaScript или не стал популярнее? ”. Потому что WebAssembly это инструмент для решения узкого круга специализированных задач.

Начнем с того, что WebAssembly, несомненно, имеет своё коммьюнити. Однако мир JavaScript развивался около 30 лет и за это время “оброс”, такими мощными и функциональными фреймворками как, например: Angular, Vue и React. Также JavaScript используется в клиентском коде для приложений на языке PHP – всё это делает JavaScript самым популярным языком программирования в мире.

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

WebAssembly начал свой “путь к успеху” только в июне 2019 года, когда был выпущен Chrome 75 с включенными по умолчанию потоками WebAssembly. Но началом попыток серьёзного использования WebAssembly в мире .NET можно считать 2020-й год, благодаря выходу Blazor WebAssembly 3.2.0, и с тех пор комьюнити, использующее WebAssembly, постоянно растёт.

Так как WebAssembly построены на стековой виртуальной машине, исполняющей инструкции бинарного формата, они позволяет выполнять клиентский код на традиционно “серверных” языках программирования, таких как C, C++, C#, Rust, Go, что позволяет использовать на стороне клиента, в браузере, всю вычислительную и алгоритмическую мощь этих языков.

Это даёт ощутимые преимущества в быстродействии и функциональности клиентских приложений, по сравнению с JavaScript, TypeScript и CoffeeScript. Но так же требует других знаний и умений от прикладного разработчика клиентской части приложения. Именно это, на мой взгляд, тормозит расширение комьюнити WebAssembly, так как требует для написания клиентского кода более дорогих “серверных” программистов, коих и так постоянно не хватает.

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

Ну и какой-нибудь вывод, если он нужен:

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

Есть ряд причин, по которым WebAssembly не набрал популярности в веб-разработке.

1. JavaScript существует уже почти 30 лет и за это время сформировалась огромная экосистема библиотек, инструментов и сообщество разработчиков. WebAssembly, анонсированный в 215 году и выпушенный в свет 2017, все еще играет роль "догоняющего".
2. JavaScript является языком, доступным для изучения и использования широкому кругу веб-разработчиков. WebAssembly требует навыков низкоуровневого программирования на языках C/C++/Rust/Kotlin, что сужает круг потенциальных разработчиков.
   
3. WebAssembly был задуман в первую очередь для обеспечения высокой производительности для ресурсоемких задач (игры, компьютерное зрение, криптография и т.д.). Для большинства веб-приложений JavaScript/TypeScript вполне достаточны.
   
4. Согласно опросам StackOverflow за 2019 год, JavaScript используется 67.8% разработчиков, TypeScript - 21.2%, в то время как WebAssembly - всего 1.2%. К 2023 году JavaScript опустился до 63.6%, TypeScript вырос в популярности до 38.9%, а WebAssembly совсем пропал из списка популярных технологий.
   

Тем не менее, WebAssembly имеет популярность, особенно в областях, где требуется высокая производительность:

1. Игры и мультимедиа.
2. Научные вычисления, машинное обучение (TensorFlow.js, Lingon.js).
   
3. Криптография (Bitcoin, Ethereum).
   
4. Компьютерная графика, CAD, 3D-моделирование.
   

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

Основная причина, на мой взгляд почему webassembly не особо сильно распространен - необходимость изучать дополнительные языки программирования + связывание данных (из js в webassembly и наоборот) происходят не настолько удобно как этого хотелось бы рядовому разработчику, особенно это касается C++.

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

В проде моего кода с webassembly нет, но для себя пробовал делать с c++ и rust (последний на мой взгляд гораздо более удобный).

У команды в ГК Альфа-Лизинг есть небольшой опыт использования WASM, недавно протестировали пару внутренних утилит на Blazor (WASM от Microsoft), чтобы ознакомиться с технологией и оценить ее перспективы и применимость для задач. Этим занимались backend-разработчики, которые отметили ряд преимуществ: разработка на привычном C#, небольшой объем кода, эффективный отлов ошибок на этапе компиляции.

Однако выявились и некоторые минусы. Во-первых, достаточно сырая библиотека Blazor, непонятны перспективы ее поддержки и развития как со стороны Microsoft (Silverlight когда-то тоже выглядел перспективным), так и со стороны разработчиков браузеров.

Во-вторых, объем сборки WASM в несколько раз превышает размер JS-бандла. 0.8 мегабайт на Angular vs 4 мегабайта на Blazor. При этом убедительных аргументов в пользу webassembly с точки зрения бизнеса не найдено. JS уже привычен, понятен и удовлетворяет всем нашим требованиям. Как правило в b2b frontend не на сколько ресурсоемкий, чтобы раскрыть возможные преимущества WebAssembly в производительности.

Лично у меня есть еще одно опасение. Эволюция процесса разработки ПО привела к усилению специализации. Те, кому ближе интерфейсы переключились на разработку фронта, а те, кому ближе базы и API - ушли в бэкенд. WASM в этом смысле толкает нас назад.

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

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики.

Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

Что такое WebAssembly?

Если коротко, WebAssembly (Wasm) — это новый формат инструкций, который можно исполнять в браузере так же, как JavaScript.

Огромное значение имеет то, что вы можете получить код на WebAssembly путём компиляции исходников на C/C++, Rust, Go и многих других языках. В Wasm используется статическая типизация и плоская модель памяти, а сам код хранится в компактном бинарном формате. Из-за этого код выполняется достаточно быстро, почти так же быстро, как если бы вы запустили приложение из командной строки.

Возможность использования уже готовых и известных инструментов и библиотек для веб-приложений и значительный прирост производительности по сравнению с JS делают Wasm очень привлекательным для веб-разработки.

В каких областях используют Wasm?

WebAssembly применяют для разработки приложений из самых разных областей. Он используется как в играх (например Doom 3), так и для портирования известных десктопных приложений (например Autocad или Figma). Даже если вам не нужно веб-приложение, Wasm можно использовать как эффективный и гибкий инструмент для serverless вычислений.

В этой статье будет рассмотрен опыт использования Wasm для ускорения веб-инструмента анализа данных. Мы возьмём уже существующий инструмент на C, скомпилируем его в WebAssembly и используем для замены медленных участков JS.

Что за приложение для анализа данных?

Приложение, о котором пойдёт речь, — fastq.bio. Это интерактивный браузерный инструмент, который показывает учёным, насколько качественные данные секвенирования ДНК были ими получены. Секвенирование — это процесс, при котором считываются «буквы» (точнее, нуклеотиды) образца ДНК.

Мы не будем вдаваться в подробности вычислений, но в общих чертах эта инфографика даёт учёным наглядное представление о том, насколько хорошо прошло секвенирование и есть ли проблемы с качеством данных.

Конечно, есть множество десктопных инструментов, которые позволяют сгенерировать подобные отчёты. Цель fastq.bio — дать интерактивное представление качества данных прямо в бразуере. Это особенно полезно для учёных, которые не очень хорошо владеют командной строкой.

Входные данные для приложения поставляются в виде обычного текстового файла. Он генерируется инструментами, используемыми для секвенирования, и содержит список последовательностей ДНК и оценку качества для каждого нуклеотида в последовательности. Формат файла называется .FASTQ, отсюда и название приложения.

Как это было реализовано с помощью JS?

В изначальной версии fastq.bio пользователь начинал с выбора FASTQ-файла на своём компьютере. Используя объект File, приложение считывало небольшой фрагмент данных начиная со случайной позиции (с помощью API FileReader). Обрабатывая этот фрагмент данных, JavaScript выполнял несложные строковые операции и считал нужные показатели. Один из таких показателей — количество нуклеотидов A, C, G и T на каждой из позиций фрагмента ДНК.

Как только все необходимые показатели посчитаны, они отображаются в инфографике с помощью Plotly.js, а приложение переходит к следующему фрагменту файла. Файл разделяется на фрагменты для улучшения UX: обработка файла целиком занимает очень значительное время, так как FASTQ-файлы обычно весят сотни гигабайт. По опыту можно сказать, что оптимальный размер фрагмента — от 0,5 до 1 Мбайт — при таком объёме приложение будет обновлять инфографику достаточно плавно и у пользователя не будет возникать дискомфорта. Однако при выборе размера стоит учитывать, насколько сложные вычисления производит именно ваше приложение.

Архитектура приложения на JavaScript была достаточно прямолинейна:

А как получится на WebAssembly?

Чтобы понять, можно ли использовать Wasm для оптимизации этого приложения, команда стала искать готовые решения для построения QC-инфографики (quality control, контроль качества) FASTQ-файлов. Искать нужно было инструменты, написанные на C, C++ или Rust, чтобы их можно было лёгким движением руки портировать на WebAssembly. В то же время инструмент должен был быть достаточно надёжным и уже проверенным научным сообществом.

После недолгих поисков было решено остановиться на seqtk. Это приложение достаточно часто используют, у него открытый исходный код, и оно написано на C — подходит по всем параметрам.

Прежде чем компилировать его в WebAssembly, посмотрим, как мы бы компилировали seqtk для использования на десктопе. Согласно Makefile, вот параметры gcc, которые нам нужны:

Чтобы скомпилировать seqtk в WebAssembly, нам необходим Emscripten. Он предоставляет замены существующим инструментам сборки, чтобы работать с WebAssmebly было проще. Если Emscripten у вас не установлен, вы можете воспользоваться образом Docker.

Вы можете также собрать его самостоятельно, но это обычно занимает значительное время.

Внутри контейнера мы можем использовать emcc как прямую замену gcc:

Как вы можете видеть, изменения по сравнению с компиляцией в бинарный файл минимальны:

1. Вместо вывода в бинарный файл мы просим Emscripten сгенерировать файлы .wasm и .js. Последний отвечает за запуск модуля WebAssembly.
2. Для поддержки библиотеки zlib необходимо использовать флаг USE_ZLIB. Эту библиотеку используют настолько часто, что она уже портирована на WebAssembly, и Emscripten просто включит её в наш проект.
3. Мы включаем виртуальную файловую систему Emscrippten. Это POSIX-подобная ФС (исходный код), правда работает она в оперативной памяти внутри браузера и очищается, когда вы обновляете страницу (кроме случаев, когда вы сохраняете состояние в IndexedDB, но это уже тема для отдельной статьи).

Зачем нам виртуальная файловая система? Для ответа на этот вопрос давайте сравним, как мы запускаем seqtk из коммандной строки и как мы запускаем скомпилированный модуль WebAssembly с помощью JS:

Доступ к виртуальной файловой системе очень полезен потому что тогда нам не придётся переписывать seqtk под использование строкового, а не файлового ввода. Мы можем просто отобразить фрагмент данных как файл data.fastq в виртуальной ФС и вызвать main() seqtk на нём.

С использованием seqtk, скомпилированного в WebAssembly, архитектура преобразилась:

Как видно из диаграммы, вместо запуска вычислений в основном потоке браузера мы используем WebWorkers. Это позволяет выполнять вычисления в фоновом потоке, не слишком ухудшая отзывчивость бразузера. Контроллер WebWorker’а запускает Worker и управляет его взаимодействием с основным потоком.

Мы можем попросить Worker’а запустить команду seqtk на файле, который мы только что примонтировали. Когда seqtk закончит выполнение, Worker отошлёт результаты назад в виде Promise. Как только основной поток получит сообщение, он сразу использует его, чтобы обновить инфографику. Как и в реализации через JavaScript, мы обрабатываем файл фрагментами и обновляем картинку на каждой итерации.

Оно того стоит? На WebAssembly получилось быстрее?

Да. Чтобы понять, принесла ли замена JS на Wasm свои плоды, команда сравнила реализации по параметру «количество операций чтения в секунду». Время, которое уходит на генерацию интерактивных графиков, не учитывается, потому что в обоих случаях для этой части используется JS.

Используя решение «из коробки» команда получила прирост производительности в 9 раз:

Это уже довольно неплохой результат. Особенно учитывая, как просто его было достичь (а его очень просто достичь, как только вы поймёте, как работает WebAssembly).

После этого разработчики заметили, что seqtk выводит очень много полезных результатов QC-анализа, но их большая часть не используется в инфографике приложения. После удаления вывода этих параметров результат версии на JS удалось превзойти в 13 раз:

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

Решение нашлось довольно быстро — совместить две эти функции в одну. В результате функция получилась ужасна, но знания C особо не потребовалось. Результаты работы функции пришлось сначала совмещать, а потом дополнительно обрабатывать, чтобы разделить назад. Однако это того стоило и позволило увеличить производительность в 20 раз по сравнению с результатом JS.

И что, подобного выигрыша получится достичь всегда?

Конечно нет. Двадцатикратного прироста производительности от простой замены JS на Wasm ожидать не стоит. Вы можете получить ускорение в 2 раза или на 20 %… На самом деле, ваше приложение может наоборот замедлиться, если вы будете загружать большие файлы в память или если ваш код будет требовать большого числа взаимодействий между WebAssembly и JavaScript.

Заключение

Мы увидели, что замена медленного JS-кода на вызовы предкомпилированного Wasm может привести к значительному улучшению производительности. Когда код, необходимый для вычислений, уже написан на C, из этого можно извлечь огромную выгоду. Однако, как уже было сказано выше, WebAssembly — не всегда правильный инструмент для ваших целей. Используйте его с умом.

Дополнительные ресурсы для изучения

• «Level Up With WebAssembly» — практическое руководство по созданию приложений на WebAssembly.
• Aioli (GitHub) — фреймворк для создания быстрых браузерных инструментов для геномики.
• Исходный код fastq.bio (GitHub) — интерактивный онлайн-инструмент для контроля качества результатов секвенирования ДНК.
• «An Abridged Cartoon Introduction To WebAssembly» — краткое введение в WebAssembly с милыми картинками.

Зачем он нужен?

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

Помимо Mozilla в разработке участвуют представители других проектов: Fastly, npm, Node. Сейчас уже доступно три реализации WASI.

Основные изменения в Qt 5.12

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

Кроме того, в Qt 5.12 доступна вторая превью-версия Qt for WebAssembly. Этот модуль позволяет компилировать Qt-приложения для запуска в любом современном браузере. Команда Qt утверждает, что, несмотря на статус превью, модуль довольно зрелый и функциональный и его можно использовать в работе.

Разработчики довели до стабильной версии ещё два модуля, которые в предыдущих релизах Qt значились как превью:

• Qt Remote Objects — делает обмен данными (IPC) между основными процессами Qt бесшовным, что позволяет раскрывать свойства, сигналы и слоты класса QObject другим процессам, вне зависимости от того, где они запущены.
• Qt WebGL Streaming Plugin — предназначен для потоковой передачи данных UI приложения любому современному браузеру.

В новом релизе Qt QML получил поддержку стандарта ECMAScript 7 для работы с наиболее современной версией JavaScript и упрощения интеграции с JS-библиотеками.

В Qt Quick добавлен тип Item View — TableView, который работает более эффективно по сравнению с предыдущей реализацией, QQC1. Кроме того, появилась поддержка функции предварительной генерации текстур дальних областей, позволяющая создавать глифы, необходимые для отрисовки текста, во время компиляции, чтобы увеличить производительность приложения при его запуске. Pointer Handlers переименованы в Input Handlers и также полностью поддерживаются в Qt Quick — эта функция упрощает создание сложных жестовых взаимодействий с сенсорным экраном.

Остальные нововведения

• Qt Core — добавлен двоичный формат CBOR (Concise Binary Object Representation). Он похож на JSON, но обгоняет его по гибкости и количеству поддерживаемых типов данных. Кроме того, улучшен класс QRegularExpression, что позволило отказаться от старого класса QRegExp.
• Qt Network — добавлена поддержка DTLS (Datagram Transport Layer Security). На macOS и iOS теперь поддерживаются TLS-расширение ALPN и HTTP/2, действующее через бэкенд.
• Qt Gui — появилась поддержка Windows UI Automation, которая унифицирует использование разных инструментов ввода с помощью Windows Pointer Input Messages на Windows 8.
• Qt Location — добавлен обновлённый плагин MapBox и несколько API.
• Qt WebEngine — переписан на основе Chromium 69 и получил поддержку клиентских сертификатов.
• Qt for Automation — получил обновлённые модули KNX и MQTT, которые теперь поддерживают новые версии соответствующих протоколов.

Предыдущая версия фреймворка, Qt 5.11, вышла в мае 2018 года с обычной годовой поддержкой. Она была ориентирована на то, чтобы обеспечить доступность фреймворка на Windows, поэтому его переписали с нуля на основе Microsoft UI Automation.

Новое в Go 1.11

• Как альтернатива GOPATH, реализована экспериментальная концепция модулей со встроенной поддержкой управления версиями и дистрибуции пакетов.
• Добавлена поддержка WebAssembly, позволяющая компилировать программы на Go в wasm-модули со всеми необходимыми компонентами.
• Представлен новый пакет, который предоставляет простой API для поиска и загрузки пакетов c исходным Go-кодом.
• Усовершенствовано представление информации во время отладки, включая информацию о номерах строк и размещении точек останова.
• Добавлена поддержка большего количества функций для встраивания по умолчанию, включая те, что вызывают panic.
• Представлен новый формат экспорта данных пакетов. Предполагается, что для конечных пользователей он будет более прозрачным и понятным, к тому же, он ускоряет сборку больших проектов. В случае проблем его можно выключить на время компиляции.

Полный список изменений доступен на странице Release Notes на сайте проекта Go.

Версия Go 1.10 вышла в феврале 2018 года. Значительных изменений в ней не было, разработчики только улучшили проверку на устаревшие файлы, реализовали автозапуск go vet для выявления критических ошибок перед тестированием и добавили поддержку FreeBSD версии 10.3.

Chrome, Edge, Firefox и Safari объявили о поддержке WebAssembly в ноябре 2017 года, спустя два года работы.

В чем суть проблемы?

Как только WebAssembly получит поддержку тредов с разделяемой памятью, станет возможным создание чрезвычайно точных таймеров на JavaScript, а это приведет к тому, что ограничения для защиты от атак по сторонним каналам перестанут работать. Об этом заявил Джон Бергбом(John Bergbom), специалист по информационной безопасности из Forcepoint.

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

Атаки Meltdown и Spectre проводились через запускаемый в браузере JavaScript-код, использующий внутренние функции браузера вроде SharedArrayBuffer или performance.now(). Обновление WebAssembly позволит проводить подобные атаки с той же эффективностью.

Искусственные границы

Официально доступна только поддержка Chrome на системах Windows и macOS. Однако пользователи отметили, что это ограничение создано искусственно. Новая сборка AutoCAD работает в браузере и под Linux, но для корректного запуска требуется с помощью расширения сменить User Agent на идентификатор Chrome.

Поддержка низкоуровневого байт-кода со временем расширяется. В апреле 2018 года вышла бета-версия Qt для WebAssembly для запуска приложений в браузере, а также началось тестирование онлайн-среды разработки WebAssembly Studio. В начале июня 2018 года Nebulet объявила, что разрабатывает микроядро, способное выполнять модули на WebAssembly с правами нулевого кольца защиты процессора в одном адресном пространстве с ядром.

Производительность

По словам создателя Nebulet, когда используемый для сборки компилятор Cretonne будет готов, модули на WebAssembly смогут обогнать по скорости традиционные приложения для Linux. Это станет возможным за счет снижения накладных расходов на системные вызовы и переключения контекста. Кроме того, помогут «экзотические» оптимизации, которые невозможно реализовать в традиционных операционных системах.

Выпуск

Микроядро находится на начальной стадии разработки и выйдет в свет не ранее осени 2018 года.

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

Как использовать Qt для WebAssembly?

Проект находится в разработке, поэтому его бета-версию можно скачать только в виде исходного пакета из раздела загрузок в аккаунте. В качестве компилятора рекомендуется использовать Emscripten. Также для работы необходимы порты QtBase и QtDeclarative. Инструкция по настройке среды и созданию пакета представлена на официальной wiki-странице.

Финальный вариант порта станет доступен в версии 5.11, релиз которого запланирован на 31 мая 2018 года. После выпуска обновления разработчики хотят представить модули для создания графических приложений на Python.

Функциональность

С npm можно устанавливать пакеты для фронтенд-разработки, а так как он не умеет компилировать код на Rust, с этим помогает wasm. Однако создание npm-пакета для дальнейшего распространения — сложная задача, и wasm-pack упрощает работу.

Уильямс рассказала о четырех шагах, которые подготовят код на Rust для публикации пакета в реестре npm:

1. Компиляция в WebAssembly.
2. Запуск wasm-bindgen.
3. Создание package.json.
4. Формирование документации — копирование README.md из Rust-проекта в npm-пакет.

Проект все еще развивается — в планах у разработчиков интеграция с rustdoc, расширение набора инструментов для работы в Rust с Node.js и так далее. Для более близкого знакомства с инструментом создатели подготовили руководство.

Краткий обзор возможностей

В WebAssembly Studio представлены:

• базовая поддержка C/C++ и Rust;
• редактикуемые артефакты компилятора (бинарные модули .wasm можно изменять так же, как текстовые файлы):

• всплывающие подсказки к ключевым словам:

• обширные контекстные меню с популярными действиями:

• Binary Explorer, визуализирующий бинарное представление кода на WebAssembly:

• граф вызовов из отношений вызывающего / вызываемого объекта между функциями, чтобы лучше разобраться в структуре модуля WebAssembly:

Некоторые функции WebAssembly Studio требуют предустановки бэкенд-сервисов (компиляция), но все остальные запускаются прямо из браузера. Binaryen, Wabt, Capstone.js компилируются в код WebAssembly, что упрощает процесс масштабирования приложений и одновременно снижает нагрузку на сервер.

Дальнейшие действия

В ближайшие несколько месяцев разработчики обещают улучшить WebAssembly Studio по следующим направлениям:

• поддержка проектов на C/C++ и Rust вместе с полезными API;
• возможность скачивать и собирать проекты WebAssembly Studio на локальной машине с использованием привычных инструментов;
• пользовательский интерфейс и производительность.

Больше о новом инструменте можно прочитать в официальной документации. Лучше разобраться в технологии WebAssembly поможет наша небольшая инструкция с примером игры «Жизнь».

Что включает в себя проект?

Ключевые возможности wasm-bindgen:

• Импорт из JavaScript в Rust таких функциональностей, как DOM-манипуляции, вывод сообщений на консоль и мониторинг производительности.
• Импорт из Rust в JavaScript классов, функций и т.д.
• Работа со сложными строками, числами и объектами вопреки возможности WebAssembly манипулировать исключительно с низкоуровневыми числовыми типами.

Пример работы проекта опубликован на GitHub. Для более глубокого погружения рекомендуется прочитать документацию.

В мае 2017 года другой программист из Mozilla представил JavaScript-фреймворк Fathom, обучавший браузер Firefox оценивать веб-страницы так же, как человек.

Больше возможностей

Все желающие могут ознакомиться со следующими документами:

• Спецификация ядра, детально раскрывающая особенности версии 1.0 стандарта WebAssembly;
• JS-интерфейс, предоставляющий открытый Javascript API для взаимодействия с WebAssembly;
• Веб-API, описывающий процессы интеграции WebAssembly с более широкой веб-платформой.

WebAssembly — это безопасный портируемый низкоуровневый формат кода для компактного представления и быстрого исполнения. Технология поддерживается большинством современных браузеров. А в Mozilla Firefox уже внедрен двухуровневый компилятор для ускорения обработки машинных кодов.

WebAssembly или wasm – это низкоуровневый формат байт-кода для клиентских скриптов на стороне браузера. Если вы пишете компилятор для языка программирования, один из вариантов — выбрать готовую платформу, например JVM или .NET, и компилировать ваш язык в её байт-код. WebAssembly занимает ту же роль, поэтому при компиляции в WebAssembly вы делаете свою программу доступной для всех платформ, на которых поддерживается wasm, другими словами, для всех браузеров.

На практике WebAssembly реализуется разработчиками браузеров на основе существующего JavaScript-движка. По сути, он предназначен для замены JavaScript как целевого языка. Например, вместо компиляции TypeScript в JavaScript его разработчики теперь могут компилировать свой код в WebAssembly. Иными словами, это не новая виртуальная машина, это новый формат для той же самой виртуальной машины JavaScript, которая включена в каждый браузер. Это позволит использовать существующую инфраструктуру JavaScript без использования самого JavaScript.

Разработка MVP была завершена в марте 2017, и сейчас есть готовые реализации для всех основных браузеров.

Почему это важно?

Во-первых, новый формат WebAssembly обещает значительное увеличение производительности парсинга. Как сказано в FAQ WebAssembly, тип бинарного формата, используемый в WebAssembly, может быть декодирован гораздо быстрее, чем JavaScript может быть пропарсен (эксперименты показывают более чем 20-кратную разницу). На мобильных устройствах большому скомпилированному коду может запросто потребоваться 20–40 секунд только на парсинг, поэтому встроенное декодирование (особенно в сочетании с такими технологиями, как улучшенная по сравнению с gzip потоковая подача для сжатия) имеет решающее значение для обеспечения хорошего пользовательского опыта.

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

Первыми пользователями wasm, вероятно, будут разработчики игровых движков, поскольку они всё время ищут, как бы улучшить производительность. До WebAssembly лучшим, на что они могли надеяться, был asm.js (упрощённый JavaScript, оптимизированный для скорости), который был хорошей технологией, но не очень полезной для многих игр.

В сущности, Autodesk планирует добавить поддержку WebAssembly для своего игрового движка Stingray, а Unity Technologies, создатели игрового движка Unity, начали экспериментировать с WebAssembly ещё в 2015 году. Разработчики Rust также работают над поддержкой WebAssembly для запуска кода Rust в вебе.

Прим.перев. На самом деле, Rust уже умеет компилировать в wasm напрямую, без Emscipten. Кроме того, с момента написания статьи произошли изменения: Autodesk сообщила о прекращении разработки и продажи Stingray.

Зачем это вам

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

Конечно, вы можете использовать лучшие версии JavaScript, такие как TypeScript или даже новые языки вроде Kotlin. Но, в конце концов, все они должны быть скомпилированы в JavaScript. В свою очередь это создало проблемы для разработчиков языка JavaScript, которые должны поддерживать практически все возможные сценарии и все стили программирования. WebAssembly изменит это и позволит всем сосредоточиться на том, что у них получается лучше всего.

Это ещё не всё: WebAssembly можно будет переносить на другие платформы. Это означает, что, если вы пишете программное обеспечение на языке, который компилируется в WebAssembly, вы сможете запустить его на .NET. Тот факт, что wasm позволяет повторно использовать уже существующую инфраструктуру JavaScript в вебе, означает, что вы уже можете использовать его для разработки.

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

Например, вы можете создать компилятор WebAssembly для DSL, который вы используете внутри вашей компании, и запустить его в сети на стороне клиента без использования настраиваемых плагинов, таких как Oracle Java Plug-in или Adobe Flash.

Как это работает

Основополагающий принцип WebAssembly — хорошая интеграция с существующим миром JavaScript, от технических характеристик, таких как совместимость и общие политики безопасности, до интеграции инструментов, таких как поддержка функции View Source браузеров.

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

Однако инструменты, вероятно, покажут нечто более похожее на это (пример из документации):

Если вас интересует, почему в качестве примера используется C++, то это из-за того, что целью начального выпуска (MVP) WebAssembly была поддержка C/C++. Поддержка других языков будет позже; в данный момент они находятся в разработке. Этот выбор был сделан по нескольким техническим и практическим причинам:

• MVP WebAssembly не поддерживает сборку мусора (в разработке);
• Реализация компилятора C/C++ в WebAssembly может полагаться на проверенные временем инструменты вроде LLVM (один из наиболее используемых наборов инструментов для компилятора).

Разработчики WebAssembly используют LLVM для сокращения объёма работы, необходимой для получения рабочего продукта. Кроме того, это позволило им легко интегрироваться с другими инструментами, которые работают с LLVM, такими как Emscripten.

Наличие MVP даёт обычным разработчикам возможность тестировать и использовать WebAssebmly, что позволяет соответственно его улучшать.

Инструменты WebAssembly

На данный момент официальные инструменты WebAssembly могут компилировать только C/C++ в WebAssembly, хотя другие разработчики уже начали работу по добавлению поддержки других языков и платформ (ранее мы упоминали .NET и Rust). Однако даже с помощью официальных инструментов вы уже можете использовать его для веб-разработки двумя способами:

• Записывать WebAssembly в текстовом формате и преобразовывать его в двоичный файл с использованием предоставленных инструментов;
• Использовать сторонний инструмент, основанный на этих инструментах.

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

WABT включает в себя инструменты для разработки и/или использования в инструментах, предназначенных для работы с WebAssembly:

• Он отлично поддерживает спецификацию формата;
• Он может конвертировать в текстовый формат и из него;
• Он включает в себя интерпретатор.

Иными словами, он обеспечивает чистый и лёгкий доступ к данным в формате WebAssembly, чтобы вы могли с ними работать.

С другой стороны, Binaryen — это мощный набор инструментов, предназначенный для использования в инфраструктуре компилятора:

• Он может работать с кодом WebAssembly или графом потока управления, предназначенным для компиляторов;
• Он оптимизирует код многими способами, с использованием как стандартных техник оптимизации, так и специально рассчитанных на WebAssembly;
• Он может компилировать из и в asm.js, Rust MIR (промежуточный язык для Rust) и LLVM.

Таким образом, этот набор инструментов готов к интеграции в ваш бэкенд.

По сути, оба позволяют создавать инструменты, которые управляют WebAssembly, но WABT предназначен для инструментов, которые используются во время разработки (например, статический анализ), в то время как Binaryen предназначен для поддержки WebAssembly в компиляторах.

Эти инструменты отлично подходят для тех, кто разрабатывает инструменты и продукты, связанные с компилятором: они предоставляют как инструменты для разработки, так и готовые к использованию в продакшене. Однако они не идеальны для обычных разработчиков, поэтому для них есть более простой способ.

Если вам нужно создать такие инструменты, есть ещё и второй вариант — написать всё с нуля. Этот вариант подойдёт, если вам нужен собственный компилятор или интерпретатор для вашего собственного языка, нужна лучшая производительность или лёгкий инструмент. В этом деле вам может помочь библиотека WasmCompilerKit. Это Kotlin-библиотека, которую вы можете использовать для загрузки WASM-файлов, их изменения и создания. Учитывая то, что она написана на Kotlin, вы можете использовать её также с Java и Scala.

Использование WebAssembly

Если вы просто разработчик, заинтересованный в использовании WebAssembly, то для знакомства с ним вы можете использовать Emscripten (SDK). Emscripten — это набор инструментов, который уже используется для компиляции C/C++ в asm.js. С Emscripten вам будет легче использовать ранее упомянутый Binaryen и интегрировать его со своим собственным набором инструментов.

После установки Emscripten или его компиляции из исходного кода необходимо установить binaryen:

Затем для того, чтобы активировать среду для компиляции и проверить, что установлены правильные пути и переменные, нужно использовать следующие команды:

Наконец, вы можете писать ваш код:

И затем скомпилировать в WebAssembly и увидеть результат в браузере:

Первая команда создаст три файла: модуль WASM, HTML-файл, который показывает код в действии, и JS-файл, который запускает модуль и отвечает за всё, что нужно для его запуска. Параметр WASM=1 говорит Emscripten, что мы хотим сгенерировать модуль WASM вместо asm.js-файла.

Вы также можете вывести свой код в настраиваемый шаблон, используя флаг --shell-file. Emscripten SDK содержит базовый шаблон в этом месте: (папка с esmdk)/emscripten/incoming/src/shell_minimal.html. Скопируйте этот файл в свой проект и адаптируйте его под свои нужды (например, добавьте остальную часть вашего JS-кода).

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

Конечная цель состоит в том, чтобы подключать модуль WebAssembly так же легко, как подключается код JavaScript, с помощью HTML-тега <script type = "module">, но это ещё только впереди.

Взаимодействие между C и JavaScript

Взаимодействие между C и JavaScript — проблема для Emscripten. Первое, что вам нужно сделать — это подключить заголовочный файл emscripten:

Самый простой способ вызвать JavaScript — использовать функцию emscripten_run_script:

Вызвать C-функцию из JavaScript немного сложнее. Во-первых, вы должны сделать её доступной из кода C/C++, потому что по умолчанию Emscripten делает недоступными все функции C, кроме основной (main). Необходимо добавить модификатор EMSCRIPTEN_KEEP_ALIVE ко всем функциям, которые вы хотите использовать в JavaScript:

Если вы пишете на C++, не забудьте поместить любую функцию, которую вы хотите сделать доступной, внутри блока extern "C", чтобы C++ не задекорировал имя функции (это то, что делает C++, а не баг WebAssembly или Emscripten).

Во-вторых, вам необходимо скомпилировать модуль WebAssembly с параметром NO_EXIT_RUNTIME, чтобы избежать остановки среды выполнения при выходе из основной функции, что сделало бы невозможным вызов кода C из JavaScript:

В-третьих, вы не можете напрямую вызвать свою C-функцию, поэтому вы должны использовать следующий синтаксис:

Есть три типа на выбор: number, string и array.

Если вам нужно использовать функцию в JS-коде несколько раз, вы можете обернуть её с помощью функции cwrap:

Вы можете легко проверить, как это работает, в консоли:

Подводим итоги

Это было короткое введение в WebAssembly: что это такое, почему это важно и как вы можете это использовать. WebAssembly станет отличной платформой для дальнейшей эволюции веба: это сделает веб-разработку проще и эффективней.

Его разработка поддерживается людьми из Mozilla, Microsoft, Google и Apple. Внимание к WebAssembly — ещё одно доказательство его важности.

Вы можете использовать WebAssembly уже сегодня и посмотреть подробную документацию на сайте MDN. Если вас интересует более подробная информация о формате, вы можете прочитать её на официальном сайте. Вы также можете посмотреть документацию Emscripten, чтобы понять детали, связанные с взаимодействием между JavaScript и C/C++.

Один из инженеров компании разработал способ сократить время запуска asm.js в браузере с помощью технологии параллелизма. «Так как для WebAssembly используется тот же обработчик, что и для asm.js, браузер будет обрабатывать быстрее и его», — сообщает автор технологии Бенджамин Бувье.

Распараллеливание состоит из разбиения последовательной программы на более мелкие независимые задачи и их запуска на разных ядрах процессора. Принцип технологии, используемой в Firefox, заключается в том, чтобы убрать из главного потока работу виртуальной машины для выполнения asm.js, а также удаление и генерацию кода. Семантика asm.js и wasm схожа, то есть можно просто кодировать wasm опкодами WebAssembly вместе с некоторыми специфическими для asm.js.

Хотя компиляция и ускорена, в мобильных приложениях она все равно может сильно тормозить выполнения кода, так как парсинг — все еще слабое место, а в работе asm.js он занимает важную роль. Парсинг WebAssembly же происходит на порядок быстрее.

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