<script src='несколько мегабайт яваскрипта.js'></script>
то всё нормально и потом дальше разбросанные по странице встроенные скрипты по очереди выполнятся. Но если вдруг 50кБ wasm, то его обязательно надо загружать асинхронно и потом дополнительно расставлять костыли синхронизации всем остальным, потому что порядок исполнения теперь какой попало. <script>await init()</script>
нельзя сделать.<script>
заведомо получили проинициализированные глобальные объекты, и не пришлось ничего в них менять, запихивая в колбэки init'а. async function init(){
instance = await WebAssembly.instantiate(await load('...wasm...'),{env:env})).instance;
}
<script src="somefile.js"></script>
<script>console.log(wasm)</script>
"синхронно" ? typedef struct{
int data[3][5];
}array_t;
array_t & my_static_singleton_array() {
static array_t array = {{{1,2,3,4,5},{1,2,3,4,5},{1,2,3,4,5}}};
return array;
}
void add12(array_t & array, int n){
(*((int (*) [3][5]) &array))[1][2] += n;
}
Любой await всё равно поломает синхронность выполнения. И придётся возвращать промисы и ожидать их во всех следующих зависимых скриптах, которые надо будет ещё и как type="module" объявить (что вероятно поломает и их порядок даже без await). И дополнительно так же синхронизировать и сами встроенные скрипты, так как не уверен что с await порядок их выполнения сохранится.
Тем не менее есть крайне дурацкие способы поломать асинхронность через вебворкеров (deasync), но пользоваться ими я пожалуй не буду.
а вообще про принудительную асинхронную загрузку "тому кто это придумал надо гвоздь в голову забить" (с) ДМБ
причём есть возможность синхронной загрузки wasm меньше аж 4кБ (там вроде это ограничение хотели увеличить, но если даже и увеличили, не уверен что можно полагаться что оно будет работать везде).