Асинхронщина - суть js, на том вся его архитектура стоит. Wasm не замена js, а средство для оптимизации узких мест: подразумевается что работать оно должно аналогично вставкам оптимизированного asm кода при классическом программировании. Если же ты хочешь писать ВСЁ на asm, то, очевидно, придётся страдать на каждом шаге - это твой личный выбор:).

В целом если нет желания писать на js - можно писать на языках, компилирующихся в wasm, наверняка есть множество библиотек с прозрачными биндингами браузерного api, например wasm-bindgen для rust.

Мало, что понимаю в wasm, но вот попалась информация, что там будет ( в Хроме 126) API реализующее Promise
https://v8.dev/blog/jspi-newapi
Js в браузере решает 99% задач.

voraa, кнешно будет, запрос же есть на него.
Гугл же сейчас вообще не стесняются пихать в веб стандарты 100500 мильёнов апи и фич на каждый чих и хотелку. Кто-то может сказать что это активное развитие, кто-то что это закрепление монополии, путём физической невозможности реализации новых браузеров.:)

Почему? Большинство АПИ все таки делается с какой то договоренностью с другими разработчиками и потом вносится в стандарт. А потом и Файрфокс и Сафари тоже его начинают его поддерживать. И наверно не просто так делают, а именно потому, что есть запрос.
Ну а если уж какой совсем новый, то пусть будет любезен тоже реализовывать все. Иначе кому такой браузер нужен будет.

voraa, дык суть как раз в том что оно так (неоправдано) разрасталось, что новый сделать абсолютно нереально. Только развивать то что уже есть. Даже если ты корпорация уровня Майков - проще сдаться:).

Ну так может это и хорошо. Не нужны ни кому куча не совместимых движков. Разработчикам не нужно это в первую очередь. А самих браузеров может быть много. Едж и Хром ведь различаются, у каждого свои плюшки. А движки пусть будут одинаковые (строго поддерживающие стандарт)

Только вот wasm про это к сожалению не знает.

Это ещё возможность взять готовый кусок кода, собрать в wasm, засунуть в браузер и запустить на любом устройстве не переписывая всё на js, без относительно того, насколько быстро и оптимально это будет работать в результате. Кроссплатфомернность которую мы заслужили...

Ну вот там внутри будут ровно те же костыли только ещё и с дополнительной кучей всякого не особо нужного обвеса.
Небольшой кусок кода на С собранный без emscripten и его стандартной библиотеки со всякими почти пустыми затычками для всяких stdio, голым clang получается на 100-150кБ меньше, т.е. раза в два. Засада приключилась с dlopen, и загрузкой функций из других wasm модулей, так как к wasm.instantiate гвоздями зачем-то приколотили async. При том что есть и синхронный вызов, но с ограничениями по размеру. Кто это интересно, #$%^!, решил что 4кБ будет достаточно для всех, а если там вдруг 10кБ то пользователь прям помрёт от лишней 1мс синхронного ожидания пока wasm это загрузит.

да, когда-нибудь будет, а потом возможно даже и не только в хроме, "жаль только жить в эту пору прекрасную..."


https://github.com/dsyer/async-wasm
я могу также руками добавить callback в wasm, в который потом верну результат асинхронной функции.
я не до конца понимаю следующее:
вызов идёт из wasm, и как мне его затормозить и подождать выполнения асинхронной функции в JS, пусть даже и в тупом цикле while(1), но чтобы при этом периодически "отдавать управление" обратно JS для выполнения его стэка вызовов с асинхронными функциями.

p.s. Для костылей "деасинхронизации" с воркерами, SharedArrayBuffer необходимый для Atomics.wait, забанили из-за spectre и включается обратно этот CORS в заголовках http от сервера.
Если я html файл открываю браузером с диска, без сервера, включить в нём sharedarraybuffer во встроенных <script> возможности я так понимаю нет? (без всяких --enable-features=SharedArrayBuffer при запуске браузера)

pvv, об "открытии html файла с диска" вообще забудь. Фактически это не поддерживаемая на данный момент технология. Проще перечислить что там будет работать, чем то что не будет.