WebAssembly *

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

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

Проблема встаёт в момент, когда человек узнаёт, сколько в реальности нужно собрать, чтобы получить готовый sysroot для, например, QT: объём работы для подготовки сборочной площадки убивает всю выгоду от идеи. Но что если этой работы делать просто… не нужно.

P.S. Да, это Doom в браузере. Опять. А ещё там есть HoMM2. Ссылка на playground в конце статьи, там, в браузере, можно его запустить, и собрать на свой десктоп. И посмотреть другие примеры.

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

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

С 17 по 21 августа мы проводим Неделю тестирования Flutter Web с WebAssembly ! В течение недели инженеры Dart и Flutter будут в режиме реального времени обрабатывать поступающие запросы, чтобы помочь в миграции, а наша команда по связям с разработчиками будет делиться вашими успехами в каналах сообщества.

А помните, был такой проект "Кронос" на закате "союза", на заре "перестройки"? Профессиональная 32-битная графическая рабочая станция на собственном железе и собственной ОС и собственной инженерной школой. Вроде был Кронос, а вроде и не был его, сколько с тех пор воды утекло.

В октябре 2023 года я рассказывал на Хабре о WUI — небольшой UI-библиотеке на C++, которую начал делать для своего приложения. Тогда она работала на Windows и Linux, а macOS оставалась в списке задач.

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

Тот же Rust‑код, что рисует топологию на десктопе, собирается в wasm и рисует в <canvas> через WebGPU. Сайт при этом не знает про GPU: кликнул на нарушение в списке, камера уехала на место, маркер показал дефект. Ниже как это устроено, где «просто пересобрали» было бы враньём, и какие ловушки сидят не в Rust, а в вебе.

Задача

У нас десктопный инструмент для топологии интегральных схем, layout в формате GDSII (и OASIS). Файл описывает геометрию кристалла: иерархия ячеек, на листьях прямоугольники и полигоны по слоям (металл, поликремний, диффузия). Координаты целые, в DBU, единицах базы данных; в микрометры переводим уже при развороте сцены. Реальный проект: сотни мегабайт на диске, миллионы фигур после разворачивания иерархии.

Рядом выросла веб‑платформа с результатами анализа этих дизайнов. Захотелось показать сам layout в браузере, в том же UI: клик по нарушению в списке открывает его место на топологии. В десктопных пакетах это называют RVE, results viewing environment. Нам нужна была такая навигация без второго рендер‑движка.

Что отсекли сразу

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

Canvas2D или SVG на JS. На миллионах прямоугольников не работает. И это был бы второй движок.

Отдельный JS/TS‑парсер и рендер. Формат один, интерпретации через полгода две. Для GDS это особенно опасно: иерархия, зеркала, массивы ссылок.

Остался вариант, который мы и сделали: тот же Rust, цель wasm32-unknown-unknown, картинка в <canvas> через WebGPU.

Каждый год на новогодних каникулах у меня просыпается ностальгия, хочется перепройти что‑то из детства, типа «Harry Potter and the Philosopher’s Stone» от KnowWonder. И если с консольными играми всё просто (эмуляторы типа DuckStation или PCSX2 работают идеально), то с PC‑играми 32-битной эры всё сложно, особенно на Mac. Часто пока ты добьешься запуска игры, уже пропадает всякое желание ее проходить.

В этот раз я решил проблему радикально: написал свою «Windows». В браузере. На TypeScript.

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

В прошлой статье я рассказывал, как мы делаем онлайн IDE для .NET — дизайн, компиляция и запуск приложений происходят прямо в браузере, без сервера. Проект живёт по адресу xaml.io. С тех пор мы много чего добавили, и в какой-то момент у нас стало получаться загружать в IDE довольно крупные .NET проекты — десятки XAML, сотни C# файлов, несколько референсных проектов и пакетов NuGet.

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

Открыли как-то в IDE один реальный проект (FamilyShow — классическое демонстрационное WPF-приложение), поправили одну строку в .cs и 84 секунды наблюдали за анимацией прогресса. С таким UX никакой интерактивный дизайн невозможен.

