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

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

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

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

Нейросети с нами надолго. Даже если вдруг исчезнут OpenAI, Anthopic, Z.ai и прочие, мой личный Qwen 3.8 27B никуда не денется. Вопрос - a что с этим делать? Как разрабатывать софт в новую эпоху?

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

Есть такой университетский предмет, который все давненько подзабыли (а люди с ИТ-курсов его и в глаза не видели): "методология разработки программного обеспечения". Разработка хорошего ПО - это всегда вопрос методологии. Это и общие принципы архитектуры, и дисциплина работы, и возможность передать работу соседу, разделить между несколькими людьми, признать нечто готовым или не готовым. Без методологии разработка стремительно теряет управляемость.

Как сейчас.

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

По просьбам трудящихся, пишу о внутреннем устройстве WebAssembly.

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

В итоге, наш технобордель выглядит так:

• Интерпретатор
• Интерфейс к хосту
• Стек
• Хранилище кода
• Память
• Таблица

Займёмся делом!

Представлять WebAssembly не нужно — поддержка уже есть в современных браузерах. Но технология годится не только для них.

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

Далее — проверка концепции на прочность, инструментарий и первый скриптовый модуль.