For me, the huge missing link (that is fortunately being worked on!) is being able to (in a performant way) have a good answer for "host code wants to do some blocking operation, WASM should suspend during the operation".
This _should_ be gotten thanks to work on stack switching in WASM. As of the most recent working group meeting on this [0], it seems like V8 has made a good amount of progress on this. They published a thing back in January[1] on this, and hopefully if things go well and this is available across WASM engines then there will be one less "JS-ism" (everything async) that causes issues for transpilation.
Another feature (like WASM itself) which will probably be misused to create pages that are less usable and responsive than before. There are very good reasons why the language of the web is non-blocking.
I think you are misunderstanding things. This makes it easier for WASM-compiled programs to favor non-blocking mechanisms when being compiled. It's just that the source language might express this without an async layer.
The fact is right now if the source language has a notion of blocking calls, the when compiled to a non-blocking target like WASM it currently has to do a bunch of tricks that outright makes things slower. WIth these improvements, those "blocking calls" can properly end up non-blocking at the JS layer, matching what we all know computers can do.
JS stuff is non-blocking because of the original sin of Javascript (we have to execute all the JS before we can render a page, since there can be some document.body = ... nonsense in there). This is incidental to the programming model, and not some deeper truth about how things should be programmed.
Case in point: non-blocking `async` code in Javascript ends up sometimes turning into blocking code for performance reasons in specific cases (when awaiting an already completed promise, notably). Jumping in and out of an event loop isn't exactly efficient either.
This _should_ be gotten thanks to work on stack switching in WASM. As of the most recent working group meeting on this [0], it seems like V8 has made a good amount of progress on this. They published a thing back in January[1] on this, and hopefully if things go well and this is available across WASM engines then there will be one less "JS-ism" (everything async) that causes issues for transpilation.
[0]: https://github.com/WebAssembly/meetings/blob/main/stack/2023...
[1]: https://v8.dev/blog/jspi