Сейчас та же правка занимает 5 секунд, а правка XAML-разметки на типичной странице — меньше секунды. В этой статье — как мы к этому пришли, и какие сюрпризы нам приготовили по дороге Roslyn, OpenSilver, WASM и наш собственный код.

В статье расскажу о PWA‑бенчмарке, который основан на задаче N тел. Физический движок написан на Rust/WebAssembly, визуализация через Three.js, и результаты запусков сохраняются в Supabase. Тут присутствует разбор архитектуры, сравнение алгоритмов расчета — прямой и Barnes‑Hut, а также тут расписаны проблемы, связанные с измерением производительности в браузере.

Конвертация медиа. Люди решают эту задачу десятки раз в неделю. Видео с дрона нужно перевести в MP4 для мессенджера, HEIC с айфона в JPEG для сайта, аудиозапись интервью обрезать и сжать. Обычно это выглядит так: человек открывает один из сотен онлайн-конвертеров, загружает туда полугигабайтный файл, ждёт, пока он доползёт до сервера, потом ждёт очереди, потом скачивает обратно. Параллельно его файлы лежат на чужом сервере, о чём мало кто задумывается (а зря, если речь про корпоративный договор или личное видео).

Мы решили проверить, можно ли полностью убрать из этой схемы сервер. Чтобы конвертация происходила целиком в браузере, на устройстве пользователя. Без загрузок, без очередей, без серверных затрат. Так появился BrowsersKit: набор инструментов (медиа-конвертер, PDF, математика, Python-песочница), работающих на клиенте. Дальше расскажу, как это устроено внутри, какие грабли нас поджидали и как мы с ними справились.

WebAssembly появился для браузерных задач как способ исполнять тяжелый код быстрее, чем это делает JavaScript. Но за последние годы он начал выходить далеко (иногда буквально далеко) за пределы вкладки браузера: серверы, edge-вычисления, плагины, песочницы. Появились рантаймы Wasmtime, WasmEdge, Wasmer, которые исполняют WASM-модули\компоненты прямо на ОС. Звучит красиво - собрал один бинарь, а запускаешь где угодно, да еще и в максимальной изоляции.

Но есть интересное наблюдение. Существуют проекты, которые строили свои виртуальные машины на WASM, но отказались от него. Самый заметный пример - это Polkadot. Они спроектировали собственную PolkaVM на базе набора инструкций RISC-V и переключили исполнительный слой смарт-контрактов на нее (при этом сам runtime Polkadot по-прежнему компилируется в WASM). Если WASM настолько хорош, как заявляется, то почему для нового движка выбрали не его, а регистровую машину?

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

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

Я не начинал с идеи написать «убийцу JavaScript». Честно говоря, такие заявления обычно только мешают думать.

Сначала была гораздо более скромная мысль: мне нравится Go, мне нравится его простота, типизация и ощущение предсказуемого инструмента. Но когда дело доходит до интерактивного веб‑интерфейса, почти неизбежно оказываешься в другой вселенной: JavaScript, Node.js, сборщики, плагины, отдельная модель компонентов, отдельная экосистема.

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

Так появился мой небольшой экспериментальный проект GoFrame. Сейчас это не готовый фреймворк для продакшена, а исследование в сторону Go‑first подхода для браузера через WebAssembly: маленький рантайм, JSX‑подобная разметка .gox, компиляция этой разметки в обычный Go‑код и утилита goxc, которая способна сгенерировать, собрать и упаковать приложение. В README проекта это прямо описано как экспериментальный Go‑first фреймворк и набор инструментов для интерактивных браузерных приложений на WebAssembly; там же честно указано, что проект не заявляет готовность к продакшену, стабильный API 1.0, SSR, гидратацию, серверные API, форматтер или LSP.

В этой статье я не хочу пересказывать ридми. Интереснее другое: как маленькая идея «а что если сделать JSX для Go?» довольно быстро потянула за собой компилятор, компонентную идентичность, состояния, эффекты, маршрутизацию, проверки в браузере и даже бюджет размера WebAssembly‑бандла.

Решил я поиграть на выходных в Carmageddon. Но вот незадача!- Заводить всё это в эмуляторе DosBox нет никакого желания (он стоит у меня для других целей, ну вы понимаете))- То что мы с Сашей Гурьяновым делали на DosZone у меня тормозит, так как не вывозит мой старенький процессор. Пора уже собрать комп для нашей ДОС Зоны))- Ремейки типа Carmageddo: Max Damage и Reincarnation полная фигня. Куплено в стиме и полно разочарования

Что же делать? Будем сами портировать в браузер! Всё как мы любим. Для эксперимента и развлечения ради!

Обзор асинхронности WASM с выходом WASI 0.3

WASM уже вышел за пределы браузеров и выглядит как перспективная технология для серверной разработки. Однако в вопросе серверного компьюта рано или поздно встает вопрос асинхронной обработки I/O-bound нагрузки. В данной статье попробуем разобраться, что как отвечает экосистема WASM на данный вызов. Статья особенно актуальна в свете того, что совсем недавно официально представлен WASI 0.3

В общем и целом это практически полностью ИИ порт на создание которого ушло всего 10 минут!Так я решил проверить готова ли самая обычная нейронка портировать с нуля игру в браузер, так сказать под ключ.

Сертификат комплаенса — мёртвая бумага: через два часа хотфикс делает сертифицированный хеш недействительным, и никто не замечает. UVS заменяет «доверьтесь нам» на то, что любой пересчитает сам: deriveTier выводит тир из улик, а не из бейджа. drand + двойной RFC-3161-якорь + WASM-движок, собираемый на лету. Демо живые — попробуй сломать.

Вращения в трёхмерном пространстве встречаются практически в любой задаче компьютерной графики, от игровых движков до WebGL‑приложений.

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

На примере демонстрационного проекта на Rust, WebAssembly и ThreeJS рассматриваю связь между осью вращения, матрицами поворота, комплексными числами и кватернионами, а также показывается, как эти математические конструкции используются для вращения реальной 3D‑модели.

TL;DR. Две нейросетевые задачи — удаление фона (ONNX Runtime Web + модель silueta) и замазывание лиц (MediaPipe Tasks Vision + BlazeFace) — запущены полностью на клиенте: ни один пиксель не уходит на сервер. Ниже — почему «в браузере», какие модели выбраны и почему, как тянуть 43-мегабайтную модель с прогресс-баром, почему лица лучше пикселизировать, чем размывать, и подробный разбор бага, на который я убил вечер: Service Worker, кэширующий .mjs/.wasm, ломает dynamic import() с ошибкой «Failed to fetch dynamically imported module».

Всем привет! Я решил наконец то сам сделать пост на хабре. Обычно о всех моих веб проектах и команды DosZone Team пишет здесь многоуважаемый @denis-19, за что ему огромное спасибо! Ведь нам просто лень или не хватает на это времени. И так! После шутера Blood мне было интересно попробовать также портировать Redneck Rampage как раз на основе того, что я уже сделал. Было ошибочно так думать, потому что RR в отличие от NBlood оказался совершенно на другом движке - RedNukem, и пришлось начинать всё с нуля. Да и сложность повысилась и всё это заняло в два раза больше времени, чуть больше недели.

Мы были двумя 16-летними студентами колледжа, чья программа безнадёжно отставала от индустрии. Пока на парах проходили технологии пятилетней давности, реальный мир уже жил в экосистеме React, Next.js и WebAssembly. Пришлось учиться самим — по вечерам разбирая современный стек и споря об архитектуре. Эта тяга сподвигла нас создавать не абстрактные проекты для портфолио, а реально полезные инструменты, которыми хочется пользоваться каждый день.

Так четыре года назад родился наш проект — 167 утилит и 8 интерактивных песочниц в одном сервисе. Форматтеры, конвертеры, генераторы паролей и UUID, DevOps-конфиги, шпаргалки и песочницы для Python, SQL и Bash. Всё сделали прямо в браузере, без сервера.

Рассказываем как это было.